Wie viel bringt Hyperthreading beim Kompilieren?

volkard

Und daß man endlich einen Thread pro Client benutzt, liegt mir am Herzen. Es ist in allen Fragen nicht lahmer (Komplexitätsklasse, Anzahl der Locks) als die verkrüppelten State-Machines und so, aber würde unglaublich viel bessere Software erlauben, weil sie unglaublich viel einfacher zu stricken ist.

Nur haut man derzeit noch (kaum!) mehr Anfragen mit Wahnsinnsprogrammieraufand und dergleichen durch. Alte Zöpfe.

dot

volkard schrieb:

Und daß man endlich einen Thread pro Client benutzt, liegt mir am Herzen.

Oder noch besser: I/O Completion Ports... :p

volkard

dot schrieb:

volkard schrieb:

Und daß man endlich einen Thread pro Client benutzt, liegt mir am Herzen.

Oder noch besser: I/O Completion Ports... :p

Eben nicht! Ratzewenig Gain, dafür müssen die Worker wieder komplexer werden.

hustbaer

@volkard
Vorausgesetzt du hast genug RAM für -j4711, dann würde es ziemlich sicher grob bremsen. Weil es viel weniger Cache-Freundlich ist als z.B. -j8.

Aber.
Bevor hier lange gestritten wird...: wer erklärt sich bereit nen Benchmark zu machen? Freiwillige?

Also, 30% durch HT wären ja schon mal ein Wort. Der i7 kostet etwa 40% mehr, das wäre dann preis-/leistungstechnisch voll in Ordnung.

Und ich bin es eigentlich auch gewohnt, dass mehr Threads als Hardware-Threads nichts bringen, weil die Rolle von I/O normalerweise vernachlässigbar ist.
Ich habe testweise gerade ein etwas größeres Projekt kompiliert (Wine):

make -j4: real 14m39.818s
make -j6: real 14m47.750s
make -j8: real 14m56.268s

Das ganze mit einem Phenom II X4 945.

Immer schön brav mit einer Runde drop_caches vor jedem Durchgang.

Wer keinen Haswell hat, darf natürlich auch testen... ich gehe mal davon aus, dass die Unterschiede zwischen den letzten paar Intel-Generationen jetzt nicht übermäßig dramatisch sein werden.

hustbaer

Achja, vorhin vergessen...

@volkard:
Beim Thema 1 Thread/Client sind wir uns einig! Weiss ich zwar schon lange, aber diese eine Urban-Legend ist so stark dass ich mich immer freue wenn jmd. anderer hier den selben Standpunkt vertritt wie ich

Erwähnenswert ist hier natürlich C# mit async/await.
Damit können wir endlich wieder im "one-thread-per-client" Stil programmieren, und unsere Programme sind trotzdem (mindestens) gleich langsam wie welche die async IO "zu fuss" machen.

hustbaer

http://www.anandtech.com/show/7003/the-haswell-review-intel-core-i74770k-i54560k-tested/6

Visual Studio 2012 - Build Mozilla Firefox:

i7 4470K 20.1 Minuten
i5 4670K 24.1 Minuten

Also der i7 ca. 20% schneller als der i5.
Wobei der i5 natürlich um 0.1 GHz langsamer läuft (3.4 statt 3.5) und nur 6 MB statt 8 MB 3rd level Cache hat.

7-Zip liegt er 36% vorn.
Cinebench 11.5 ca. 30%.

Ich freu mich auf jeden Fall schon mal auf meinen E3-1245 v3. Wird ein netter Sprung vom Q6600

volkard

hustbaer schrieb:

@volkard
Vorausgesetzt du hast genug RAM für -j4711, dann würde es ziemlich sicher grob bremsen. Weil es viel weniger Cache-Freundlich ist als z.B. -j8.

Aber.
Bevor hier lange gestritten wird...: wer erklärt sich bereit nen Benchmark zu machen? Freiwillige?

Ich messe mal ein wenig rum und schreibe mit.

volkard

