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 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.

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

Zitat von jaenicke:

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?!

Zitat von Delphi-Laie:

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.

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