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.)
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
Fabien LE LEZ <gramster@gramster.com> writes:
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.
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
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
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.
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
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.
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.
(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
"Sylvain" a écrit dans le message de news: 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...
"Sylvain" <noSpam@mail.net> a écrit dans le message de news:
46a3d486$0$25910$ba4acef3@news.orange.fr...
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...
"Sylvain" a écrit dans le message de news: 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
"Sylvain" a écrit dans le message de news: 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
"Sylvain" <noSpam@mail.net> a écrit dans le message de news:
46a3d486$0$25910$ba4acef3@news.orange.fr...
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.
"Sylvain" a écrit dans le message de news: 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
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
On Jul 22, 9:17 pm, Falk Tannhäuser <tannhauser86549s...@free.fr>
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:james.kanze@gmail.com
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
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
On Jul 23, 12:13 am, "Christophe Lephay" <christophe- wrote:
"Sylvain" a écrit dans le message de news: 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
On Jul 23, 12:13 am, "Christophe Lephay" <christophe-
lep...@wanadoo.fr> wrote:
"Sylvain" <noS...@mail.net> a écrit dans le message de news:
46a3d486$0$25910$ba4ac...@news.orange.fr...
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:james.kanze@gmail.com
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
On Jul 23, 12:13 am, "Christophe Lephay" <christophe- wrote:
"Sylvain" a écrit dans le message de news: 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
On Jul 23, 12:05 am, Sylvain wrote:
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
On Jul 23, 12:05 am, Sylvain <noS...@mail.net> wrote:
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:james.kanze@gmail.com
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
(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
"Michael DOUBEZ" a écrit dans le message de news: 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 ?
"Michael DOUBEZ" <michael.doubez@free.fr> a écrit dans le message de news:
46a434ad$0$23935$426a74cc@news.free.fr...
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 ?
"Michael DOUBEZ" a écrit dans le message de news: 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
Christophe Lephay - <46a49328$0$25941$ :
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
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
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