Und hier die Messungen!

Im Rechner stecken 16G RAM. Er ist frisch gebootet.
Es laufen
X //grafische Oberfläche
ein Terminal //in Windows auch Konsole genannt
Scite //Texteditor

vh-main src # free
             total       used       free     shared    buffers     cached
Mem:      16340336     526060   15814276      21688        876     365104
-/+ buffers/cache:     160080   16180256
Swap:            0          0          0

Keine Auslagerungsdatei,
160M sind belegt, der Rest sind Plattencache oder einfach unbenutzt.

Es ist ein i7 mit 3.4GHz

vh-main linux # cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 42
model name	: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz
stepping	: 7
microcode	: 0x12
cpu MHz		: 3401.000
cache size	: 8192 KB
//Rest weggelassen
und so weiter

Nichts übertaktet.

Acht Prozessoren, vier Kerne mit Hyperthreading.

vh-main linux # cat /proc/cpuinfo | grep processor
processor	: 0
processor	: 1
processor	: 2
processor	: 3
processor	: 4
processor	: 5
processor	: 6
processor	: 7

Eine SSD ist eingebaut.
Anzahl der Dateien auf der SSD mal zählen...

time ( find / -xdev | wc -l )
1001254
real	0m10.924s
user	0m0.876s
sys	0m2.570s

Ungefähr 1Mio, dauert 10s von der SSD.

Gleich nochmal.

vh-main src # time ( find / -xdev | wc -l )
1001254
real	0m1.102s
user	0m0.426s
sys	0m0.715s

Und dauert 1s aus dem Cache.
Das ist beim Compilieren wohl vernachlässigbar.
//Wie lange wohl dir/s mit 1Mio Dateien unter Windows dauern würden?

Und die Anzeige geschieht über rxvt-unicode

time find / -xdev
//Eine Million Zeilen ausgelassen
real	0m5.718s
user	0m0.993s
sys	0m2.360s

ist also auch vernachlässigbar.
//Wie lange wohl 1Mio Zeilen auf die Konsole auszugeben unter Windows dauern würde?

Mal den Kernel ein erstes mal compilieren...

vh-main linux # make clean && time make -j1
//Ausgabe weggelassen
real	9m39.604s
user	9m3.625s
sys	0m33.014s

Nochmal...

vh-main linux # make clean && time make -j1
//Ausgabe weggelassen
real	9m36.542s
user	9m3.003s
sys	0m33.142s

Also vielleicht 3 Sekunden wegen wirgendwelcher Sachen mit dem Plattencache?

Nochmal...

vh-main linux # make clean && time make -j1
//Ausgabe weggelassen
real	9m36.553s
user	9m3.513s
sys	0m32.713s

Jo, so isses wohl.

Mal mit verschiedenen Prozessoranzahlen messen.
1 576.553 +0.00%
2 293.681 +1.87% gegenüber doppelt so schnell wie 1
3 200.666 +4.41%
4 156.743 +8.74%
Muss gar nix mit Overhead zu tun haben, sondern es gibt einfach Anteile, die nicht mit der Prozessorzahl skalieren, wie das anschleißende Erstellen und Packen des images.

5 148.013
6 139,562
7 132.156
8 129.121 21% mehr Leistung als 4

hustbaer schrieb:

Vorausgesetzt du hast genug RAM für -j4711, dann würde es ziemlich sicher grob bremsen. Weil es viel weniger Cache-Freundlich ist als z.B. -j8.

9 127.215 //ganz ein wenig schneller
10 126.839 //Optimum
11 127.319 //ja, der hustbaer-Performanceeinbruch kommt
12 128.072 //kommt ganz sicher aber recht langsam

Gerne wird empfohlen, 2*Prozessorzahl+1 zu nehmen. Mal da rummessen...

16 127.398
17 127.601 //ist Geschichte
18 128.971

Und jetzt aber endlich das riesige hustbaer-Loch suchen...
32 129.466
64 130.025
128 130.215 //Es ist weg, versteckt sich irgendwo, aber nicht bei mir.
4711 packt mein Rechner nicht, friert einfach ein.

