21 Jan
2004
21 Jan
'04
5:14 a.m.
Index: olena/ChangeLog
from Astrid Wang <astrid(a)lrde.epita.fr>
* oln/core/point2d.hxx: Fix member function minus().
* oln/core/abstract/dpoint.hh: Add member function norm2().
Index: olena/oln/core/abstract/dpoint.hh
--- olena/oln/core/abstract/dpoint.hh Thu, 07 Aug 2003 02:08:21 +0200 david
(oln/d/28_dpoint.hh 1.16 640)
+++ olena/oln/core/abstract/dpoint.hh Mon, 19 Jan 2004 17:49:12 +0100 astrid
(oln/d/28_dpoint.hh 1.16 640)
@@ -30,6 +30,7 @@
# include <mlc/type.hh>
# include <oln/core/coord.hh>
+# include <ntg/real/builtin_float.hh>
namespace oln {
@@ -135,6 +136,16 @@
return true;
}
+ ntg::float_d
+ norm2(void) const
+ {
+ double norm = 0;
+
+ for (unsigned i = 0; i < dim; ++i)
+ norm += nth(i) * nth(i);
+ return sqrt(norm);
+ }
+
static std::string
name()
{
Index: olena/oln/core/point2d.hxx
--- olena/oln/core/point2d.hxx Mon, 28 Jul 2003 14:14:03 +0200 david (oln/c/29_point2d.hx
1.5 640)
+++ olena/oln/core/point2d.hxx Mon, 19 Jan 2004 16:44:56 +0100 astrid (oln/c/29_point2d.hx
1.5 640)
@@ -114,7 +114,7 @@
inline point2d
point2d::minus() const
{
- point2d p(row(), col());
+ point2d p(-row(), -col());
return p;
}
--
astrid
21 Jan
21 Jan
10:44 a.m.
Astrid Wang <wang_a(a)epita.fr> writes:
point2d::minus() const
{
- point2d p(row(), col());
+ point2d p(-row(), -col());
return p;
}
Ne vaut-il mieux pas écrire :
point2d::minus() const
{
return point2d(-row(), -col());
}
Car sinon il y a un risque que ceci se produise :
* Appel du constructeur d'un point2d pour p avec (-row(), -col()).
* Appel du constructeur par copie de point2d a l'emplacement de la
valeur de retour, en dehors de la fonction.
* Appel du destructeur de p.
La deuxième syntaxe, elle, autorise le compilateur à appler
directement le bon constructeur a l'emplacement de l'objet qui va
recevoir la valeur de retour.
cf. Thinking in C++, page 421, en bas. :)
gcc en -O3 optimise le premier code de sorte a ce qu'il n'y ai pas de
problèmes, mais icc ne le fait pas. Et en plus, je trouve que gcc
n'est pas très correct en se permettant de telles optimisations, qui
risque de changer le comportement attendu.
Pour conclure, c'est ce genre de problème qui fait que vaucanson est
beaucoup plus rapide quand on le compile avec gcc qu'avec icc.
--
Thomas Claveirole
thomas.claveirole(a)lrde.epita.fr
1:45 p.m.
Thomas Claveirole wrote:
[...]
cf. Thinking in C++, page 421, en bas. :)
gcc en -O3 optimise le premier code de sorte a ce qu'il n'y ai pas de
problèmes, mais icc ne le fait pas. Et en plus, je trouve que gcc
n'est pas très correct en se permettant de telles optimisations, qui
risque de changer le comportement attendu.
Pour conclure, c'est ce genre de problème qui fait que vaucanson est
beaucoup plus rapide quand on le compile avec gcc qu'avec icc.
il faut qu'on en parle
1:48 p.m.
Thomas Claveirole <thomas.claveirole(a)lrde.epita.fr> writes:
Astrid Wang <wang_a(a)epita.fr> writes:
Changer le comportement en quoi par exemple ?
point2d::minus() const
{
- point2d p(row(), col());
+ point2d p(-row(), -col());
return p;
}
Ne vaut-il mieux pas écrire :
point2d::minus() const
{
return point2d(-row(), -col());
}
Car sinon il y a un risque que ceci se produise :
* Appel du constructeur d'un point2d pour p avec (-row(), -col()).
* Appel du constructeur par copie de point2d a l'emplacement de la
valeur de retour, en dehors de la fonction.
* Appel du destructeur de p.
La deuxième syntaxe, elle, autorise le compilateur à appler
directement le bon constructeur a l'emplacement de l'objet qui va
recevoir la valeur de retour.
cf. Thinking in C++, page 421, en bas. :)
gcc en -O3 optimise le premier code de sorte a ce qu'il n'y ai pas de
problèmes, mais icc ne le fait pas. Et en plus, je trouve que gcc
n'est pas très correct en se permettant de telles optimisations, qui
risque de changer le comportement attendu. Pour conclure, c'est ce genre de problème qui
fait que vaucanson est
beaucoup plus rapide quand on le compile avec gcc qu'avec icc.
Intéressant :)
Si on y gagne à tous les coups, alors il faudra jeter un oeil dans les
différents fichiers d'Olena car on peut trouver ce genre d'écriture un
peu partout dans Olena.
--
astrid
2:50 p.m.
Astrid Wang <wang_a(a)epita.fr> writes:
Changer le comportement en quoi par exemple ?
Dans des cas peu fréquents (et très moches) ou tu as des effets de
bords dans le constructeur qui vont aller modifier autre chose que
l'objet en construction. En effet, dans ces cas là, appeler deux
constructeurs au lieu d'un, ce n'est pas forcément la même chose. Idem
avec les déstructeurs.
Cela-dit, je n'ai jamais vu d'exemple de tel cas. Simplement,
théoriquement, ce n'est pas impossible. Un exemple classique serait
d'afficher quelque chose dans le constructeur.
Si on y gagne à tous les coups, alors il faudra jeter
un oeil dans les
différents fichiers d'Olena car on peut trouver ce genre d'écriture un
peu partout dans Olena.
Parfois, ce n'est pas toujours possible de procéder ainsi :
ma_fonction()
{
MonObjet o;
o.je_fait_des_trucs();
return o;
}
En particulier, il y a pas mal de fonction de ce genre dans Vaucanson.
--
Thomas Claveirole
thomas.claveirole(a)lrde.epita.fr
3:43 p.m.
>> "Thomas" == Thomas Claveirole
<thomas.claveirole(a)lrde.epita.fr> writes:
Thomas> Astrid Wang <wang_a(a)epita.fr> writes:
> point2d::minus() const
> {
> - point2d p(row(), col());
> + point2d p(-row(), -col());
> return p;
> }
Thomas> Ne vaut-il mieux pas écrire :
Thomas> point2d::minus() const
Thomas> {
Thomas> return point2d(-row(), -col());
Thomas> }
Thomas> Car sinon il y a un risque que ceci se produise :
Thomas> * Appel du constructeur d'un point2d pour p avec (-row(), -col()).
Thomas> * Appel du constructeur par copie de point2d a l'emplacement de la
Thomas> valeur de retour, en dehors de la fonction.
Thomas> * Appel du destructeur de p.
Thomas> La deuxième syntaxe, elle, autorise le compilateur à appler
Thomas> directement le bon constructeur a l'emplacement de l'objet qui
va
Thomas> recevoir la valeur de retour.
Pour autant que je sache, la première aussi, car elle est
sujette à l'optimisation de la valeur de retour nommée (sur
le net: "Named return value optimization" ou encore "RVO").
C'est un sujet qu'on a discuté il y a quelques années au labo,
quelqu'un en a peut-être encore des traces quelque part.
En tout cas c'est la raison pour laquelle on préfère écrire
A operator+(const A& l, const A& r)
{
A a(l)
a += r;
return a;
}
plutôt que
A operator+(const A& l, const A& r)
{
return A(l) += r;
}
Dans le premier cas le compilateur pour placer `a' directement à
l'emplacement de la valeur de retour, pour éviter la copie.
Dans le second cas compilateur ne sait pas a priori que
l'adresse du résultat de `+=' est la même que celle de la
variable temporaire créée pour A(l).
(J'ai bien compris que tu n'es pas tout as fait dans ce cas là.
Je justifie juste le comportement de gcc: la norme lui permet
cette optimisation.)
--
Alexandre Duret-Lutz
5:55 p.m.
Alexandre Duret-Lutz <duret_g(a)lrde.epita.fr> writes:
[...]
Pour autant que je sache, la première aussi, car elle est
sujette à l'optimisation de la valeur de retour nommée (sur
le net: "Named return value optimization" ou encore "RVO").
C'est un sujet qu'on a discuté il y a quelques années au labo,
quelqu'un en a peut-être encore des traces quelque part.
En tout cas c'est la raison pour laquelle on préfère écrire
A operator+(const A& l, const A& r)
{
A a(l)
a += r;
return a;
}
plutôt que
A operator+(const A& l, const A& r)
{
return A(l) += r;
}
si le compilateur ne supporte pas nrvo, il est preferable de faire:
A operator+(A l, const A& r)
{
return l += r;
}
cf. http://www.boost.org/libs/utility/operators.htm#symmetry
les gars de boost ont choisi de supporter les deux syntaxes.
d'apres leurs headers, cette optimisation est dispos seulement
sur gcc >= 3.1 et icc >= 6.
--
js(a)lrde.epita.fr | pouet(a)mouret.org
"creating the future" (c) framfab
22 Jan
22 Jan
3:10 p.m.
serial wrote:
[...]
cf. http://www.boost.org/libs/utility/operators.htm#symmetry
les gars de boost ont choisi de supporter les deux syntaxes.
ils doivent avoir raison !
d'apres leurs headers, cette optimisation est
dispos seulement
sur gcc >= 3.1 et icc >= 6.
j'ai du code sur lequel on va pouvoir tester ça
(en plus du code déjà écrit d'olena)
(coucou js, coucou pollux)
4:15 p.m.
Astrid Wang <wang_a(a)epita.fr> writes:
Index: olena/ChangeLog
from Astrid Wang <astrid(a)lrde.epita.fr>
* oln/core/point2d.hxx: Fix member function minus().
* oln/core/abstract/dpoint.hh: Add member function norm2().
Index: olena/oln/core/abstract/dpoint.hh
--- olena/oln/core/abstract/dpoint.hh Thu, 07 Aug 2003 02:08:21 +0200 david
(oln/d/28_dpoint.hh 1.16 640)
+++ olena/oln/core/abstract/dpoint.hh Mon, 19 Jan 2004 17:49:12 +0100 astrid
(oln/d/28_dpoint.hh 1.16 640)
@@ -30,6 +30,7 @@
# include <mlc/type.hh>
# include <oln/core/coord.hh>
+# include <ntg/real/builtin_float.hh>
#include <ntg/float.hh>
C'est mieux d'utiliser les headers publics, ils regroupent les headers
utiles.
28 Jan
28 Jan
11:07 a.m.
Astrid Wang <wang_a(a)epita.fr> writes:
> Index: olena/ChangeLog
> from Astrid Wang <astrid(a)lrde.epita.fr>
>
> * oln/core/point2d.hxx: Fix member function minus().
> * oln/core/abstract/dpoint.hh: Add member function norm2().
>
> Index: olena/oln/core/abstract/dpoint.hh
> --- olena/oln/core/abstract/dpoint.hh Thu, 07 Aug 2003 02:08:21 +0200 david
(oln/d/28_dpoint.hh 1.16 640)
> +++ olena/oln/core/abstract/dpoint.hh Mon, 19 Jan 2004 17:49:12 +0100 astrid
(oln/d/28_dpoint.hh 1.16 640)
> @@ -30,6 +30,7 @@
>
> # include <mlc/type.hh>
> # include <oln/core/coord.hh>
> +# include <ntg/real/builtin_float.hh>
#include <ntg/float.hh>
C'est mieux d'utiliser les headers publics,
ils regroupent les headers
utiles.
On peut peut-être utiliser #warning (+ #ifndef) pour guider
l'utilisateur sur les bons headers ?
7401
days inactive
7408
days old
9 comments
7 participants
participants (7)
-
Akim Demaille -
Alexandre Duret-Lutz -
Astrid Wang -
Nicolas Burrus -
serial -
Thierry Géraud -
Thomas Claveirole