suite à une discussion rapide hier soir, il semble que le fait que je n'utilise pas la dernière version d'olena pour la prestation SWT ait un effet (psychologique) négatif sur le labo. De plus, on m'a répété des propos que je ne revendique pas. je préfère donc *écrire* ce que j'ai déjà dit plusieurs fois. les deux raisons principales pour lesquelles je tourne la version 0.5 : - étant complètement à la bourre, le portage (pas énorme) est d'une priorité ridicule par rapport aux livraisons que j'ai en retard (comprendre : nuisible à mon planning) - comme j'effectue bcp de couple compilation/test, le temps de compilation est critique pour mon avancement le détail maintenant : - la version 0.5 compile avec g++-2.95 - les versions plus récentes ne compilent pas avec g++-2.95 - les temps de compilation avec g++-2.95 sont inférieurs à ceux de des g++-3* pour preuve : ........................................................... olena-0.5 2.95.4 (2.95.4 opt) 3.3.3 (3.3.3 opt) ........................................... compilation 5,74s 10,90s 6,97s 13,25s exécution 1,15s 1,08s ........................................................... olena-0.10 3.3.3 (3.3.3 opt) ........................................... compilation 12,26s 23,28s exécution 1,91s ........................................................... mes soi-disant propos (que je déclare n'avoir jamais dit) : (1) << je n'utilise pas des versions d'olena récentes parce qu'elles se trainent >> en corrolaire, on m'a donc rapporté : (2a) << olena, c'est lent >> et (2b) << en voulant être générique et rapide, on n'est ni l'un ni l'autre ; d'ailleurs SCOOP ne marche pas >> MISES AU POINT : (1) regardez les tableaux ci-dessus, ce n'est pas le temps d'exécution qui me pénalise dans l'utilisation d'olena ; rappel : je fais du "1 compilation puis 1 test" à répétition ! (2) que les personnes qui ont dit ça en parlent ouvertement et non pas dans mon dos, qu'elles donnent des chiffres, des arguments (pas des impressions) comme vous l'aurez peut-être deviné, le code swt tourne maintenant avec la version 0.10 d'olena.
Thierry GERAUD <theo@lrde.epita.fr> writes:
........................................................... olena-0.5 2.95.4 (2.95.4 opt) 3.3.3 (3.3.3 opt) ........................................... compilation 5,74s 10,90s 6,97s 13,25s exécution 1,15s 1,08s ........................................................... olena-0.10 3.3.3 (3.3.3 opt) ........................................... compilation 12,26s 23,28s exécution 1,91s ...........................................................
J'avais posté un Makefile magique qui permet de gagner du temps lors des compilations a condition que les headers d'Olena soit propres (ie, le code dans les .hxx). Cela permet de gagner un facteur 5. Ca pourrait peut-etre t'aider ? Le post en question : From: yann@lrde.epita.fr (Yann Régis-Gianas) Subject: Compiler plus vite II (la revanche du préprocesseur) Newsgroups: lrde.vaucanson, lrde.olena Date: Tue, 07 Oct 2003 15:10:31 +0200 Organization: EPITA / LRDE http://www.lrde.epita.fr Scénario: --------- Développement d'un algorithme pour Vaucanson. Développement d'un petit programme utilisant Vaucanson. ie: un "main.cc" avec des inclusions des headers de la bibliothèque. Problème: --------- Qu'est-ce que c'est long, la compilation ! Sans option de compilation, sur un 2.5Ghz : ~/work_local/vaucanson/vgrep % g++ -c -I ../prcs-toy/include vgrep.cc 7.84s user 0.28s system 98% cpu 8.275 total Solution: --------- 1. Le programme est compilé une première fois (c'est long mais c'est principalement à cause de l'analyse/instanciation du code de Vaucanson). Cette compilation se decompose en deux etapes : a. compilation d'une unité d'instanciation main.unit.o (la même chose que le code de main.cc mais ses fonctions sont envoyees dans un namespace poubelle). b. compilation de main.o mais seulement avec les interfaces de vaucanson. c. liaison de main.o et main.unit.o. 2. Je travaille sur le code de mon algorithme (pas sur Vaucanson). Faire b. puis c. tant qu'il n'y a pas de problème de liaison, sinon faire a. b. c. Benchmark: ---------- ~/work_local/vaucanson/vgrep % make g++ -I ../prcs-toy/include -c -o vgrep.unit.o vgrep.unit.cc g++ -o vgrep vgrep.o vgrep.unit.o make 8.20s user 0.37s system 96% cpu 8.885 total ... modification dans vgrep.cc ... ~/work_local/vaucanson/vgrep % make g++ -c -I ../prcs-toy/include vgrep.cc -DINTERFACE_ONLY g++ -o vgrep vgrep.o vgrep.unit.o make 1.64s user 0.17s system 92% cpu 1.956 total ... repetition tant qu'on n'utilise pas de nouveaux types/algorithmes de Vaucanson ... Conclusion: ----------- Soit un gain de 5 (qui a priori doit etre encore plus fort sur des machines plus lentes). Le Makefile qui suit est une ebauche grossiere mais l'idee est la. Je propose la distribution d'un tel Makefile(.am) dans la tarball de Vaucanson. --- Makefile -------------------------------------------------------------- --------------------------------------------------------------------------- CXX=g++ CXXFLAGS= CPPFLAGS=-I ../prcs-toy/include MAKE=make GREP=grep all: vgrep vgrep.unit.cc: @ $(GREP) '#include' vgrep.cc > vgrep.unit.cc @ echo 'namespace __instanciator_code {' >> vgrep.unit.cc @ $(GREP) -v '#include' vgrep.cc >> vgrep.unit.cc @ echo '}' >> vgrep.unit.cc vgrep.o: vgrep.cc $(CXX) -c $(CPPFLAGS) $(CXXFLAGS) vgrep.cc -DINTERFACE_ONLY vgrep: vgrep.o vgrep.unit.o @ $(CXX) -o vgrep vgrep.o vgrep.unit.o &> /tmp/log || \ (grep 'ld returned 1 exit status' /tmp/log &> /dev/null && \ rm vgrep.unit.cc && \ $(MAKE)) @ cat /tmp/log
Yann Régis-Gianas wrote:
Thierry GERAUD <theo@lrde.epita.fr> writes: [...] J'avais posté un Makefile magique qui permet de gagner du temps lors des compilations a condition que les headers d'Olena soit propres (ie, le code dans les .hxx). Cela permet de gagner un facteur 5. Ca pourrait peut-etre t'aider ?
Le post en question : [...]
merci, c'était passé à la (ma) trappe (malgré l'importance de ta contrib !!!) qui se charge de : 1. wikifier (en EN) le texte de yann dans la KB + ajouter un lien dans les pages olena 2. ajouter ce texte dans la doc d'olena 3. me former, en version ultra-rapide, à gforge (pour que j'arrête ce type de post !) ?
Thierry GERAUD wrote:
suite à une discussion rapide hier soir, il semble que le fait que je n'utilise pas la dernière version d'olena pour la prestation SWT ait un effet (psychologique) négatif sur le labo.
L'utilisation de olena (toute version) a en tout cas un effet psychologique positif pour les developpeurs :)
- comme j'effectue bcp de couple compilation/test, le temps de compilation est critique pour mon avancement
Oui, et tu n'es pas le seul à souligner ce problème. L'algo qui classifie présenté lors du séminaire prend 2 minutes pour compiler sur nostromo, et... se fait killer sur mon pauvre PC. Il existe des moyens pour diminuer le temps de compile. Doit-on travailler la dessus ? Est-ce une priorité ? Je pense que oui.
olena-0.5 exécution 1,15s 1,08s
olena-0.10 3.3.3 (3.3.3 opt) exécution 1,91s
(2a) << olena, c'est lent >>
Par rapport a la version 0.5, Olena est environ 2 fois plus lent (1.08 vs 1.91). Est-ce important ? Doit-on travailler dessus ? Doit-on attendre que les compilateurs s'améliorent ?
(2b) << en voulant être générique et rapide, on n'est ni l'un ni l'autre ; >>
Ce qu'a oublié la personne qui a dit ça, c'est que 'générique' et 'rapide' doivent être compris relativement. Il est clair que Olena 0.10 est moins rapide que Olena 0.5 pour les compilateurs actuels. Mais Olena est rapide par rapport à Mathlab, par rapport à de nombreuses autres bibliothèques. En ce qui concerne la génénéricité, on peut difficilement dire qu'Olena n'est pas génénérique. Mais on peut encore gagner en généricité, en travaillant par exemple sur les images à base de pixels non rectangulaires, ou bien les images Nd.
<< d'ailleurs SCOOP ne marche pas>>
SCOOP n'est pas utilisé systématiquement dans Olena (par exemple la hierarchie des window est mauvaise). Il y a également des modifictions à apporter pour éviter des problèmes de typages dans les morphers. Ceci dit SCOOP marche car Olena 0.10 marche. SCOOP n'est pas finalisé et appliqué partout et c'est pourquoi la version d'Olena n'est pas Olena 1.0. Ceci dit encore une fois il faut fixer les priorités.
(2) que les personnes qui ont dit ça en parlent ouvertement et non pas dans mon dos, qu'elles donnent des chiffres, des arguments (pas des impressions)
On en a déjà parlé lors du pot de la Release Olena-Vaucanson-Transformer. Je pense qu'un certain nombre d'arguments ont été mal interprétés. Ceci dit je pense qu'il ne faut pas demander aux personnes mécontentes des preuves, mais faire avancer Olena. Je propose une réunion Olena mercredi matin pour savoir où on veut aller (image Nd, Scoop, compile++, stable?). -- Niels
Niels van Vliet wrote:
Thierry GERAUD wrote:
suite à une discussion rapide hier soir, il semble que le fait que je n'utilise pas la dernière version d'olena pour la prestation SWT ait un effet (psychologique) négatif sur le labo.
L'utilisation de olena (toute version) a en tout cas un effet psychologique positif pour les developpeurs :)
- comme j'effectue bcp de couple compilation/test, le temps de compilation est critique pour mon avancement
Oui, et tu n'es pas le seul à souligner ce problème.
L'algo qui classifie présenté lors du séminaire prend 2 minutes pour compiler sur nostromo, et... se fait killer sur mon pauvre PC.
Il existe des moyens pour diminuer le temps de compile. Doit-on travailler la dessus ? Est-ce une priorité ? Je pense que oui.
ce n'est pas à moi de répondre ; je peux seulement donner mon avis (qui est : je ne pense pas que c'est une des priorités majeures)
olena-0.5 exécution 1,15s 1,08s
olena-0.10 3.3.3 (3.3.3 opt) exécution 1,91s
(2a) << olena, c'est lent >>
Par rapport a la version 0.5, Olena est environ 2 fois plus lent (1.08 vs 1.91). Est-ce important ?
je ne le pense pas pour deux raisons : 1. les temps d'exécution ne peuvent qu'être améliorés (ils le seront dans un avenir qu'il faudrait fixer) 2. le fait de disposer dans olena d'algorithmes performants (au sens des fast::morpho, des filtrages récursifs, de l'union-find de Tarjan) au lieu des versions naïves est bcp plus important
Doit-on travailler dessus ? Doit-on attendre que les compilateurs s'améliorent ?
ce n'est pas à moi de prendre des décisions sur ces points
(2b) << en voulant être générique et rapide, on n'est ni l'un ni l'autre ; >>
Ce qu'a oublié la personne qui a dit ça, c'est que 'générique' et 'rapide' doivent être compris relativement. Il est clair que Olena 0.10 est moins rapide que Olena 0.5 pour les compilateurs actuels. Mais Olena est rapide par rapport à Mathlab, par rapport à de nombreuses autres bibliothèques.
Cf. ce que je disais précédent : il faut dorénavant éviter ce type d'assertions ! quelqu'un a comparé les temps d'exécution avec matlab, avec d'autres bibliothèques ? il faudrait peut-être le faire...
En ce qui concerne la génénéricité, on peut difficilement dire qu'Olena n'est pas génénérique. Mais on peut encore gagner en généricité, en travaillant par exemple sur les images à base de pixels non rectangulaires, ou bien les images Nd.
<< d'ailleurs SCOOP ne marche pas>>
SCOOP n'est pas utilisé systématiquement dans Olena (par exemple la hierarchie des window est mauvaise).
vrai Cf. mon autre post à propos de bêtes fonctions mathématiques ; on a tout à y gagner en passant à SCOOP
Il y a également des modifictions à apporter pour éviter des problèmes de typages dans les morphers. Ceci dit SCOOP marche car Olena 0.10 marche. SCOOP n'est pas finalisé et appliqué partout et c'est pourquoi la version d'Olena n'est pas Olena 1.0. Ceci dit encore une fois il faut fixer les priorités.
oui
(2) que les personnes qui ont dit ça en parlent ouvertement et non pas dans mon dos, qu'elles donnent des chiffres, des arguments (pas des impressions)
On en a déjà parlé lors du pot de la Release Olena-Vaucanson-Transformer. Je pense qu'un certain nombre d'arguments ont été mal interprétés.
sûrement, il faudrait donc en parler
Ceci dit je pense qu'il ne faut pas demander aux personnes mécontentes des preuves, mais faire avancer Olena. Je propose une réunion Olena
tu interprètes mal mes propos : je dis qu'il n'est pas normal de critiquer dans mon dos et, Cf. plus haut, je dis qu'une critique doit être fondée (et, pour ça, il faut _effectivement_ avancer des *faits*)
mercredi matin pour savoir où on veut aller (image Nd, Scoop, compile++, stable?).
très bonne initiative un responsable fait un ordre du jour ?
connaissant olena et faisant parti des gens qui ne l'utilise pas (ou tres peu) pour faire du traitement d'images, je peux vous dire qu'olena n'est pas un remplacant de matlab, maintenant si on se compare a ce produit, il faut etre realiste : de mon point de vue, il n'existe pas un equivalent de matlab (en performance et en convivialite) pour mettre au point une methode, et a moins que j'ai mal compris nos objectifs, je ne pense pas que le but actuel d'olena est de faire de la concurrence a matlab. personnelement, j'utilise olena (ou un programme c ou c++) que quand j'ai besoin de traiter beaucoup de données, et que ma methode est deja fixée. le reste du temps j'utilise matlab a cause de tous les moyens disponible sur cet outil. pour olena, il faut viser la stabilité du tronc, tant qu'on n'aura pas une garantit sur la portabilité du code d'une version a l'autre, personne ne va se permettre d'utiliser la derniere version. meme si on sait que la derniere version contient moins de bugs et plus d'algos ... Pour cette raison, il ne faut pas perdre du temps pour aller chercher les performances, alors qu'on est meme pas sure que le code de la version 1.0 serait compatible avec la version actuelle ceci reste que mon avis, et vous pouvez avoir un autre avis completement different, pour pouvoir debattre de tous ces problemes, je vous invite a venir tous a la reunion de demain *Mercredi 09 juin a 15h00* Thierry GERAUD wrote:
Niels van Vliet wrote:
Thierry GERAUD wrote:
suite à une discussion rapide hier soir, il semble que le fait que je n'utilise pas la dernière version d'olena pour la prestation SWT ait un effet (psychologique) négatif sur le labo.
L'utilisation de olena (toute version) a en tout cas un effet psychologique positif pour les developpeurs :)
- comme j'effectue bcp de couple compilation/test, le temps de compilation est critique pour mon avancement
Oui, et tu n'es pas le seul à souligner ce problème.
L'algo qui classifie présenté lors du séminaire prend 2 minutes pour compiler sur nostromo, et... se fait killer sur mon pauvre PC.
Il existe des moyens pour diminuer le temps de compile. Doit-on travailler la dessus ? Est-ce une priorité ? Je pense que oui.
ce n'est pas à moi de répondre ; je peux seulement donner mon avis (qui est : je ne pense pas que c'est une des priorités majeures)
olena-0.5 exécution 1,15s 1,08s
olena-0.10 3.3.3 (3.3.3 opt) exécution 1,91s
(2a) << olena, c'est lent >>
Par rapport a la version 0.5, Olena est environ 2 fois plus lent (1.08 vs 1.91). Est-ce important ?
je ne le pense pas pour deux raisons :
1. les temps d'exécution ne peuvent qu'être améliorés (ils le seront dans un avenir qu'il faudrait fixer)
2. le fait de disposer dans olena d'algorithmes performants (au sens des fast::morpho, des filtrages récursifs, de l'union-find de Tarjan) au lieu des versions naïves est bcp plus important
Doit-on travailler dessus ? Doit-on attendre que les compilateurs s'améliorent ?
ce n'est pas à moi de prendre des décisions sur ces points
(2b) << en voulant être générique et rapide, on n'est ni l'un ni l'autre ; >>
Ce qu'a oublié la personne qui a dit ça, c'est que 'générique' et 'rapide' doivent être compris relativement. Il est clair que Olena 0.10 est moins rapide que Olena 0.5 pour les compilateurs actuels. Mais Olena est rapide par rapport à Mathlab, par rapport à de nombreuses autres bibliothèques.
Cf. ce que je disais précédent : il faut dorénavant éviter ce type d'assertions ! quelqu'un a comparé les temps d'exécution avec matlab, avec d'autres bibliothèques ? il faudrait peut-être le faire...
En ce qui concerne la génénéricité, on peut difficilement dire qu'Olena n'est pas génénérique. Mais on peut encore gagner en généricité, en travaillant par exemple sur les images à base de pixels non rectangulaires, ou bien les images Nd.
<< d'ailleurs SCOOP ne marche pas>>
SCOOP n'est pas utilisé systématiquement dans Olena (par exemple la hierarchie des window est mauvaise).
vrai
Cf. mon autre post à propos de bêtes fonctions mathématiques ; on a tout à y gagner en passant à SCOOP
Il y a également des modifictions à apporter pour éviter des problèmes de typages dans les morphers. Ceci dit SCOOP marche car Olena 0.10 marche. SCOOP n'est pas finalisé et appliqué partout et c'est pourquoi la version d'Olena n'est pas Olena 1.0. Ceci dit encore une fois il faut fixer les priorités.
oui
(2) que les personnes qui ont dit ça en parlent ouvertement et non pas dans mon dos, qu'elles donnent des chiffres, des arguments (pas des impressions)
On en a déjà parlé lors du pot de la Release Olena-Vaucanson-Transformer. Je pense qu'un certain nombre d'arguments ont été mal interprétés.
sûrement, il faudrait donc en parler
Ceci dit je pense qu'il ne faut pas demander aux personnes mécontentes des preuves, mais faire avancer Olena. Je propose une réunion Olena
tu interprètes mal mes propos : je dis qu'il n'est pas normal de critiquer dans mon dos et, Cf. plus haut, je dis qu'une critique doit être fondée (et, pour ça, il faut _effectivement_ avancer des *faits*)
mercredi matin pour savoir où on veut aller (image Nd, Scoop, compile++, stable?).
très bonne initiative
un responsable fait un ordre du jour ?
Réda Dehak wrote:
connaissant olena et faisant parti des gens qui ne l'utilise pas (ou tres peu) pour faire du traitement d'images, je peux vous dire qu'olena n'est pas un remplacant de matlab, maintenant si on se compare a ce produit, il faut etre realiste : de mon point de vue, il n'existe pas un equivalent de matlab (en performance et en convivialite) pour mettre au point une methode, et a moins que j'ai mal compris nos objectifs, je ne pense pas que le but actuel d'olena est de faire de la concurrence a matlab. personnelement, j'utilise olena (ou un programme c ou c++) que quand j'ai besoin de traiter beaucoup de données, et que ma methode est deja fixée. le reste du temps j'utilise matlab a cause de tous les moyens disponible sur cet outil.
pour olena, il faut viser la stabilité du tronc, tant qu'on n'aura pas une garantit sur la portabilité du code d'une version a l'autre, personne ne va se permettre d'utiliser la derniere version. meme si on sait que la derniere version contient moins de bugs et plus d'algos ...
Pour cette raison, il ne faut pas perdre du temps pour aller chercher les performances, alors qu'on est meme pas sure que le code de la version 1.0 serait compatible avec la version actuelle
ceci reste que mon avis, et vous pouvez avoir un autre avis completement different,
pour pouvoir debattre de tous ces problemes, je vous invite a venir tous a la reunion de demain *Mercredi 09 juin a 15h00*
La reunion aura lieu a 14h00 et non 15h00
participants (4)
-
Niels van Vliet -
Réda Dehak -
Thierry GERAUD -
yann＠lrde.epita.fr