Compiler en parallele

Le
Fabien LE LEZ
Bonjour,

Comme de plus en plus de monde, j'ai maintenant un processeur double
coeur (Core2 Duo), et je m'aperçois que la plupart des logiciels ne
peuvent utiliser que 50 % de sa puissance (i.e. un seul coeur).

Qu'en est-il des compilateurs ?
Existe-t-il des outils pour répartir la compilation sur deux
processeurs ou plus ?

(Je précise que tous les fichiers de mes projets (sources, objets,
exe) tiennent largement en RAM, donc le disque dur ne reste pas
longtemps un goulot d'étranglement.)
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
fabien.chene
Le #309157
Fabien LE LEZ
Comme de plus en plus de monde, j'ai maintenant un processeur double
coeur (Core2 Duo), et je m'aperçois que la plupart des logiciels ne
peuvent utiliser que 50 % de sa puissance (i.e. un seul coeur).

Qu'en est-il des compilateurs ?


Je ne sais pas s'il existe des compilateurs multithreadés ; mais par
curiosité, j'aimerais bien savoir si la phase de parsing est évidente
à rendre multithread.

Existe-t-il des outils pour répartir la compilation sur deux
processeurs ou plus ?


Divers outils de compilation permettent de lancer des compilations
parallèles, ie sur plusieurs processus : les utilitaires 'make',
'jam', 'bjam', invoqués avec l'option -j -- pour ceux que je connais,
j'imgine que la plupart des utilitaires de compilation ont une option
de ce genre. Après, un outil tel que distcc est capable de répartir
ces processus sur divers machines.


--
Fab

Falk Tannhäuser
Le #309154
Comme de plus en plus de monde, j'ai maintenant un processeur double
coeur (Core2 Duo), et je m'aperçois que la plupart des logiciels ne
peuvent utiliser que 50 % de sa puissance (i.e. un seul coeur).

Qu'en est-il des compilateurs ?
Existe-t-il des outils pour répartir la compilation sur deux
processeurs ou plus ?


Le 'make' de chez GNU offre une telle fonctionnalité si on lui passe
'-j' ou '--jobs' sur la ligne de commande. Pour plus de détails,
consulter la section intitulée "Parallel" dans l'info de make.
Je ne sais pas si d'autres 'make' possèdent une option semblable.

Falk

Sylvain
Le #309112
Fabien LE LEZ wrote on 22/07/2007 20:10:

(Je précise que tous les fichiers de mes projets (sources, objets,
exe) tiennent largement en RAM, donc le disque dur ne reste pas
longtemps un goulot d'étranglement.)


qu'ils y tiennent est une chose, qu'ils y soient en est une autre.
utilises-tu un RAM disk ? non, alors tout repose sur le cache controleur
et le cache système, soit aucune certitude.

Sylvain.

Christophe Lephay
Le #309111
"Sylvain" 46a3d486$0$25910$
Fabien LE LEZ wrote on 22/07/2007 20:10:

(Je précise que tous les fichiers de mes projets (sources, objets,
exe) tiennent largement en RAM, donc le disque dur ne reste pas
longtemps un goulot d'étranglement.)


qu'ils y tiennent est une chose, qu'ils y soient en est une autre.
utilises-tu un RAM disk ? non, alors tout repose sur le cache controleur
et le cache système, soit aucune certitude.


De toute façon, c'est le processeur et non le disque le maillon faible pour
une compilation...


Michael DOUBEZ
Le #309110
"Sylvain" 46a3d486$0$25910$
Fabien LE LEZ wrote on 22/07/2007 20:10:
(Je précise que tous les fichiers de mes projets (sources, objets,
exe) tiennent largement en RAM, donc le disque dur ne reste pas
longtemps un goulot d'étranglement.)
qu'ils y tiennent est une chose, qu'ils y soient en est une autre.

utilises-tu un RAM disk ? non, alors tout repose sur le cache controleur
et le cache système, soit aucune certitude.


De toute façon, c'est le processeur et non le disque le maillon faible pour
une compilation...


Pas nécessairement, c'est pourquoi gcc a l'option -pipe qui permet
d'éviter la création de fichiers temporaires entre les phases de
compilation.

Pour ce qui est de l'utilisation des deux coeurs des processeurs, ça
dépends de l'OS et du compilateur utilisé. Sous linux, il doit falloir
regarder dans les options du noyau pour savoir comment sont repartis les
ressources (ie. un thread attaché à un proc ou autre politique).

Pour le compilateur, je sais que j'ai du utiliser des compilos spéciaux
pour les architectures risc mais pour les multi-coeur, je sais pas.

Michael



James Kanze
Le #309108
On Jul 22, 9:17 pm, Falk Tannhäuser wrote:
Comme de plus en plus de monde, j'ai maintenant un processeur double
coeur (Core2 Duo), et je m'aperçois que la plupart des logiciels ne
peuvent utiliser que 50 % de sa puissance (i.e. un seul coeur).

Qu'en est-il des compilateurs ?
Existe-t-il des outils pour répartir la compilation sur deux
processeurs ou plus ?


Le 'make' de chez GNU offre une telle fonctionnalité si on lui passe
'-j' ou '--jobs' sur la ligne de commande. Pour plus de détails,
consulter la section intitulée "Parallel" dans l'info de make.
Je ne sais pas si d'autres 'make' possèdent une option semblable.


Au moins sous Unix, g++ a une option -pipe, aussi, qui fait que
plusieurs phases de compilation peuvent s'exécuter en parallel.
(Et si j'étais mauvaise langue, je dirais que sous Windows, tu
gagnes, parce que tu as un processeur pour les virus, et l'autre
pour tes applications, et donc, les virus ne te rallentissent
plus autant.)

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


James Kanze
Le #309107
On Jul 23, 12:13 am, "Christophe Lephay" <christophe-
wrote:
"Sylvain" 46a3d486$0$25910$

Fabien LE LEZ wrote on 22/07/2007 20:10:

(Je précise que tous les fichiers de mes projets (sources, objets,
exe) tiennent largement en RAM, donc le disque dur ne reste pas
longtemps un goulot d'étranglement.)


qu'ils y tiennent est une chose, qu'ils y soient en est une autre.
utilises-tu un RAM disk ? non, alors tout repose sur le cache controleur
et le cache système, soit aucune certitude.


De toute façon, c'est le processeur et non le disque le
maillon faible pour une compilation...


Ça dépend. Avec un langage simple (genre C), et sans
l'optimisation, le goulot d'étranglement est bien la lecture de
la source. (Je ne sais pas ce qu'il en est maintenant. Quand
j'ai fait mes mesures, il s'agissait bien d'un compilateur C
sans optimisation.)

J'ai aussi l'expérience, plus tard, qu'un build passe de 4
heures à 20 minutes quand on le faisait tourner sur le serveur.
Beaucoup dépend du reseau.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34



James Kanze
Le #309106
On Jul 23, 12:05 am, Sylvain
Fabien LE LEZ wrote on 22/07/2007 20:10:
(Je précise que tous les fichiers de mes projets (sources, objets,
exe) tiennent largement en RAM, donc le disque dur ne reste pas
longtemps un goulot d'étranglement.)


qu'ils y tiennent est une chose, qu'ils y soient en est une autre.
utilises-tu un RAM disk ? non, alors tout repose sur le cache controleur
et le cache système, soit aucune certitude.


C'est à peu près ce que je me démande moi-même. Pour beaucoup,
le compilateur lit des données, puis il les traite. À part la
phase de l'optimisation, il n'y a pas besoin de garder beaucoup
en RAM. (Mais ça doit dépend du compilateur. J'ai eu un cas
récemment où g++ épuisait la mémoire, alors que je ne m'y serais
jamais attendu ; le « programme » consistait en beaucoup de
tableaux, aucun avec plus de 64 entrées. Il y avait bien quelque
dixaines de milliers de symboles, mais je crois pas que ça
aurait suffit à éclater la mémoire ; j'ai plutôt l'impression
que g++ a gardé tout en mémoire, plutôt que de vider chaque
tableau sur disque, au fur et à mesure.)

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


Christophe Lephay
Le #309104
"Michael DOUBEZ" 46a434ad$0$23935$
De toute façon, c'est le processeur et non le disque le maillon faible
pour une compilation...


Pas nécessairement, c'est pourquoi gcc a l'option -pipe qui permet
d'éviter la création de fichiers temporaires entre les phases de
compilation.


Tu as testé pour voir de quel ordre était le gain de temps ?


Rakotomandimby (R12y) Mihamina
Le #309881
Christophe Lephay -
De toute façon, c'est le processeur et non le disque le maillon faible
pour une compilation...
Pas nécessairement, c'est pourquoi gcc a l'option -pipe qui permet

d'éviter la création de fichiers temporaires entre les phases de
compilation.
Tu as testé pour voir de quel ordre était le gain de temps ?



Pas en benchmark formel, pour moi.
J'ai compilé une Gentoo entiere, en poste de travail avec KDE (donc Qt donc
C++, hop en charte,... :) ) sur un T7200, et les options "pipe" et "-jN"
(avec N de l'ordre de 8 pour le suffoquer) me donne un gain de l'ordre de
30% en temps de recompilation.

Pour calculer, j'ai d'abord dis au système de rapatrier les codes sources
necessaires, pour m'affranchir du temps de téléchargement. Il m'a semblé
que la phase de decompression des tarballs est celle ou l'on ne gagne rien.
Si on pre-desarchive le code, là on peut peut-etre beaucoup gagner... ou
pas.
--
"C'est très facile d'avoir des idées de partage quand on n'a rien."
Patrice KARATCHENTZEFF



Publicité
Poster une réponse
Anonyme