nproc gibt die Anzahl der verfügbaren CPU-Kerne/-Threads an, z. B. 8 auf einer Quad-Core-CPU, die bidirektionales SMT unterstützt.
Die Anzahl der Jobs, die Sie mit make parallel ausführen können mit -j Option hängt von mehreren Faktoren ab:
- die Menge an verfügbarem Speicher
- die Speichermenge, die von jedem
makeverwendet wird Arbeit - inwieweit
makeJobs sind E/A- oder CPU-gebunden
make -j$(nproc) ist ein anständiger Ausgangspunkt, aber Sie können normalerweise höhere Werte verwenden, solange Sie Ihren verfügbaren Speicher nicht erschöpfen und anfangen zu prügeln.
Für wirklich schnelle Builds empfehle ich, wenn Sie über genügend Speicher verfügen, die Verwendung eines tmpfs , auf diese Weise sind die meisten Jobs CPU-gebunden und make -j$(nproc) wird so schnell wie möglich funktionieren.
Der einfachste Weg ist die Verwendung von nproc etwa so:
make -j`nproc`
Der Befehl nproc gibt die Anzahl der Kerne auf Ihrem Computer zurück. Indem Sie es in die Häkchen packen, wird der nproc Der Befehl wird zuerst ausgeführt, gibt eine Zahl zurück und diese Zahl wird an make übergeben .
Möglicherweise haben Sie einige anekdotische Erfahrungen gemacht, bei denen das Ausführen von Core-Count + 1 zu schnelleren Kompilierungszeiten führt. Dies hat mehr mit Faktoren wie E/A-Verzögerungen, anderen Ressourcenverzögerungen und anderen Einschränkungen der Verfügbarkeit von Ressourcen zu tun.
Dazu mit nproc+1 , versuchen Sie Folgendes:
make -j$((`nproc`+1))
Leider können sogar verschiedene Teile desselben Builds mit widersprüchlichen Werten für den j-Faktor optimal sein, je nachdem, was gebaut wird, wie, welche der Systemressourcen zu diesem Zeitpunkt der Engpass sind, was sonst noch auf der Build-Maschine passiert, was darin vor sich geht das Netzwerk (wenn verteilte Build-Techniken verwendet werden), Status/Standort/Leistung der vielen Caching-Systeme, die an einem Build beteiligt sind, etc.
Das Kompilieren von 100 winzigen C-Dateien kann schneller sein als das Kompilieren einer einzigen riesigen oder umgekehrt. Das Erstellen von kleinem, stark verschachteltem Code kann langsamer sein als das Erstellen großer Mengen von einfachem/linearem Code.
Sogar der Kontext des Builds spielt eine Rolle - die Verwendung eines für Builds auf dedizierten Servern optimierten j-Faktors, der auf exklusive, nicht überlappende Builds abgestimmt ist, kann zu sehr enttäuschenden Ergebnissen führen, wenn er von Entwicklern verwendet wird, die parallel auf demselben gemeinsam genutzten Server bauen (jeder dieser Builds kann länger dauern Zeit als alle zusammen, wenn sie serialisiert sind) oder auf Servern mit unterschiedlichen Hardwarekonfigurationen oder virtualisiert.
Hinzu kommt der Aspekt der Korrektheit der Build-Spezifikation. Bei sehr komplexen Builds können Race-Conditions auftreten, die zeitweilige Build-Fehler mit Auftretensraten verursachen, die je nach Erhöhung oder Verringerung des j-Faktors stark variieren können.
Ich kann weitermachen. Der Punkt ist, dass Sie Ihre tatsächlich bewerten müssen in Ihren Kontext einbauen für die der j-Faktor optimiert werden soll. Der Kommentar von @ Jeff Schaller gilt:Iterieren Sie, bis Sie Ihre beste Anpassung gefunden haben. Persönlich würde ich mit dem nproc-Wert beginnen, zuerst nach oben und nach unten nur versuchen, wenn die Aufwärtsversuche eine sofortige Verschlechterung zeigen.
Es könnte eine gute Idee sein, zuerst mehrere identische Builds in vermeintlich identischen Kontexten zu messen, nur um eine Vorstellung von der Variabilität Ihrer Messungen zu bekommen - wenn sie zu hoch ist, könnte dies Ihren gesamten Optimierungsaufwand gefährden (eine 20%ige Variabilität würde eine 10%ige Verbesserung vollständig in den Schatten stellen/ Degradationsablesung in der j-Faktor-Suche).
Schließlich ist es meiner Meinung nach besser, einen (adaptiven) Jobserver zu verwenden, wenn er unterstützt und verfügbar ist, anstelle eines festen j-Faktors - er bietet durchgängig eine bessere Build-Leistung in einem breiteren Spektrum von Kontexten.