Compile Code

vb87

Komplett-PC-Aufrüster(in)
Hallo,

ich frage mich die letzten Tage, ob Programme wie z.B. "GNU Make" auch mit 32 oder 64 Kernen noch gut Skalieren. Zwischen 16 Threads und einem Thread merkt man dort einen sehr deutlichen Unterschied. Bei meine aktuell sehr kleinen Projekt habe ich eine Compile-Dauer von ca. 8,7s mit einem Thread, bei 16 Threads komm ich auf ca. 1,7s. Ich frage mich, wie es bei sehr großen Projekt ist? Skaliert es dort wirklich bis hinauf auf 128 Threads? Oder ist dort vorher schon ein Ende? Das ganze ist reines Interesse. Ich plane nicht meinen 5800X gegen einen TR zu ersetzen, da meine Hobby Projekte dafür zu klein sind.
 
Anandtech:
Die Linkphase ist afaik immer relativ SC lastig so dass im Endergebnis eher die dort stärkeren CPUs besser abschneiden. Die Ergebnisse von Anandtech sehen ausserdem so aus als gäbe es einen Punkt bei ~16Threads die Skalierung negativ wird.
Ich bin mir auch sicher auf einer Seite regelmäßig ein Chromium Kompilat als Benchmark gesehen zu haben, aber ich erinnere mich nicht wo.
Quasi jedes Buildsystem wird aber sowieso versuchen immer nur das neu zu kompilieren was sich geändert hat (bis sich irgendwas dabei verrennt und man erstmal 30Minuten den Heisenbug sucht bevor man ein Clean all versucht :crazy: ).
Edit: TPU hat auch einen Compile Benchmark:
Allerdings ist nicht klar was für eine "Medium sized Application" da gebaut wird (W1zzard hätte z.B. GPU-Z nehmen können, aber dann kann man es ja auch dran schreiben :wall:)
 
Zuletzt bearbeitet:
Danke @Olstyle für die Antwort.
Chromium hatte ich bei GamersNexus als Test gesehen. Aber zumindest auf seiner Homepage waren keine Aktuellen Daten mehr anzutreffen. Scheinbar nur noch in neueren Videos.
Hast du einen Link zu dem Beitrag bei Anandtech? Das Hört sich interessant an.
Quasi jedes Buildsystem wird aber sowieso versuchen immer nur das neu zu kompilieren was sich geändert hat (bis sich irgendwas dabei verrennt und man erstmal 30Minuten den Heisenbug sucht bevor man ein Clean all versucht :crazy: ).
Ja das ist mit bewusst/bekannt. Bei normaler Entwicklung baut man meist nur wenige Dateien neu.
 
Wie schnell gebaut werden kann hängt sehr stark vom compiler und dessen Konfiguration ab. Aus der Vergangenheit kennen ich es, das der compiler für den ARM core innerhalb von ein paar Minuten alles neu gebaut hat, der für die DSPs hat gern mal ne halbe Stunde gebraucht...
 
Jetzt bist du bei Cross-Compilern. Das ist nochmal ein anderes Thema. Dort ist es auch deutlich gängiger kommerzielle Produkte (IAR, Greenhills, etc. ) einzusetzen.
 
Da oben ist doch ein Link mit allen Anandtech Ergebnissen.
Etwas Text dazu findest du hier:
Bzw. dort ist wiederum ein Video mit einer etwas längeren Abhandlung über den Benchmark verlinkt.
Mein Fehler. Den Link hatte ich scheinbar nicht richtig zugeordnet. Die Ergebnisse finde ich sehr interessant. Den höchsten Durchsatz schafft der Prozessor mit 8 Kernen und dem höchsten Takt. Vom Gefühl her, hätte ich erwartet, dass das mehr mit der Anzahl der Kerne skaliert und ein Threadripper weit vorne liegt.

Ich trau den Daten von Anandtech net so ganz. Hab RISCV-GNU-Toolchain mal ausgecheckt und bau es mal selber und verschaffe mir mal ein Eindruck.
Aktuell sieht es aber eher so aus, als würden die Cores bei dem Build nicht umbedingt alle genutzt (Default-Build-Command wie im README), was natürlich das Ergebnis erklärt. Es gewinnt der Prozessor mit der höchsten SC Leistung.
 
Solche Anfängerfehler machen die bei dem Laden normalerweise nicht und das Ergebnis deckt sich auch mit dem von TPU.:ka:
 
Allerdings bleibt die Frage was genau da eigentlich limitiert. Ein Job pro File und damit theoretisch zumindest zeitweise Arbeit für genau so viele Threads ist ja quasi das Standardsetting und davon gibt es auch ohne riesen Projekt mehr als 32. Es könnte der I/O sein, also die SSD und/oder der RAM.
 
So wie es sich bei mir darstellt ist der default aufruf mit "make" der limitierende Faktor.
Ich habe das ganze nochmal mit "make -j16" laufen lassen und bekomme die gewünschte CPU-Auslastung von 100% bei einer HDD Auslastung von 28%. Zwischenzeitlich, vermutlich beim Linken, wird mal nur 1 Kern belastet.
 
Falsch läuft es keines Falls. Aber am Ende ist hier auch der genaue Ablauf unklar, was es für uns erstmal nicht 100% identisch nachstellbar macht.

Edit:
Wenn ich make 16 Kerne zuteile hab ich eine Laufzeit von ca. 5 Minuten. Damit komme ich deutlich über die 74 Compiles-per-Day
 
Zuletzt bearbeitet:
Ich hasse Video-Anleitungen, aber wahrscheinlich kommt es darin vor :haha:
Eingebundener Inhalt
An dieser Stelle findest du externe Inhalte von Youtube. Zum Schutz deiner persönlichen Daten werden externe Einbindungen erst angezeigt, wenn du dies durch Klick auf "Alle externen Inhalte laden" bestätigst: Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit werden personenbezogene Daten an Drittplattformen übermittelt.
Für mehr Informationen besuche die Datenschutz-Seite.
 
Ach das Video, was bei TPU verlinkt war :D

Ich hab jetzt nochmal reingeschaut. Und finde keine genaue Erklärung. Ich hab aber in den Kommentaren einige Hinweise gelesen, was den Build in Windows teilweise ausbremst. Ich hab das ganze in eine VM laufen, was sicher auch nicht optimal ist.
 
Zuletzt bearbeitet:
Ich hatte gestern nochmals 2 Vergleiche ausgeführt. Das System ist komplett auf der Platte und vor dem Build hab ich ein Clean ausgeführt. Anschließend den Build laufen lassen.
Aufruf 1: make -> Laufzeit 33m48,394s
Aufruf 2: make -j16 -> Laufzeit 5m39,943s
Der Parameter -j16 teilt make mit, dass es 16 Threads nutzen kann.

Bei Aufruf 1 ist so auch als Beispiel im Git-Repo angegeben. Damit bekomme ich eine Auslastung von ~10%
Bei Aufruf 2 bekomme ich dann eine Auslasstung von 100% der CPU.
 
Wenn ich die 73,6 "Compiles per Day" von Anandtech mit 24h umrechne komme ich auf 19,5min, also irgendwo dazwischen.
Wenn ich von deiner Laufzeit mit j16 rückwärts rechnen wiederum auf einen ~7 Stunden Arbeitstag. :what:
Letzteres könnte vielleicht sogar passen. So oder so, schlecht dokumentierte Tests sind die Hölle.
 
Zurück