4. Wie viel bringt Hyperthreading beim Kompilieren?

Wie viel bringt Hyperthreading beim Kompilieren?

  • 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

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

    0
  • ?

    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.

    0
  • V

    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.

    0
  • ?

    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.

    0
  • J

    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.

    0
  • ?

    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.

    0
  • M

    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.

    0
  • V

    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?

    0
  • M

    Nee, aber wir arbeiten im CAD/PDM Bereich und da ist es schon nicht verkehrt, entsprechend leistungsfähige Hardware zu haben. Komplexere Modelle zu generieren oder zu verarbeiten oder zu testen kann schon durchaus dauern.
    Wobei das Kompilieren unserer Software auch immer noch eine ganze Weile dauert. Zwar kein Vergleich zu dem Rechner, den ich davor hatte, aber trotzdem, ein Clean Build von allen unseren Komponenten, die man normal als Entwickler braucht dauert schon so 20-30 Minuten.

    0
Anmelden zum Antworten