Wie skalieren 128 CPU-Threads?

[IT-Superprofi]

Unter aktuellem Windows oder Linux?

Oder ist bei 128 CPU-Threads so viel Overhead da, dass die sich nur noch selbst verwalten?

Oder kann irgendein neuer, toller scheduler zusammen mit der verhältnismäßig hohen Bandbreite (QPI) eine gute Skalierung vermuten lassen?

[RumbleThumble]

Ich gebe dir recht, könnte ine Problem werden.
Jedoch meine ich mich errinnern zu können das selbst Win 7 bis zu 256 CPUs skalieren kann, und das sind weit mehr als 128 Threads.
Die haben einen neuen Zustand neben "running" und "waiting" eingeführt, den Aufgaben (Threads) annehmen können: "pre-waiting". Zudem wurde der "dispatcher-lock" entfernt, der die Skalierung mit mehr als 32 Prozessoren verhinderte.

[IT-Hyperprofi]

Du bist schon ein Superprofi, als ob 128 Threads besonders viel wären. Ein Webserver erzeugt allein für jede Anfrage mehrere Threads. Nun stell dir mal vor wieviele Leute noch sinnvoll Golem zuspammen könnten, wenn bei weniger als 128Threads schluß wäre!

[_gilty_]

nanana, warum gleich so böse ?

gemeint war (so habs ich verstanden) wie effizient ein aktuelles OS zum Beispiel X threads (im sinne von prozessen/taks) auf 128 Threads der 64 Cores verteilt.
Und das ist gar kein so unberechtigter zweifel, da zur zeit nur effiktiv auf quadcores getestet werden konnte (win7) und win2008r2 auf 4x4 Cores.

Mal sehen was da noch alles auf uns zukommt.

[olek]

Antwort: Sehr!

[IT-Hyperprofi]

Rein als jemand, der sich nicht tiefgründig mit dem Thema beschäftigt hat, sehe ich andere Probleme, als die Skalierung durch das OS. Die Daten die in der CPU berechnet werden, werden nach wie vor alle über den gleichen Bus geschoben, also egal ob ich jetzt eine Recheneinheit oder 8 habe. Bei wenigen MB Cache und hoher Rechenleistung, dürften sich die Rechenwerke damit sehr häufig in die Quere kommen.
Das die Verteilung der Threads aber eine signifikante Rolle spielt kann ich mir nicht vorstellen, weil sie selbst bei Einkern-Systemen über einen Scheduler läuft.

[Ext]

Eigentlich sämtliche posix-Betriebssysteme skalieren da ausgezeichnet, andernfalls wären solche CPUs wie Sun Niagara 2 garnicht sinnvoll einsetzbar, der Overhead hält sich dabei in Grenzen. Leider kann man das von Betriebssystemem auf Basis des NT-Kernels nicht behaupten, da kann man froh sein wenn man überhaupt alle Kerne ausgelastet bekommt ohne dass der Sheduler überlastet ist.
War vor nem halben Jahr gut zu sehen, als Microsoft voller stolz erklärt hat, dass sie es hinbekommen haben mit MS-SQL 128 CPU-Kerne auszulasten. Was man damals wohlwissend verschwiegen hat: Es hat mieserabel skaliert.

[RogerProger]

Bei Webservern, die Verbindungen Requests auf Threads verteilen ist es real nicht wirklich wichtig, ob die Anzahl der Threads die Anzahl der von den Kernen ausführbaren Threads übersteigt. Man erinnere sich: Multithreading hat bereits vor Jahrzehnten auf Singlecore-Systemen eine wichtige Rolle gespielt. Geichläufigkeit war damals nur virtuell.
Wird der Rechner jedoch gezielt zum Numbercrunchen eingesetzt, sollte die Anzahl der Threads in etwa der Anzahl der CPU-Kerne entsprechen, um Kontext-Switches so gering wie möglich zu halten, den die kosten enorm Zeit.
Was eine viel größere Rolle spielt ist die Art der Programmierung. Ist eine Rechen-Aufgabe gut programmiert, erfordert sie eine möglichst kleine Menge an Thread-Locks. Im besten Fall keine.
Siehe Actor-Model, Software-Transactional-Memory etc. pp. Multithreading ist also in erste Reihe kein so großes Hardware- oder OS-Problem, sondern ein Problem der adäquaten Programmierung des rechnenden Programms.