Messungen ohne Hypterthreading:
4 153.073
5 151.750 //Optimum, HT bringt also 19.64% mehr Leistung
6 151.991

SeppJ schrieb:

volkard, wenn du eine Angabe ins Lächerliche verzerrst, dann ist es leicht, sie als Religion abzustempeln. Ein -j8 bringt sehr viel auf einem Vierprozessorsystem, probier es aus!

Soeben geschehen und Deine Angabe ist religiös.

SeppJ

volkard schrieb:

Soeben geschehen und Deine Angabe ist religiös.

Mit einem Rechner wie deinem vielleicht. Nicht jeder hat SSD und RAM ohne Ende. Oder will erstmal alle Daten in den RAM kopieren, was schließlich auch Zeit braucht. Selbst bei dir ist das Optimum immer noch bei einer Prozesszahl über der physischen Prozessorzahl.

volkard

SeppJ schrieb:

Mit einem Rechner wie deinem vielleicht.

Naja, daß Du "sehr" fett geschrieben hast, klang sehr nach etwas unumstößlichem, was jeder Anfänger frühzeitig lernen müsse. Außerdem hast Du mich aufgefordert, es auszumessen.

SeppJ schrieb:

Nicht jeder hat SSD

Naja, die bringt eher nur was beim ersten Compilerlauf, oder wenns RAM echt alle geht.

SeppJ schrieb:

und RAM ohne Ende.

Viel RAM ist einfach lecker.
Aber naja, der Linux-Kernel ist schon ein recht fettes Projekt, trotzdem uncompiliert 500M, compiliert 1G, so viel hat man eigentlich schon.

SeppJ schrieb:

Oder will erstmal alle Daten in den RAM kopieren, was schließlich auch Zeit braucht.

Passiert meistens von selber. Eigene Sachen compiliert man ja mehrmals, nur beim ersten mal müssen sie ins RAM hüpfen. Fremde Sachen muss ich vorher auspacken oder runterladen, da passiert's auch.

SeppJ schrieb:

Selbst bei dir ist das Optimum immer noch bei einer Prozesszahl über der physischen Prozessorzahl.

Jup. Seltsamerweise bei +2 und nicht bei +1. Wundert mich.
Aber ab Erreichen der Prozessorzahl bis zu exorbitanten Zahlen gehts nur um Prozentchen. Mit Drehplatte würde ich wohl doppelte Prozessorzahl nehmen. So nehme ich ab heute 10.

SeppJ

volkard schrieb:

SeppJ schrieb:

Mit einem Rechner wie deinem vielleicht.

Naja, daß Du "sehr" fett geschrieben hast, klang sehr nach etwas unumstößlichem, was jeder Anfänger frühzeitig lernen müsse.

Aber es bringt total viel! Außer wenn du den Test nicht so manipulierst, dass dein gewünschtes Ergebnis rauskommt. Den Code direkt so wie er ist von einer eher langsamen Quelle aus zu übersetzen ist ja wohl der Normalfall, wohingegen das vorherige Laden des Codes in den RAM die Ausnahme ist, die quasi nur dann vorkommt, wenn man tatsächlich mal mehrere Benchmarks nacheinander laufen lässt und vergleichbare Werte haben möchte (also so wie dein Test, der zumindest in dieser Hinsicht auch richtig ist).
Wenn du beim echten Übersetzen des Projekts erst ein find / -xdev | wc -l machst um alles in den RAM zu laden, dann magst du von der reinen Compilierzeit her zwar ungefähr gleich auf liegen, aber insegesamt bist du garantiert ein ganzes Ende langsamer als wenn du einfach direkt mit ein paar mehr Prozessen gleichzeitig compiliert hättest.

Naja, die bringt eher nur was beim ersten Compilerlauf, oder wenns RAM echt alle geht.
[...]
nur beim ersten mal müssen sie ins RAM hüpfen.
[...]
Mit Drehplatte würde ich wohl doppelte Prozessorzahl nehmen.

