C-Compilier-Maschine: Intel oder AMD?

[jal2]

@elensar
Danke für den Testlauf!

Das sollte nochn paar Minuten rausholen

Er lag schon unter einer Minute:

real 0m57.806s

 

[blafoo]

Du weist was ich damit sagen wollte

 

[elensar]

Befehl war time make -j64

Muss ich den buildcache extra angeben?

Hatte jetzt alles in einer 10GB ramdisk laufen, kein unterschied.

.config unter http://www.wepaste.com/thinkpad-forum/

leeres Passwort....

 

[blafoo]

So ik compilier

Grüße

*EDIT sagt*

8 x 4,4GHz (Core i7 2600k, also weniger Cache als der genannte Opteron, und "nur" HT anstelle von reelen Kernen), nebenbei lief halt KDE auf 3 Monitoren + surfen hier im Forum

8GB vom Ram (2133er, der auch als solches läuft) auf /tmp, welches als Buildcache dient.

Kernel 3.11.5

make -j 12, bei der oben genannten Config:

real    5m16.416s
user    35m36.080s
sys     1m59.593s

make -j8, bei oben genannter Config:

real    5m17.685s
user    34m29.400s
sys     1m56.033s

make -j10, bei oben genannter Config:

real    5m17.796s
user    35m21.153s
sys     1m59.500s

D.h., hochgerechnet, wäre der i7 schneller, hab schließlich 8x weniger Cores (und ja mit -j12 hab ich mir keine so große Freunde gemacht wie gedacht, die alte Gentoo regel: Core x 1,5, zaehlt wohl nimma

Wenn die CPU auf "normal" Takt läuft, was mit Turboboost entweder 3,6 oder 3,8Ghz sind, dürfte zwar noch mal ein paar Sekunden drauf kommen, schätz so 30, aber selbst das wäre rechnerisch schneller als der AMD.
Kann das aber gerne auch noch testen

Grüße

 

[elensar]

Jetzt interressiert mich aber die skalierung:
-j
1 geht nicht
2 real 12m14.758s
4 real 6m40.841s
8 real 4m18.441s
16 real 2m12.480s
32 real 1m16.629s
48 real 1m2.110s
64 real 0m57.806s

schade, für mehr Kerne bräuchte ich MPI und das frist zuviel timing.

 

[blafoo]

Frage die mich zusätzlich stellt:

Bei z.B. 8 Threads, werden die komplett auf einer CPU gemacht, oder werden die schön verteilt?

Weil pro CPU je 2 Threads wäre natürlich bei nem MultiProzessor-System traumhaft, alleine weil "nur" 2 Threads sich die 16mb pro Prozessor Cache teilen müssten.

So hast du dann effektiv 64mb Cache für 8 Threads wo ich mit ähm glaube 12 oder 16mb liebäugeln muss.

Grüße

 

[cuco]

Jein. Zwar kann dann jede CPU den Cache ausnutzen und falls vorhanden noch den Turbo voll ausreizen. Aber dafür müssen sich die CPUs auch "untereinander absprechen". Je nachdem, wie viel die Threads untereinander austauschen müssen. Das kann gar nichts sein (Bestfall) oder auch ziemlich viel - dann ist es deutlich schneller, die Sachen auf einer CPU auszuführen, da die Kommunikation unter den CPUs deutlich langsamer ist als unter den Kernen einer CPU.

 

[blafoo]

Daran hab ich auch gedacht

Vielleicht hat elensar nichts zu tun und baut den Kernel mit make -j4 in Vollbestückung und einmal nur mit einer CPU verbaut *hüstel*

 

[jal2]

Vielleicht hat elensar nichts zu tun und baut den Kernel mit make -j4 in Vollbestückung und einmal nur mit einer CPU verbaut *hüstel*

Kann man unter Linux nicht die Anzahl der CPU beim Booten begrenzen?

 

[blafoo]

So adhoc wüsste ich das gar nicht.

Die Frage ist ob er wirklich CPUs/Kerne oder Threads begrenzt und wir dann wieder bei dem Problem sind und wir nicht wissen wo der einzelne Thread geraade wirklich ist ^^

 

[elensar]

Angeblich kann man dass mit Taskset machen:

time taskset -c 0,16,32,48 make -j 4
real 8m7.463s


50 und 51 waren als Reserve gedacht falls die Kerne gerade was anderes tun, vermute dass Linux bei Kern 0 anfängt die Programme zuzuordnen.
time taskset -c 0,1,16,17,32,33,48,49,50,51 make -j 8
real 5m32.277s

time taskset -c 32-47 make -j 8
real 4m37.024s

Scheinbar macht der Linux interne Scheduler irgendwas besser.

Achso, auseinanderbauen geht, nicht, die Kiste ist im Serverraum fest eingebaut.

Neustarten kostet auch schon 10min arbeit, werde ich auch nicht tun.

 

[cuco]

Kann/Muss man da nicht auch noch alle Besonderheiten von NUMA beachten dann? Aber ich habe noch nie mit einer Multi-CPU-Maschine gearbeitet, ich schieße hier also mit gefährlichem und rein theoretischem Halbwissen um mich

 

[haarp]

Probier doch mal den Brain Fuck Scheduler (http://ck.kolivas.org/patches/bfs/), der skaliert noch ein Stück anders und könnte noch ein Stück rausholen. Vor allem hier noch mal mit der Zahl der Jobs spielen.

Und auch wenn du nicht übertakten willst, würde ich dennoch empfehlen eine K-Edition zu nehmen und die TDP anzuheben. Das kann einen enormen Unterschied machen, gibt es doch dem Turbo mehr Luft, was vor allem bei vollast auf allen Kernen einen deutlichen Vorteil bringt.

Letztlich würde ich auch noch empfehlen das ganze in tmpfs zu legen, um den Flaschenhals schön immer nahe der CPU zu halten.