Intel: Sapphire Rapids, Alder Lake und Tremont bekommen neue Cache-Instruktion

[PCGH-Redaktion]

Jetzt ist Ihre Meinung gefragt zu Intel: Sapphire Rapids, Alder Lake und Tremont bekommen neue Cache-Instruktion

Intel hat seine Übersicht für CPU-Instruktionen aktualisiert und damit eine neue Instruktion verraten, die in Sapphire Rapids, Alder Lake und Tremont zum Einsatz kommen soll. Die Instruktion heißt "CLDEMOTE" und kann die Kommunikation zwischen Kernen beschleunigen.

Bitte beachten Sie: Der Kommentarbereich wird gemäß der Forenregeln moderiert. Allgemeine Fragen und Kritik zu Online-Artikeln von PC Games Hardware sind im Feedback-Thread zu veröffentlichen und nicht im Kommentarthread zu einer News. Dort werden sie ohne Nachfragen entfernt.

Zurück zum Artikel: Intel: Sapphire Rapids, Alder Lake und Tremont bekommen neue Cache-Instruktion

 

[LP96]

Würde das nicht darauf hindeuten, dass Intel nun auch bei den Consumer CPUs die Cache Architektur anpasst?
So wie ich das in Erinnerung hatte, waren doch bei den Consumer CPUs L2 und L3 Cache noch inklusiv. Da würde ein solcher Befehl doch kaum Sinn machen, die Daten sind ja scon im langsameren Cache vorhanden und man könnte sie einfach nur aus den schnelleren Stufen löschen.
Bei den HEDT ist ja seit Skylake-X der L3 Cache nicht mehr inklusiv, da würde ein solcher Befehl ja Sinn machen.
Ergo passt Intel die Consumer CPUs darauf an, die Cache Architektur der HEDT Plattform zu übernehmen?

 

[DKK007]

Die Frage ist, wie sich das auf die Sicherheitslücken auswirkt, wenn man da so im Cache rumwurschteln kann.

 

[gerX7a]

Es gibt per se eine Menge Instruktionen im Befehlssatz, die sich auf cacheability und prefetching beziehen und damit direkten Einfluss auf die Caches nehmen. Die sind völlig normal und diese neue Instruktion hier taugt daher wenig etwaige Schreckensgespenster neu aufzuwärmen. - Siehe bei Bedarf das IA-64/32 Softw. Dev. Manual.
Ebenso fraglich ist jedoch auch, warum so ein hochspezifisches Implementationsdetail hier eine "News" wert ist.

 

[PCGH_Torsten]

Würde das nicht darauf hindeuten, dass Intel nun auch bei den Consumer CPUs die Cache Architektur anpasst?
So wie ich das in Erinnerung hatte, waren doch bei den Consumer CPUs L2 und L3 Cache noch inklusiv. Da würde ein solcher Befehl doch kaum Sinn machen, die Daten sind ja scon im langsameren Cache vorhanden und man könnte sie einfach nur aus den schnelleren Stufen löschen.
Bei den HEDT ist ja seit Skylake-X der L3 Cache nicht mehr inklusiv, da würde ein solcher Befehl ja Sinn machen.
Ergo passt Intel die Consumer CPUs darauf an, die Cache Architektur der HEDT Plattform zu übernehmen?

Für Sapphire Rapids wäre zu erwarten, dass er die Skylake-SP-/Cascade-Lake-/Cooper-Lake-Linie aufgreift. Aber Änderungen für Alder Lake oder gar Tremont sind nicht bekannt und die Gerüchte zu relativen Cache Größen sprechen nicht dafür. Ice Lake ist meinem Wissen nach jedenfalls noch inlusiv und da Lakefield die gleichen Sunny-Cove- mit Tremont-Kernen kombiniert, würde ich nicht auf mehrere Speicherbefehlsstrukturen in verschiedenen Teilen der CPU. Aber sinnvoll wäre es, wenn Intel die für die Topmodelle geplante Unterstützung für alle Prozessoren einführt, damit Code auf allen Designs korrekt ausgeführt werden kann.

 

[DKK007]

Wobei das eh spannend wird, zwei verschiedene Architekturen in einer CPU zu haben. Da werden sich viele Betriebssysteme und Programme wohl verstolpern.

 

[DKK007]

Wobei Lakefield ein 1+4 Design hat.

Gibt es bei aktuellen Apollo Lake CPUs mit Goldmont-Architektur überhaupt HT??
Die Atom ist schließlich auf mit schmaler Pipeline auf billige lahme CPUs ausgelegt.

 

[PCGH_Torsten]

Goldmont hat kein HT, das gab es nur bei den ursprünglichen in-order-Bonnell-Kernen. Allerdings kann Windows seit Bulldozer mit asymmetrischen Kerneigenschaften umgehen und auch priorisierte Kerne sind schon länger üblich. Mit Lakefield werden die Unterschiede zwar deutlich größer, aber da Intel für gewöhnlich lange vorher zusammen mit Microsoft an so etwas arbeitet, bin ich da zuversichtlich. Anders sähe dies aus, wenn sich die Befehlssätze der Kerne untereinander unterscheiden. Das wäre eine weitereichende, neue Herausforderung.

 

[DKK007]

Wobei doch die Bulldozermodule in sich selbst symmetrisch waren.



Ich dachte um die Pipeline für die geteilte FPU hat sich die CPU alleine gekümmert.
Oder hatte MS da bei Windows XP schon spezielle Sachen eingebaut?

 

[PCGH_Torsten]

Bulldozer erschien 2011, XP wurde 2007 abgelöst...

Und die Module waren zwar symmetrisch aufgebaut, aber wenn ein Kern Decode- und FPU-Ressourcen belegte, konnte der andere wenig machen. Anstatt die Leistungsressourcen zu analysieren, hat man dem Scheduler einfach beigebracht, dass jeder zweite Kern schlecht ist und man erstmal alle vier Module mit je einem Thread belegen sollte, ehe man irgend einem Modul einen zweiten Thread verpasst. Trotz physisch symmetrischen Aufbaus arbeitete Windows also mit "schnellen" und "langsamen" Kernen. Das sollte auch mit einem technisch schnellen und vier technisch langsamen funktionieren.

 

[DKK007]

Bei welcher Windows-Version kam das?

Denn XP wird von den Boards noch offiziell unterstützt.

 

[PCGH_Torsten]

Die Scheduler-Verbesserungen kamen über mehrere Updates, meiner Erinnerung nach so 6 bis 12 Monate nach Launch. Und die offizielle Unterstützung von Betriebssystemen durch Mainboards sagt nichts darüber aus, mit welcher Performance die Prozessoren laufen.

 

[DKK007]

Goldmont hat kein HT, das gab es nur bei den ursprünglichen in-order-Bonnell-Kernen.
[...]
Anders sähe dies aus, wenn sich die Befehlssätze der Kerne untereinander unterscheiden. Das wäre eine weitereichende, neue Herausforderung.

Es gab da doch Anpassungen, damit beide Teile von Lakefield miteinander kompatibel sind.

Doch Sunny Cove ist in dem Bereich nicht gleich Sunny Cove: Die AVX512-Einheit wurde für Lakefield entfernt, das Feature Set wurde an Tremont angepasst (welches kein AVX512 kann) und unterm Strich so leicht abgespeckt.

Bei beiden Architekturen wird im Einsatzfeld Lakefield auf SMT oder, wie Intel es nennt, Hyper-Threading verzichtet. Pro Kern steht also immer auch genau ein Thread zur Verfügung.