ComputerJunge schrieb:
Alle relevanten oder "nur" interessanten Merkmale der Produkte sind mittlerweile automatisch Teil und Opfer der "Fanboy-Wars".
Sollten wir das nicht gewöhnt sein? Man sieht doch auch hier am "Thread Director", wie sich Leute in die Wolle bekommen und wie er auf der einen Seite "schlecht" geschrieben wird und auf der anderen Seite als quasi der Weisheit letzter Schluss stilisiert wird. Genauso, wie hier immer noch angenommen wird, dass der Thread Director das "Scheduling" übernimmt. Dass das nicht so ist, kann man in Whitepapern und Co nachlesen.
Atma schrieb:
Nenn mir einen Nachteil des Thread Directors bei Alder- und Raptor Lake.
https://dl.acm.org/doi/abs/10.1145/3546591.3547532
Da wird auf entsprechende Probleme eingegangen und dass der Thread Director am Ende auch alles andere als das "Wunderwerk" ist, für das ihr es hier aktuell hinstellt. Die Grundregeln für AlderLake und RaptorLake "lassen" sich auch ohne Thread Director ausführen: erst P-Kerne, dann E-Kerne, dann SMT-Kerne.
Darüber hinaus analysiert der Thread Director den "Mikrocode" und teilt die Threads in 3-Klassen ein und meldet diese Klassen dem Windows Scheduler. Dieser Scheduler entscheidet am Ende aber nicht nur anhand des Thread Directors, wohin ein Thread gelagert wird, sondern nimmt dazu noch andere Informationen mit, die das Betriebssystem auch selbst erfasst. Entsprechend werden auch die Prioritäten und Co damit einbezogen und auch die Art des Tasks.
Der Thread Director ist ein wunderbares Monitoring-Werkzeug und liefert wertvolle Daten, er ist aber noch nicht perfekt und Intel wird auch an diesem weiter arbeiten müssen, so wie Microsoft und in Linux und Co an den Schedulern weiter gearbeitet werden muss, damit diese entsprechend auch die richtigen Entscheidungen treffen.
Denn aktuell ist es so, dass Threads auf den P-Kernen laufen, die aber locker in e-Kerne könnten und teilweise auch umgekehrt. Es wird aber interessant werden, was da noch alles möglich ist, wenn man mit immer besseren Monitoring von Threads auf der CPU, da entsprechenden "Klassen" und Softwarekniffen im Scheduler hier weiter geht.