Eben! Wie oft übersetzt du die gleichen, unveränderten Dateien mehrmals hintereinander? Ungefähr 0 Mal nehme ich an, denn du bist nicht doof und verwendest Werkzeuge wie make & Co, die unnötige Mehrfachübersetzungen des gleichen Codes vermeiden.

Fremde Sachen muss ich vorher auspacken oder runterladen, da passiert's auch.

Interessant, das muss ich mal probieren, ob das wirklich schneller ist. Bisher hatte ich nicht den Eindruck, aber ich habe es nie gemessen (erhöhte Prozessorzahl habe ich aber schon gemessen^*, das bringt wirklich ordentlich was beim ersten Compilieren mit Drehplatte, was mMn der Normalfall ist).

^*: Ich muss zugeben, das ist um 2008 herum gewesen. Aber mein Rechner war damals nicht wesentlich anders als mein heutiger. Die Festplatte war natürlich nochmals ein ganzes Stück lahmer als heute, verglichen mit einer SSD.

hustbaer

@volkard
Interessant!
Ich hätte wirklich geglaubt dass man mit sehr vielen Threads/Prozessen einen spürbaren Nachteil hätte...
Sieht man mal wieder wie man sich verschätzen kann.

volkard schrieb:

SeppJ schrieb:

und RAM ohne Ende.

Viel RAM ist einfach lecker.

Also bei uns sind die Entwicklungsrechner mit 16GB die, die wenig RAM haben.

volkard

SeppJ schrieb:

Aber es bringt total viel! Außer wenn du den Test nicht so manipulierst,

Du bist heute ungewohnt uneinsichtig.

SeppJ schrieb:

Den Code direkt so wie er ist von einer eher langsamen Quelle aus zu übersetzen ist ja wohl der Normalfall,

Totaler Unfug.

SeppJ schrieb:

Wenn du beim echten Übersetzen des Projekts erst ein find / -xdev | wc -l machst um alles in den RAM zu laden,

Das hat nur den Verzeichnisbaum geladen, vom gesamten Linux in 10s. Vom Kernel wäre es vielleicht 1s, also wieder nur Prozentchen.

SeppJ schrieb:

Wie oft übersetzt du die gleichen, unveränderten Dateien mehrmals hintereinander? Ungefähr 0 Mal nehme ich an, denn du bist nicht doof und verwendest Werkzeuge wie make & Co, die unnötige Mehrfachübersetzungen des gleichen Codes vermeiden.

Wie oft übersetze ich Daten, die noch im Plattencache sind? IMMER! Ich hab sie ja gerade erst editiert und die IDE hat sie nur zum compilieren gerade mal rausgeschrieben. Oder es ist Fremdcode, den habe ich gerade komplett mit git oder svn geholt oder als .tar.bz2 runtergeladen und ausgepackt. In allen Fällen sind die Dateien noch im Festplattencache.

SeppJ schrieb:

(erhöhte Prozessorzahl habe ich aber schon gemessen^*, das bringt wirklich ordentlich was beim ersten Compilieren mit Drehplatte, was mMn der Normalfall ist).

Naja, das ist wohl dann einfach ein Unterschied zwischen uns. Die Meinung über den Normalfall. Ich lade Sachen direkt vor dem Benutzen runter und packe sie aus oder compiliere direkt nach dem Ändern. Du lädst anscheinend am Tage zuvor und editierst am Tage zuvor, bevor Du compilierst. Das ist mir nicht verständlich.

SeppJ schrieb:

^*: Ich muss zugeben, das ist um 2008 herum gewesen.

2004/2005 mit Singleprozessor, Drehplatte (5400rpm,leise,lahm,kalt,perfekt!), und (damals üppigen,ich mag viel ram) 2G Ram hatte ich schon keine Probleme mehr. Ich weiß echt nicht, was Du anstellst, um normalerweise Code zu compilieren, der nicht noch im Plattencache liegt.

