3 Jun
2004
3 Jun
'04
4:09 p.m.
Thierry GERAUD <theo(a)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(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