Wie geht der Windows 10-Scheduler mit Hyper Threading um, da Core Parking für Intel-CPUs standardmäßig deaktiviert ist?

Ich verwende Windows 10 (1607) auf einer Intel Xeon E3-1231v3-CPU (Haswell, 4 physische Kerne, 8 logische Kerne ).

Bei der ersten Installation von Windows 7 auf diesem Computer konnte ich beobachten, dass vier von acht logischen Kernen geparkt waren, bis eine Anwendung mehr als 4 Threads benötigte. Mit dem Windows-Ressourcenmonitor kann überprüft werden, ob Kerne geparkt sind oder nicht ( Beispiel ). Soweit ich weiß, ist dies eine wichtige Technik, um die Threads über die physischen Kerne hinweg im Gleichgewicht zu halten, wie auf der Microsoft-Website erläutert : " Der Core Parking-Algorithmus und die Infrastruktur werden auch verwendet, um die Prozessorleistung zwischen logischen Prozessoren auf Windows 7-Clientsystemen auszugleichen Prozessoren, die die Intel Hyper-Threading-Technologie enthalten. "

Nach dem Upgrade auf Windows 10 habe ich jedoch festgestellt, dass es keine Kernparkplätze gibt. Alle logischen Kerne sind ständig aktiv. Wenn Sie eine Anwendung mit weniger als vier Threads ausführen, können Sie sehen, wie der Scheduler sie gleichmäßig auf alle logischen CPU-Kerne verteilt. Microsoft-Mitarbeiter haben bestätigt, dass Core Parking in Windows 10 deaktiviert ist .

Aber ich frage mich warum? Was war der Grund dafür? Gibt es einen Ersatz und wenn ja, wie sieht es aus? Hat Microsoft eine neue Scheduler-Strategie implementiert, die Core-Parking obsolet machte?

Blinddarm:

Hier ein Beispiel, wie die in Windows 7 eingeführte Kernparkfunktion die Leistung verbessern kann (im Vergleich zu Vista, für die noch keine Kernparkfunktion verfügbar war). Was Sie sehen, ist, dass HT (Hyper Threading) unter Vista die Leistung beeinträchtigt, während es unter Windows 7 nicht funktioniert:

( Quelle )

Ich habe versucht, Core Parking wie hier erwähnt zu aktivieren, aber ich habe festgestellt, dass der Core-Parking-Algorithmus nicht mehr Hyper-Threading-fähig ist. Es parkte die Kerne 4,5,6,7, während der Kern 1,3,5,7 geparkt sein sollte, um zu vermeiden, dass die Fäden demselben physischen Kern zugeordnet werden. Windows zählt Kerne so auf, dass zwei aufeinander folgende Indizes zu demselben physischen Kern gehören. Sehr eigenartig. Es hat den Anschein, als hätte Microsoft dies grundlegend vermasselt. Und niemand hat es bemerkt ...

Außerdem habe ich einige CPU-Benchmarks mit genau 4 Threads durchgeführt.

CPU-Affinität für alle Kerne festgelegt (Windows-Version):

Durchschnittliche Laufzeit: 17.094498, Standardabweichung: 2.472625

CPU-Affinität für jeden anderen Kern festgelegt (damit er auf verschiedenen physischen Kernen läuft, bestmögliche Zeitplanung):

Durchschnittliche Laufzeit: 15.014045, Standardabweichung: 1.302473

CPU-Affinität auf die denkbar schlechteste Planung gesetzt (vier logische Kerne auf zwei physischen Kernen):

Durchschnittliche Laufzeit: 20.811493, Standardabweichung: 1.405621

Es gibt also einen Leistungsunterschied. Und Sie können sehen, dass die Windows-Defualt-Planung zwischen der besten und der schlechtesten möglichen Planung liegt, wie wir es bei einem nicht hyperthreading-fähigen Scheduler erwarten würden. Wie in den Kommentaren darauf hingewiesen, können jedoch andere Ursachen dafür verantwortlich sein, wie weniger Kontextwechsel, Rückschlüsse durch Überwachungsanwendungen usw. Daher haben wir hier noch keine endgültige Antwort.

Quellcode für meinen Benchmark:

#include <stdlib.h> #include <Windows.h> #include <math.h>  double runBenchmark(int num_cores) { int size = 1000; double** source = new double*[size]; for (int x = 0; x < size; x++) { source[x] = new double[size]; } double** target = new double*[size * 2]; for (int x = 0; x < size * 2; x++) { target[x] = new double[size * 2]; } #pragma omp parallel for num_threads(num_cores) for (int x = 0; x < size; x++) { for (int y = 0; y < size; y++) { source[y][x] = rand(); } } #pragma omp parallel for num_threads(num_cores) for (int x = 0; x < size-1; x++) { for (int y = 0; y < size-1; y++) { target[x * 2][y * 2] = 0.25 * (source[x][y] + source[x + 1][y] + source[x][y + 1] + source[x + 1][y + 1]); } } double result = target[rand() % size][rand() % size]; for (int x = 0; x < size * 2; x++) delete[] target[x]; for (int x = 0; x < size; x++) delete[] source[x]; delete[] target; delete[] source; return result; }  int main(int argc, char** argv) { int num_cores = 4; system("pause"); // So we can set cpu affinity before the benchmark starts  const int iters = 1000; double avgElapsedTime = 0.0; double elapsedTimes[iters]; for (int i = 0; i < iters; i++) { LARGE_INTEGER frequency; LARGE_INTEGER t1, t2; QueryPerformanceFrequency(&frequency); QueryPerformanceCounter(&t1); runBenchmark(num_cores); QueryPerformanceCounter(&t2); elapsedTimes[i] = (t2.QuadPart - t1.QuadPart) * 1000.0 / frequency.QuadPart; avgElapsedTime += elapsedTimes[i]; } avgElapsedTime = avgElapsedTime / iters; double variance = 0; for (int i = 0; i < iters; i++) { variance += (elapsedTimes[i] - avgElapsedTime) * (elapsedTimes[i] - avgElapsedTime); } variance = sqrt(variance / iters); printf("Average running time: %f, standard deviation: %f", avgElapsedTime, variance); return 0; }