Abgesehen davon darf man den Rechner in Standby tun über Nacht statt auszuschalten. Frißt gerade ebensoviel Watt wie ausgemacht, bei alten Rechnern vielleicht 3W, Moni 1W, zusammen <8€/Jahr, bei neuen gehts unter die Erkennungsschwelle von Baumarktenergieverbrauchsmessgeräten. Spätestens dann sollte der Code aber meistens im Plattencache liegen.

Oder Du hast so wenig RAM bzw so herausfordernde Aufgaben^*, daß Du regelmäßig das RAM komplett belegst und sogar ein Bißchen auf die Auslagerungsdatei gehen musst.

^* Muss nicht gleich berechnen hochdimensionaler Matrizen sein, ein Browsergame mit Speicherloch im Firefox zündet da viel mehr.

volkard schrieb:

Mal den Kernel ein erstes mal compilieren...
vh-main linux # make clean && time make -j1
//Ausgabe weggelassen
real	9m39.604s
user	9m3.625s
sys	0m33.014s
9 127.215 //ganz ein wenig schneller
10 126.839 //Optimum
11 127.319 //ja, der hustbaer-Performanceeinbruch kommt
12 128.072 //kommt ganz sicher aber recht langsam

Gerne wird empfohlen, 2*Prozessorzahl+1 zu nehmen. Mal da rummessen...

16 127.398
17 127.601 //ist Geschichte
18 128.971

Das Optimum hängt wohl vom Verhältnis CPU-Zeit / Festplattenzeit ab.

Jester

Volkards experimente sind schonmal gut, jetzt sollte man noch ne varianzanalyse machen, ich glaube dass sich die interpretation nicht wirklich halten lässt. Die winzigen unterschiede lassen imo aufgrund von messungenauigkeiten garnicht drauf schließen wo genau das echte optimum (nicht das vom vorliegenden lauf) liegt.

Insbesondere die behauptung, dass 2*prozessorzahl+2 inzwischen unsinnig ist lässt sich mit den daten imo nicht belegen.

Abgesehen davon das es echte Unterschiede geben kann sobald sich die Ramgröße ändert. Hier muss man halt ausprobieren.

Danke für die Mühe.

Es gab mal Zeiten da habe ich meinen Rechner die Nacht durchlaufen lassen um Gentoo-Linux Stage1 zu kompilieren. Heute macht man das in wenigen Stunden.
Für einen Privatmann spielt man doch hier nur mit Nuancen, trotzdem interessant zu wissen.

Mechanics

SeppJ schrieb:

Mit einem Rechner wie deinem vielleicht.

Ist jetzt eigentlich nichts besonderes, so einen hab ich in der Arbeit auch, hat bei uns mittlerweile fast jeder.

volkard

Mechanics schrieb:

SeppJ schrieb:

Mit einem Rechner wie deinem vielleicht.

Ist jetzt eigentlich nichts besonderes, so einen hab ich in der Arbeit auch, hat bei uns mittlerweile fast jeder.

Meiner ist 2.5 Jahre alt, hat aber damals zusammen einen Tausi gekostet, damals waren die i7 langsam erschwinglich geworden, hab ansonsten in die Vollen gegriffen, damit alles geschmeidig zusammenpasst. Und es passt perfekt, freue mich immernoch bei jedem Compilerlauf. Sollte heute um einiges billiger sein. Hab echt noch keinen Plan, wie ich ihn auslaste, oder warum ich jemals einen fetteren Rechner bräuchte.

Wer als Arbeitgeber seine Programmierer nicht mit halbwegs anständiger Hardware versorgt, zahlt halt Lohn dafür, daß sie auf den Compiler warten. Wie überaus sinnlos, wo die Löhne so teuer sind und die Hardware so billig, allein bei jeder Klitsche in der ich war, hatte ich Krüppelhardware, außer in hochschulnahen Instituten.

Sag an, Mechanics, Dein Unternehmen ist nicht zufällig auch hochschulnah?