Le Tue, 05 Jun 2012 20:39:50 +0000, Nicolas George a écrit:
À moins de compiler un monstre, l'arbre de compilation tient entièrement en RAM.
Certes. Mais dans ce cas, que ton gcc soit compilé en 486 ou core2, ça ne fera pas beaucoup de différence non plus :)
Gcc compilé en 486 va utilisé les 2 cores?
Sergio
Le Wed, 06 Jun 2012 09:09:52 +0200, lunix a écrit :
À moins de compiler un monstre, l'arbre de compilation tient entièrement en RAM.
Certes. Mais dans ce cas, que ton gcc soit compilé en 486 ou core2, ça ne fera pas beaucoup de différence non plus :)
Gcc compilé en 486 va utilisé les 2 cores?
Je ne connais pas les entrailles de gcc, mais pourquoi pas ? Le code peut être optimisé pour un type de processeur et/ou utiliser des instructions spécifiques à ce type, mais la répartition des processus sur les processeurs se fait par l'OS. Si gcc est multithread, il n'y a pas de raison.
Et il a bien du exister des machines multiprocesseurs à base de 486...
Le Wed, 06 Jun 2012 09:09:52 +0200, lunix a écrit :
À moins de compiler un monstre, l'arbre de compilation tient
entièrement en RAM.
Certes. Mais dans ce cas, que ton gcc soit compilé en 486 ou core2, ça
ne fera pas beaucoup de différence non plus :)
Gcc compilé en 486 va utilisé les 2 cores?
Je ne connais pas les entrailles de gcc, mais pourquoi pas ? Le code peut
être optimisé pour un type de processeur et/ou utiliser des instructions
spécifiques à ce type, mais la répartition des processus sur les
processeurs se fait par l'OS. Si gcc est multithread, il n'y a pas de
raison.
Et il a bien du exister des machines multiprocesseurs à base de 486...
Le Wed, 06 Jun 2012 09:09:52 +0200, lunix a écrit :
À moins de compiler un monstre, l'arbre de compilation tient entièrement en RAM.
Certes. Mais dans ce cas, que ton gcc soit compilé en 486 ou core2, ça ne fera pas beaucoup de différence non plus :)
Gcc compilé en 486 va utilisé les 2 cores?
Je ne connais pas les entrailles de gcc, mais pourquoi pas ? Le code peut être optimisé pour un type de processeur et/ou utiliser des instructions spécifiques à ce type, mais la répartition des processus sur les processeurs se fait par l'OS. Si gcc est multithread, il n'y a pas de raison.
Et il a bien du exister des machines multiprocesseurs à base de 486...
Emmanuel Florac
Le Tue, 05 Jun 2012 22:52:25 +0000, Nicolas George a écrit:
Certes. Mais dans ce cas, que ton gcc soit compilé en 486 ou core2, ça ne fera pas beaucoup de différence non plus
Euh... tu peux expliciter ton raisonnement ?
Tu passeras d'une compilation de 3 secondes à une compilation de 2 secondes?
-- The question of whether computers can think is just like the question of whether submarines can swim. Edsger W. Dijkstra
Le Tue, 05 Jun 2012 22:52:25 +0000, Nicolas George a écrit:
Certes. Mais dans ce cas, que ton gcc soit compilé en 486 ou core2, ça
ne fera pas beaucoup de différence non plus
Euh... tu peux expliciter ton raisonnement ?
Tu passeras d'une compilation de 3 secondes à une compilation de 2
secondes?
--
The question of whether computers can think is just like the question
of whether submarines can swim.
Edsger W. Dijkstra
Le Tue, 05 Jun 2012 22:52:25 +0000, Nicolas George a écrit:
Certes. Mais dans ce cas, que ton gcc soit compilé en 486 ou core2, ça ne fera pas beaucoup de différence non plus
Euh... tu peux expliciter ton raisonnement ?
Tu passeras d'une compilation de 3 secondes à une compilation de 2 secondes?
-- The question of whether computers can think is just like the question of whether submarines can swim. Edsger W. Dijkstra
Nicolas George
Emmanuel Florac , dans le message <4fcf0bc6$0$21938$, a écrit :
Tu passeras d'une compilation de 3 secondes à une compilation de 2 secondes?
Même avec des trucs dans le cache, un projet un peu gros peut prendre plusieurs minutes à compiler. Quand je recompile ffmpeg from scratch (ce qui peut s'éviter souvent en utilisant ccache, mais dès qu'il y a un changement dans les headers centraux c'est mort), il faut compter cinq bonnes minutes sur ma machine.
Emmanuel Florac , dans le message
<4fcf0bc6$0$21938$426a74cc@news.free.fr>, a écrit :
Tu passeras d'une compilation de 3 secondes à une compilation de 2
secondes?
Même avec des trucs dans le cache, un projet un peu gros peut prendre
plusieurs minutes à compiler. Quand je recompile ffmpeg from scratch (ce qui
peut s'éviter souvent en utilisant ccache, mais dès qu'il y a un changement
dans les headers centraux c'est mort), il faut compter cinq bonnes minutes
sur ma machine.
Emmanuel Florac , dans le message <4fcf0bc6$0$21938$, a écrit :
Tu passeras d'une compilation de 3 secondes à une compilation de 2 secondes?
Même avec des trucs dans le cache, un projet un peu gros peut prendre plusieurs minutes à compiler. Quand je recompile ffmpeg from scratch (ce qui peut s'éviter souvent en utilisant ccache, mais dès qu'il y a un changement dans les headers centraux c'est mort), il faut compter cinq bonnes minutes sur ma machine.
Emmanuel Florac
Le Wed, 06 Jun 2012 09:09:52 +0200, lunix a écrit:
Gcc compilé en 486 va utilisé les 2 cores?
Oui, si tu fais "make -j2" ou plus, make lance plusieurs gcc en parallèle, qui vont se répartir sur les coeurs disponibles.
-- It is better to remain silent and be thought a fool than to open one's mouth and remove all doubt. Abraham Lincoln.
Le Wed, 06 Jun 2012 09:09:52 +0200, lunix a écrit:
Gcc compilé en 486 va utilisé les 2 cores?
Oui, si tu fais "make -j2" ou plus, make lance plusieurs gcc en
parallèle, qui vont se répartir sur les coeurs disponibles.
--
It is better to remain silent and be thought a fool than to open one's
mouth and remove all doubt.
Abraham Lincoln.
Le Wed, 06 Jun 2012 09:09:52 +0200, lunix a écrit:
Gcc compilé en 486 va utilisé les 2 cores?
Oui, si tu fais "make -j2" ou plus, make lance plusieurs gcc en parallèle, qui vont se répartir sur les coeurs disponibles.
-- It is better to remain silent and be thought a fool than to open one's mouth and remove all doubt. Abraham Lincoln.
leeed
Le 04-06-2012, Nicolas Richard a écrit :
Le Mon, 04 Jun 2012 11:22:29 +0200, lunix disait :
Donc gcc compilé avec -march=core2 ou sans rien en generic va s’exécuté avec la même rapidité?
Je n'en ai aucune idée. On peut espérer que gcc soit au moins aussi efficace lorsqu'il a été compilé spécifiquement pour ton architecture, mais même ça je me demande parfois si c'est évident. Mais je suis comme toi sur ce point : je sais à peine comment fonctionne un compilateur.
Et make -j3 pour compiler ça accélère?
Eh bien si tu as plusieurs processeurs, oui, ça devrait. Cela dit à partir d'un certain nombre de processeurs, je suspecte que le goulot d'étranglement est ailleurs. Là encore, je n'en sais fondamentalement rien.
Ça me fait penser à un article de Linus Torvalds assez récent. Apparemment il compile avec -j16 (de mémoire) sur un Core2Duo tout ce qu'il y a de plus classique. Et les gains ne sont pas négligeables, par contre la consommation de mémoire sera beaucoup plus importante qu'avec un -j2 par exemple. (là encore, de mémoire, Linus a 8Go de RAM sur sa machine).
Le 04-06-2012, Nicolas Richard <theonewiththeevillook@yahoo.fr> a écrit :
Le Mon, 04 Jun 2012 11:22:29 +0200, lunix disait :
Donc gcc compilé avec -march=core2 ou sans rien en generic va s’exécuté
avec la même rapidité?
Je n'en ai aucune idée. On peut espérer que gcc soit au moins aussi
efficace lorsqu'il a été compilé spécifiquement pour ton architecture,
mais même ça je me demande parfois si c'est évident. Mais je suis comme
toi sur ce point : je sais à peine comment fonctionne un compilateur.
Et make -j3 pour compiler ça accélère?
Eh bien si tu as plusieurs processeurs, oui, ça devrait. Cela dit à
partir d'un certain nombre de processeurs, je suspecte que le goulot
d'étranglement est ailleurs. Là encore, je n'en sais fondamentalement
rien.
Ça me fait penser à un article de Linus Torvalds assez récent.
Apparemment il compile avec -j16 (de mémoire) sur un Core2Duo tout ce
qu'il y a de plus classique. Et les gains ne sont pas négligeables, par
contre la consommation de mémoire sera beaucoup plus importante qu'avec
un -j2 par exemple. (là encore, de mémoire, Linus a 8Go de RAM sur sa
machine).
Le Mon, 04 Jun 2012 11:22:29 +0200, lunix disait :
Donc gcc compilé avec -march=core2 ou sans rien en generic va s’exécuté avec la même rapidité?
Je n'en ai aucune idée. On peut espérer que gcc soit au moins aussi efficace lorsqu'il a été compilé spécifiquement pour ton architecture, mais même ça je me demande parfois si c'est évident. Mais je suis comme toi sur ce point : je sais à peine comment fonctionne un compilateur.
Et make -j3 pour compiler ça accélère?
Eh bien si tu as plusieurs processeurs, oui, ça devrait. Cela dit à partir d'un certain nombre de processeurs, je suspecte que le goulot d'étranglement est ailleurs. Là encore, je n'en sais fondamentalement rien.
Ça me fait penser à un article de Linus Torvalds assez récent. Apparemment il compile avec -j16 (de mémoire) sur un Core2Duo tout ce qu'il y a de plus classique. Et les gains ne sont pas négligeables, par contre la consommation de mémoire sera beaucoup plus importante qu'avec un -j2 par exemple. (là encore, de mémoire, Linus a 8Go de RAM sur sa machine).
Ah oui, j'avais lu ça sur google+ (c'est probablement la seule chose q ue j'aie jamais lue sur G+, et il faut que quelqu'un en parle sur usenet...)
Je cite Linus :
Heh. +Alan Cox was complaining about Android taking a long time to download and compile. "hours" and "going out to lunch".
I must have ADHD, because I'm profiling the kernel build process where "make -j32" from a clean tree on my config takes 19 seconds, and I want to shave it down a bit more.
(un peu plus tard) :
no, two cores with HT (four threads).
And enough memory to keep everything in RAM, together with ccache and an unhealthy amount of time spent on making sure pathname lookup is really really fast.
And I don't build modules I don't have. I do the occasional "build everything" just to make sure things don't break, but what I care about is what I can actually boot and test, so that's the thing I build all the time.
Ah oui, j'avais lu ça sur google+ (c'est probablement la seule chose q ue
j'aie jamais lue sur G+, et il faut que quelqu'un en parle sur
usenet...)
Je cite Linus :
Heh. +Alan Cox was complaining about Android taking a long time to
download and compile. "hours" and "going out to lunch".
I must have ADHD, because I'm profiling the kernel build process where
"make -j32" from a clean tree on my config takes 19 seconds, and I want
to shave it down a bit more.
(un peu plus tard) :
no, two cores with HT (four threads).
And enough memory to keep everything in RAM, together with ccache and an
unhealthy amount of time spent on making sure pathname lookup is really
really fast.
And I don't build modules I don't have. I do the occasional "build
everything" just to make sure things don't break, but what I care about
is what I can actually boot and test, so that's the thing I build all
the time.
Ah oui, j'avais lu ça sur google+ (c'est probablement la seule chose q ue j'aie jamais lue sur G+, et il faut que quelqu'un en parle sur usenet...)
Je cite Linus :
Heh. +Alan Cox was complaining about Android taking a long time to download and compile. "hours" and "going out to lunch".
I must have ADHD, because I'm profiling the kernel build process where "make -j32" from a clean tree on my config takes 19 seconds, and I want to shave it down a bit more.
(un peu plus tard) :
no, two cores with HT (four threads).
And enough memory to keep everything in RAM, together with ccache and an unhealthy amount of time spent on making sure pathname lookup is really really fast.
And I don't build modules I don't have. I do the occasional "build everything" just to make sure things don't break, but what I care about is what I can actually boot and test, so that's the thing I build all the time.
