@CD LABS: Radon Project: Wenn du es in dieser Leseart verstanden wissen willst ... Touche.
Zum zweiten Teil, wie hoffentlich deutlich geworden, nur Spekulationen meinerseits, da die Existenz dieser zusätzlichen und andersartigen Kerne gerade erst bekannt wurde sowie auch die komplett andere Verortung auf der CPU. Das alles wird aber zweifellos funktionale Gründe haben, d. h. man darf hier durchaus auf die eine oder andere zielgerichtete Optimierung spekulieren, denn schließlich wird man diesen Aufwand nicht ohne Grund betreiben, entsprechend wird mindestens der mobile MTL ein hochinteressantes Produkt werden, weil hier sehr viel Neues auf einmal zusammenkommt, das am Ende bei sinnvoller Komposition den absehbar größten technischen Fortschritt seit langem bei Intel darstellen dürfte, der zudem mit dem Entfall des seit längerem bestehenden Fertigungsnachteils auch nun kein Handicap mehr kompensieren muss.
@RyzA: In der aktuellen Hybrid Technology-Implementation ist primär der OS-Scheduler für die Thread-Verteilung zuständig. Intel hat die Technologien Hardware Guided Scheduling sowie den Thread Director in der CPU auf Hardware-Ebene implementiert um dem OS-Scheduler in Echtzeit deutlich weiterreichende Monitoring-Daten zur Verfügung stellen zu können, die eine bessere und zielgerichtetere Interpretation und Verteilung der Threads ermöglichen. Wirklich optimal wird das System jedoch erst mit modernisierter und neu kompilierter Software laufen, denn Intel und Microsoft sehen ebenso vor, dass Entwickler die jeweilgen Threads nun mit zusätzlichen Flags auszeichen, die dem OS einen zusätzlichen Hinweis geben, in welcher Art der Entwickler den jeweilgen Thread zu nutzen gedenkt. Intels Hardware-Lösung in Verbindund mit dem Windows-Scheduler erfüllt migrationstechnisch durchaus seinen Zweck, kann den Verwendungszweck eines konkreten Threads jedoch nur nach best guess raten. Richtig rund wird die Geschichte erst mit neuerer, angepasster Software.
Beispielsweise in einer Game Engine sollten kleinere, nebenläufige und deutlich weniger Last erzeugende Threads wie die Physik- oder Audio-Berechnung bspw. sinnvollerweise auf E-Cores verlagert werden, was die P-Cores von dieser Last befreit und mehr Leistung für wichtigere Threads wie bspw. den Main-Thread zur Verfügung stellt. Ohne die SW-Flags, weil diese "kleineren" Threads dauerhaft und teilweise asynchron nebenher laufen, verteilt die derzeitige Implementation diese jedoch nach Möglichkeit primär auf die P-Cores, d. h. mit modernerer SW kann man noch eine bessere Ausnutzung dieser neuen Hardware in Zukunft erwarten.
Zu MTL: Wie gesagt, ich würde erwarten, dass der Scheduler hier keine zusätzlichen komplexeren Entscheidungen treffen muss, sondern dass es nur darum geht in welchen Power Stage die CPU gerade läuft und dann ist es möglicherweise ein schlichtes Entweder-Oder. Also, bei mittlerer Last werden die regulären E-Cores (mit)genutzt, bei RPL bspw. bis zu 16 Stück, bei sehr geringer Last bzw. reiner Nebenläufigkeit kann man derzeit zumindest vermuten, dass die verbleibende Rechenlast komplett auf die LP-E-Kerne verlegt wird und im besten Fall das Compute Tile mit den P- und E-Kernen komplett stillgelegt werden kann.
Bei welchem Leistungslevel ein derartiges Schema greift, kann man aktuell nur vermuten. Etwas wie der connected stand-by, also bspw. die CPU weitestgehend im Ruhemodus mit einigen Hintergrund-Apps und aktivierter Netzwerkverbindung wird zweifellos ein Szenario sein. Ob es dagegen möglicherweise gar so weit reicht, dass bspw. bei Videoschauen diese LP-E-Kerne in Verbindung mit der Media-Decoder-Einheit schon ausreichend sind, kann man dagegen derzeit nicht abschätzen sondern lediglich vermuten oder hoffen.
In 9 - 12 Monaten werden wir wohl mehr wissen ... und man darf natürlich gepsannt sein, was AMD einem solchen Design mit seinen Phoenix- und Raphael-CPUs (mobile Zen4-Designs) entgegenstellen wird.
