Warum empfehlen die Leute die Option -j3 für make, wenn sie eine Dual-Core-CPU haben?


18

In Gentoo Linux ist es möglich, die MAKEOPTSVariable so einzustellen /etc/portage/make.conf, dass angegeben wird, makewie viele Jobs beim Erstellen von Paketen parallel ausgeführt werden sollen. Da ich eine Dual-Core-CPU habe, habe ich mich naiv für die -j2Option entschieden: ein Job pro Core, damit beide etwas zu tun haben. Das "Problem" ist, dass es viele Referenzen gibt, die Benutzern mit einer Dual-Core-CPU sagen, dass sie die -j3Option stattdessen einstellen sollen . Einige von ihnen sind:

Zum Beispiel heißt es im Gentoo Handbuch:

Eine gute Wahl ist die Anzahl der CPUs (oder CPU-Kerne) in Ihrem System plus eine, aber diese Richtlinie ist nicht immer perfekt.

Aber was ist die Begründung für die Regel "CPUs + 1"? Warum der Nebenjob?

Die Manpage make.conf (5) sagt sogar:

Empfohlene Einstellungen liegen zwischen CPUs + 1 und 2 * CPUs + 1.

Ich habe auch Abschnitt 5.4 (Parallele Ausführung) auf der makeInfoseite und in der Manpage makezur -jOption gelesen , aber es scheint, als gäbe es dort keine Antworten.



Antworten:


13

Es gibt keine einfache Regel, die immer funktioniert. Die Leute empfehlen möglicherweise eine bestimmte Figur, weil sie mit einer bestimmten Zusammenstellung auf einer bestimmten Maschine experimentiert haben und dies die beste Einstellung war, oder weil sie einer Überlegung gefolgt sind, die möglicherweise in irgendeiner Beziehung zur Realität steht oder nicht.

Wenn Sie mit viel RAM gesegnet sind, ist der begrenzende Faktor für eine lange Kompilierung die CPU-Zeit. Dann ist eine Task pro CPU plus eine anstehende Task für diese gelegentlichen E / A-Blöcke eine gute Einstellung. Das macht es -j3für eine Dual-Core-CPU (oder genauer gesagt für eine Dual-CPU-Maschine - wenn jeder Kern über ein Hyperthread verfügt, sind das also 4 CPUs -j5).

Wenn Sie nur über sehr wenig RAM verfügen, kann dies ein begrenzender Faktor sein, dass nicht viele Jobs gleichzeitig ausgeführt werden können. Andernfalls werden die Jobs weiterhin gegeneinander ausgetauscht. Wenn Sie beispielsweise zwei Compiler-Instanzen nicht bequem in den Speicher einfügen können, ist dies make -j2möglicherweise bereits langsamer als make. Da dies davon abhängt, wie viele Compiler-Prozesse gleichzeitig in den Arbeitsspeicher passen, ist es nicht möglich, eine allgemeine Zahl abzuleiten.

Zwischendurch kann es vorteilhaft sein, mehr Arbeitsplätze zu haben. Wenn jeder Compiler-Prozess klein ist, der Build jedoch insgesamt viele Daten berührt, ist die Festplatten-E / A möglicherweise der blockierende Faktor. In diesem Fall möchten Sie mehrere Jobs pro CPU gleichzeitig ausführen, sodass für jede CPU immer ein Job verwendet wird, während andere auf die E / A warten. Dies ist wiederum sehr abhängig vom Build-Job und vom verfügbaren RAM, hier davon, was für den Daten-Cache verfügbar ist (es gibt ein Optimum, nach dem zu viele Jobs den Cache zu sehr verschmutzen).


Ich wusste nicht, dass, wenn CPU-Kerne hyperthreaded sind, jeder von ihnen als zwei zählt. Wie auch immer, es scheint, dass meine CPU Hyper-Threading nicht unterstützt.
Francesco Turco

Ich habe diese Antwort akzeptiert. Wie auch immer, ich habe beschlossen, -j2an meinem System festzuhalten. Dies liegt daran, dass ich versucht habe, beide gccund firefoxmit Einstellungen von -j1bis zu -j5(für insgesamt 10 emerge-Befehle) aufzutauchen, und es scheint, dass die anderen drei Einstellungen -j2definitiv schneller sind als . -j1-j2
Francesco Turco

7

Ich denke , das irgendwie ist Heuristik - ermöglicht makezu Start CPUs + 1Prozesse , um sicherzustellen, dass:

  1. Es würde keine Lücke zwischen einem Worker-Prozess, der gerade beendet wurde, und einem noch ausgeführten Worker geben - ähnlich wie beim Füllen der Run-Warteschlange.
  2. Es würde nicht zu viele konkurrierende Prozesse geben, um mit dieser Vorfüllung der Run-Queue einen spürbaren Overhead zu erzielen.

Aber auch das ist heuristisch und das FreeBSD-Handbuch empfiehlt immer noch make -j4für eine einzelne CPU.


5

Im Allgemeinen gibt es Gründe, mehr Jobs als die Anzahl der Kerne zu starten. Wenn beim C-Kompilieren mit gcc -pipe nicht in den gcc-Optionen definiert ist, werden die Aktionen (Vorverarbeitung, erste Ausführung, Optimierungen und Assemblierung) nacheinander unter Verwendung temporärer Dateien ausgeführt. -pipe ändert dies dahingehend, dass Pipes zwischen Unterprozessen verwendet werden. (Das Hinzufügen von -pipe ist Standard, z. B. für FreeBSD, aber unter Linux nicht traditionell.) Wenn Sie also 2 Kerne haben und 2 Jobs gleichzeitig zulassen, verbringen Sie einige Zeit mit Festplatten-E / A. Die Empfehlung, 1 Job hinzuzufügen, scheint mit diesen Besonderheiten in Zusammenhang zu stehen. Aber um die endgültige Antwort zu erhalten, sollten Sie herausfinden, wer und wann diese Empfehlung hinzugefügt hat und ihn fragen :) oder in der Mailingliste von Gentoo Devels nachfragen.


2

Im Grunde ist diese Zahl das, was die Autoren den gesunden Menschenverstand nennen. Bestenfalls ist es eine gute Vermutung. Soweit ich weiß, wird der make-Prozess, der beim Tippen ausgelöst makewird, bereits gezählt, sodass -j3Sie am Ende den Hauptprozess warten müssen, während die beiden anderen kompilieren.

Als ich Gentoo benutzte, galt jedoch die Faustregel <#cpus>*2 + 1.

Es hängt alles davon ab, was Ihre Hühnchen-Trails, Teeblätter oder Magic 8-Bälle über die Festplatten-E / A, die stattfinden muss, und die Planung Ihres aktuellen Linux-Kernels aussagen. [Kern dieses -jPosts beginnen] Aus meiner persönlichen Erfahrung ( ist nicht Gentoo-spezifisch) ergibt alles zwischen #cpus + 1 und #cpus * 2 +1 gute Ergebnisse [Kern dieses Posts beenden] und im Durchschnitt werden Sie kaum Unterschiede feststellen. Prozessoren und Kernel sind heutzutage ziemlich gut.

ABER all dies ändert sich, wenn: a) Sie tatsächlich mehr als eine Box zum Kompilieren verwenden (du'h) oder b) Ihren eigenen Code entwickeln

Ein höheres -jAttribut weist mit größerer Wahrscheinlichkeit zuvor unbekannte Abhängigkeiten auf.

Und noch eine Randnotiz: Gehen Sie nicht nach der Anzahl der Kerne, sondern nach der Anzahl der gleichzeitigen Streams, die die CPUs nehmen. (Überschrift!)

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.