Threadlokalität

Wenn ein Thread funktioniert, liest er häufig Daten aus dem Speicher und von der Festplatte. Die Daten werden häufig in zusammenhängenden oder nahen Speicherorten auf dem Datenträger gespeichert (z. B. beim Iterieren über ein Array oder beim Lesen der Felder eines Objekts). Die Hardware setzt darauf, indem sie Speicherblöcke in schnelle Caches lädt, so dass der Zugriff auf zusammenhängende / geschlossene Speicherorte schneller ist.

Wenn Sie eine große Anzahl von Threads haben und zwischen ihnen wechseln, müssen diese Caches oft geleert und neu geladen werden, wodurch der Code eines Threads mehr Zeit in Anspruch nimmt, als wenn er gleichzeitig ausgeführt wird, ohne dass er gewechselt werden muss zu anderen Threads und komm später zurück.

Ein bisschen wie wir Menschen brauchen etwas Zeit, um zu einer Aufgabe zurückzukehren, nachdem wir unterbrochen wurden, wo wir waren, was wir taten, etc.

Nur um den Punkt "Cache-Miss" von JB Nizet zu erläutern.

Wenn ein Thread auf einem Core ausgeführt wird, werden zuletzt verwendete Daten im L1 / L2-Cache gespeichert, die sich lokal im Core befinden. Moderne Prozessoren lesen typischerweise Daten aus dem L1 / L2-Cache in etwa 5-7 ns.

Wenn nach einer Pause (unterbrochen, Warteschleife usw.) ein Thread erneut ausgeführt wird, wird er höchstwahrscheinlich auf einem anderen Core ausgeführt. Dies bedeutet, dass der L1 / L2-Cache dieses neuen Kerns keine Daten enthält, die sich auf die Arbeit beziehen, die der Thread ausgeführt hat. Es muss jetzt in den Hauptspeicher (der etwa 100 ns benötigt) gehen, um Daten zu laden, bevor mit der Arbeit begonnen wird.

Es gibt Möglichkeiten, dieses Problem zu beheben, indem Threads an einen bestimmten Kern angeheftet werden, indem eine Thread-Affinitätsbibliothek verwendet wird.