Forum Programmation.c++ Compilateur "streamé"

Posté par Gui13 (site web personnel) le 24 mars 2013 à 20:43. Licence CC By‑SA.

Étiquettes : aucune

mar.

2013

Salut à tous,

Je suis entrain de compiler Qt5 en -j5, et je bulle en attendant.

Donc voici:
Aujourd'hui, le processus de compilation, c'est ça:

je tape gcc moncode.c -c -o moncode.o
le shell lance /usr/bin/gcc dans un nouveau processus et lui passe les options
LDD entre en action, reloge les libs dont GCC a besoin (stdlib, ld, environ 500ko)
le main est enfin lancé, et parse les arguments
gcc va "automatiquement" lancer l'assembleur (ar) et l'éditeur de lien (ld), dans des sous-processus

Pour un petit projet, 4 ou 5 fichiers, c'est simple, mais je me dis que quand on commence à tourner autour des 3 ou 4000 fichiers source, le coût de lancement de 9 à 12000 processus gcc/ar/ld devient non négligeable.

Du coup l'idée d'un compilateur "streamé", dans le sens où c'est un démon qui tourner, et à qui on passe les paramètres du boulot qu'on veut lui faire faire par un moyen quelconque.

Genre:

./gcc-daemon &
echo "/home/toto/moncode.c -c -o /home/toto/moncode.o" > /tmp/gcc-daemon-pipe 
# lit moncode.c et écrit le fichier objet dans moncode.o
# on récupère le log des erreurs éventuelles dans un pipe aussi

Du coup, il n'y a plus de coût de lancement de processus, et on peut imaginer de faire tourner ar et ld dans ce mode là.
Et si le "pipe" dans lequel on balance les instructions est un peu intelligent, il peut spawner des sous-gcc qui vont recevoir leurs ordres depuis le gcc maitre, pour faire de la compile parallélisée.

Qu'en pensez-vous?
Est-ce que ça existe déjà?
Est-ce que y a des grosses failles qui font que c'est de la grosse merde?

# distccd ?

Posté par gouttegd (site web personnel) le 24 mars 2013 à 22:28. Évalué à 1.

N’est-ce pas déjà ce que fait distccd(1) ?

C’est prévu pour compiler à travers le réseau, mais qui peut le plus peut le moins, donc si on peut envoyer les fichiers à compiler à des démons sur d’autres machines, on doit aussi pouvoir les envoyer à un démon distccd sur la machine locale.

(Enfin je suppose, je n’ai jamais utilisé distcc.)
- [^] # Re: distccd ?
  
  Posté par Gui13 (site web personnel) le 24 mars 2013 à 22:32. Évalué à 3.
  
  Non pas vraiment, distcc va spawner un gcc derrière, pour chaque fichier, donc au final on retrouve le même fonctionnement.
# premature optimization is the root of all evil

Posté par neologix le 25 mars 2013 à 10:26. Évalué à 7. Dernière modification le 25 mars 2013 à 10:27.
Est-ce que y a des grosses failles qui font que c'est de la grosse merde?

Bah déjà, pour peu que ton makefile soit bien fait, tu ne vas pas tout recompiler à chaque fois, seulement le différentiel.

Ensuite, j'ai un doute sur le fait que la création des process pèsent lourd face à la phase de compilation.

Par exemple, voilà le résultat d'un benchmark d'une compilation clean de Python :

time :
```
real    1m36.857s
user    1m28.322s
sys     0m6.429s
```
strace -c -f :
```
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 99.29   41.756190        9054      4612      1679 wait4
  0.27    0.112962          21      5259      3232 execve
  0.10    0.041814          20      2108           clone
  0.07    0.028498           1     55672           write
  0.05    0.022086           0     92638           read
  0.04    0.015907           0    114234     66266 open
  0.04    0.015722         114       138           rename
  0.04    0.015164          14      1106       201 unlink
```
La grosse majorité est passé en userland, et le reste contient les I/O, etc. Donc fork()/exec() & Co ne pèsent pas lourd, sans compter que dans ton approche il y aurait aussi beaucoup d'IPC qui n'est pas gratuit non plus…