4. Wie viel bringt Hyperthreading beim Kompilieren?

Wie viel bringt Hyperthreading beim Kompilieren?

  • ?

    Also der Unterschied von make -j4 auf einem Core i5 4670 zu einem make -j8 auf einem Core i7 4770 ODER der Unterschied zwischen letzterem mit und ohne aktiviertem HT.

    Bisher habe ich Werte für einen single-core Atom gefunden (33% schneller), für einen Westmere (4% schneller, aber die Testmethoden waren mir etwas undurchsichtig), aber noch keine für Haswell. Hat da jemand welche, aus eigenen Messungen oder einen Artikel?

    0
  • ?

    AMD Phenom 2 X4
    Linux Kernel mit -j8 fast die Hälfte der Zeit nur noch.
    Auch sonstige Kompilierung geschätzt >30% schneller. Keine Messungen.
    Kommt auch die Software an.

    0

  • Nun stellt sich die Frage, welcher Anteil da auf Hyperthreading zurückzuführen ist und was auf andere Effekte, wie z.B. I/O Latency Hiding... 😉

    0
  • Mod

    dot schrieb:

    Nun stellt sich die Frage, welcher Anteil da auf Hyperthreading zurückzuführen ist und was auf andere Effekte, wie z.B. I/O Latency Hiding... 😉

    Korrekt. Mit -j8 ist man nämlich auf dem 4 Prozessorsystem auch viel schneller als mit -j4. Man müsste immer -j8 benutzen, einmal mit HT eingeschaltet und einmal ausgeschaltet. Und dann hängt das Ergebnis sicherlich auch noch von dem ab, was man compiliert.

    Ich habe aber gerade nicht die Muße, um entsprechende Experimente durchzuführen. außerdem verlangt der TE ja ausdrücklich Tests für Haswell, mein i7 hat aber AFAIK eine Westmere-Architektur. Wenn er mir ein passendes Upgrade spendiert, schreib ich ihm auch eine Forschungsarbeit zu dem Thema 🙂 .

    0
  • V

    Bei meinem I7 sinds auch ca 30%.

    0
  • V

    SeppJ schrieb:

    Man müsste immer -j8 benutzen, einmal mit HT eingeschaltet und einmal ausgeschaltet.

    Gar nicht. -j100 oder -j4711 ändert wenig. Die Threads und Prozesse werden so verflixt schnell angelegt, alles wird gut; pro Connection ein Thread war es schon vor 15 Jahren, wenn man auf wenige Prozent kackte und mit weniger als 10k Connections leben konnte, und da es jetzt keine Maximalanzahl mehr gibt, …

    Diese Angaben, die sagen was wie "Kerne*2+1" seien optimal oder mit HT halt fast doppelt so viel, die schreiben gegenseitig ab mangels besseren Wissens. Oh, eine Religion. 🤡

    0
  • Mod

    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! Das ist keine Aussage darüber, wie -j100 oder -j4711 sich verhalten.

    0
  • V

    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! Das ist keine Aussage darüber, wie -j100 oder -j4711 sich verhalten.

    Bin gewohnt, daß das Projekt ganz ins RAM passt. Und es wird vorher nach /tmp aufgepackt. Da bringt auf einem Vierprozessorsystem(womit 4 Kerne ohne HT oder 2 mit HT meine) -j5 nicht spürbar mehr als -j4. Mag sein, daß mit lahmer Platte dann -j5 statt -j4 greift (würde ich sogar stark vermuten). Aber -j4711 dürfte meinen Erfahrungen nach recht wenig ändern.
    Ich habe keine Beobachtung, wo -j signifikant was ändern würde, außer den trivialen
    - -j{weniger als Kerne+HT}
    - -j{sprengt den Speicher}

    Und ich beobachte eigentlich sowas recht streng, man mag mich da einen Nerd nennen.

    Ich hatte nicht die Absicht, etwas lächerlich zu machen, sondern wollte nur betonen.

    0
  • V

    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.

    0

  • volkard schrieb:

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

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

    0
  • V

    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.

    0

  • @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?

    0
  • ?

    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.

    0

  • 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. 👍 🤡

    0

  • 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 🙂

    0
  • V

    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.

    0
  • V

    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.

    0
  • Mod

    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.

    0
  • V

    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.

    0
  • Mod

    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.

    0
Anmelden zum Antworten