Thierry GERAUD <theo(a)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 : From: yann(a)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

Thierry GERAUD wrote: L'utilisation de olena (toute version) a en tout cas un effet psychologique positif pour les developpeurs :) 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. 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 ? 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. 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. 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