Wie viel bringt Hyperthreading beim Kompilieren?

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?

Mechanics

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.