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