Windows 7 vs. Windows 8/8.1 - Thread-Management

[Daniel]

Moin,

mir erzählte kürzlich jemand, dass mit Windows 8/8.1 ein neuer Thread-Scheduler gekommen sei, der eine /spürbare/ Performance-Steigerung mit sich brächte. Als Beispiel wurde die Software Adobe Premiere genannt, die ein Video mit einer rund 1/3 höheren Bildrate rendere. Grundsätzlich mag ich nicht in Frage stellen, dass dieser Mensch ein Windows8-System gesehen hat, welches die Videos schneller fertiggestellte als ein angeblich vergleichbares Windows7-System.

Ich habe im MSDN gefühlt jeden sein umgedreht und keinerlei Hinweise darauf gefunden, dass substantielle Änderungen am Thread-Management vorgenommen worden seien. Ich denke eher, dass ein besseres Zusammenspiel von Hard- und Software über die Treiber auf dem 8er-System zu dem Resultat führte und Windows per se damit erstmal nichts zutun hatte.

Ist Euch da mit den Threads und Windows 7 bzw. Windows 8 etwas bekannt?

[t.roller]

Eine Performance-Steigerung kommt durch bessere Prozessoren zustande.
Wenn neue Software neue CPU-Funktionen nutzt und/oder parallel auf mehreren Cores läuft wird z.B. Rendern schneller.
Manche Software nutzt auch Funktionen der Grafik-CPUs.

[Luckie]

Details hat er nicht genannt?

[Daniel]

Es geht um ein und dieselbe Version von Adobe Premiere. Dass neuere CPUs schneller sein können, ist klar, aber hier nicht die Frage.
Es geht darum, ob mit Windows 8 tatsächlich ein effizienteres Thread-Management am Start ist.

[Luckie]

Nun ja, es wird kompatible zu alten sein. Insofern wäre das wissen nur akademischer Natur und nicht von praktischen Nutzen, denke ich mal.

Im alten bekam jeder Thread eine Zeitscheibe von 20 ms, wobei höher priorisierte Threads Vorrang hatten. Eventuell haben sie da etwas an einer Schraube gedreht. Itelligente Threadumschlatung oder so. Cachen des TEB, so dass Threads schneller wieder geladen werden können. Wären eventuell Stichworte für Google, wenn man da mehr in Erfahrung bringen will.

[jaenicke]

Ja, da hat sich einiges getan. Eine Dokumentation habe ich allerdings nicht gefunden. Ich hatte darüber mal etwas gelesen.

Du kannst es aber leicht selbst testen, dass sich da etwas geändert hat. Pack einfach ein

Delphi-Quellcode:

while True do;

ins FormCreate. Unter Windows 7 wird ein Kern zu 100% ausgelastet, ab Windows 8 werden alle Kerne um etwas mehr als 100% / Kernanzahl mehr ausgelastet. Sprich alles wird nun besser auf die Kerne aufgeteilt.
Das ist einer der Gründe weshalb viele Spiele ab Windows 8 plötzlich etwas schneller laufen. Viele sind noch nicht komplett multithread-fähig, so dass diese Optimierungen dort gut ankommen.

Deshalb gibt es standardmäßig bei Windows 8 und höher auch keine Kernansicht mehr (kann man per Kontextmenü auf das Diagramm umschalten). Es ist schlicht uninteressant, weil die einzelnen Threads nicht mehr einen Kern auslasten, sondern dynamisch auf die Ressourcen aller Kerne zugreifen.

Dadurch wird das ganze schneller, auch einzelne Threads, da die Ressourcen besser genutzt werden können. Ein komplett ausgelasteter Kern ist langsamer als mehrere nicht komplett ausgelastete Kerne.

Eine so hohe Leistungssteigerung konnte ich allerdings nicht feststellen. Bei mir sind es so ca. 3-5% gewesen.

Ein anderer Effekt ist, dass alle Kerne heruntertakten können und so Strom gespart werden kann, wenn nicht einer auf 100% läuft und so volle Leistung fordert.

// EDIT:
Ach ja, den Leistungsunterschied kann man leicht messen indem man einmal normal laufen lässt und einmal die Prozessoraffinität auf einen bestimmten Kern setzt.

[Delphi-Laie]

Das ist in der Tat eine massive Änderung der Thread(ablauf)organistaion.

Zitat:

Zitat von jaenicke (Beitrag 1351027)

Dadurch wird das ganze schneller, auch einzelne Threads, da die Ressourcen besser genutzt werden können. Ein komplett ausgelasteter Kern ist langsamer als mehrere nicht komplett ausgelastete Kerne.

Nanu, und das trotz dem "Reibungsverlust" (also eigentlich Zeitverbrauch /-verlust), die die Threadumschaltung von einem Prozessor(kern) zum nächsten mit sich bringt?!

[jaenicke]

Zitat:

Zitat von Delphi-Laie (Beitrag 1351028)

Nanu, und das trotz dem "Reibungsverlust" (also eigentlich Zeitverbrauch /-verlust), die die Threadumschaltung von einem Prozessor(kern) zum nächsten mit sich bringt?!

Die Zeitscheibenverwaltung hast du auch, wenn ein Kern aktuell hauptsächlich einen Thread bearbeitet. Windows ist ja kein Echtzeitbetriebssystem, das z.B. einen Kern einfach exklusiv für eine bestimmte Aufgabe verfügbar macht, wenn nötig. Deshalb ist da der Unterschied nicht so groß wie es vielleicht scheint.

[t.roller]

Zitat:
"Time resources on Windows are mostly interrupt controlled entities. Therefore, they show
a certain granularity. Typical interrupt periods are 10 ms to 20 ms. The interrupt period
can also be set to be 1 ms or even a little below 1 ms by using API calls to
NTSetTimerResolution or timeBeginPeriod. However, for several reasons they can and
shall never be set to anything near the 1 μs regime. The best resolution to observe by
means of Windows time services is therefore in the 1 ms regime."

Das heisst, die NTSetTimerResolution kann geändert werden.

PDF-Download