Tharan schrieb:
Egal ob Raptor-Lake oder Arrow-Lake: Das Problem ist aktuell noch real und die Aussage von @xexex habe ich mit 15 Minuten googlen nach neueren Benchmark-Ergebnissen nicht bestätigen können.
Nein! Das Scheduling ist völlig anders, genauso wie die CPU Architektur. Raptor Lake hatte mit langsamen E-Cores zu kämpfen und einen Scheduler der mehr oder weniger die Threads zwischen den jeweiligen Kernarten geschoben hatte, wenn die Applikation es nicht anders angefordert hatte. Dazu gab es noch Hyperthreading, man musste dies bei der ganzen Planung auch noch berücksichtigen.
Seit Meteor Lake gibt es nun die LPE Kerne, damals noch ungünstig auf einem eigenen Die untergebracht und eigentlich nur für Always-On Notebooks zu gebrauchen. Seit Arrow Lake funktioniert der Scheduler völlig anders! Es gibt nun kein HT mehr und es gibt viel schnellere E-Kerne, nun laufen praktisch alle Threads, wenn von der Applikation nicht anders gefordert, auf den E-Kernen und sobald die Leistung benötigen, werden sie auf die P-Kerne verschoben.
In etwa kannst du dir das wie die big.LITTLE Architektur unter ARM vorstellen, nur dass es hier nicht nur einen schnellen Kern gibt sondern bis zu acht. Jeder Thread der besonders viel Leistung benötigt, wird in Sekundenbruchteilen auf einen schnelleren Kern verschoben, dazu gibt es noch in Zusammenarbeit mit Windows eine Logik je nach Inhalt.
Spiele hingegen sollen primär auf den E-Kernen und im Bedarfsfall auf den P-Kernen verarbeitet werden. Hier geht es vorrangig nicht um die Effizienz und einen möglichst geringen Verbrauch, sondern vielmehr darum, der GPU auch bestmöglich zuarbeiten zu können. Mit der hauptsächlichen Nutzung der E-Kerne ist natürlich aber auch ein möglichst geringer Stromverbrauch durch die CPU vorgesehen.
In Multi-Threaded-Anwendungen wie dem Cinebench (der eigentlich auch nur ein Benchmark ist, aber für Rendering-Anwendungen stehen könnte) verteilt der Thread Director die Last natürlich auf alle Kerne, damit der Workload schnellstmöglich abgearbeitet werden kann.
Mit dem Thred Director wie er mit Alder Lake eingeführt wurde, hat es nur noch wenig gemeinsam, weil auch die gesamte CPU Architektur nun völlig anders aussieht. Spiele auf P-Kerne zu schieben, wie es manche noch unter Alder Lake gemacht haben, ist hier völlig kontraproduktiv, da nicht jeder Thread die gleiche Leistung benötigt. Hier wird nun tatsächlich der Focus auf besonders lastintensive Prozesse gelegt, die das System durch die veränderte Architektur, viel schneller auf einen Kern mit mehr Leistung verschieben kann.
Das Design von Panther Lake stellt in der Speicherarchitektur einen deutlichen Schritt über die bisherigen Hybridgenerationen hinaus dar. Während frühere Designs wie Arrow Lake oder Lunar Lake die Effizienzkerne noch über eine separate Verbindung außerhalb des zentralen Cache-Rings anbanden, integriert Panther Lake nun alle Kerne – sowohl P- als auch E-Cores – in einen gemeinsamen L3-Cache-Ring. Diese Vereinheitlichung sorgt dafür, dass Daten, die zwischen den verschiedenen Kernarten ausgetauscht werden, nicht mehr über das SoC-Fabric laufen müssen. Dadurch sinken sowohl die Latenzen als auch der Energieverbrauch pro Zugriff.
Der L3-Cache fungiert in dieser Struktur als letzte gemeinsame Speicherstufe, die nicht nur Daten zwischenpuffert, sondern auch die Kohärenz zwischen allen Recheneinheiten sicherstellt. Wenn der Scheduler Threads zwischen P- und E-Cores verschiebt, können diese ohne vollständiges Neuladen aus dem Arbeitsspeicher fortgesetzt werden, da die relevanten Cache-Zeilen im gemeinsamen L3-Bereich erhalten bleiben. Das verbessert die Reaktionszeiten insbesondere bei Anwendungen, die häufig den Kern wechseln oder stark parallelisiert arbeiten.
Die Softwarearchitektur von Panther Lake wurde tiefgreifend überarbeitet, um die gesteigerte Komplexität der neuen Hybridstruktur effizient zu steuern. Der überarbeitete Intel Thread Director v2 spielt dabei eine zentrale Rolle. Er überwacht in Echtzeit die Art und Intensität der laufenden Aufgaben und ordnet sie automatisch dem jeweils passenden Kerntyp zu – leistungsstarke Threads wandern auf die Cougar-Cove-P-Cores, während parallele oder hintergründige Prozesse den Darkmont-E-Cores und LP-E-Cores zugewiesen werden. Neu ist dabei der sogenannte Zoneless-Scheduling-Ansatz, bei dem Threads nicht länger festen Leistungszonen zugeordnet sind, sondern dynamisch über alle Kerne hinweg verschoben werden können.
https://www.igorslab.de/evolution-o...rchitektur-effizienz-und-softwareintegration/
