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.
Intel hat diese Woche die Übersicht über CPU-Instruktionen aktualisiert. Neu dabei ist eine Instruktion namens CLDEMOTE, die in Intels kommenden Server- Desktop- und Atom-Prozessoren enthalten sein wird. Konkret geht es um die Familien Sapphire Rapids, Alder Lake und Tremont.
Schnellerer Datenaustausch zwischen Kernen
CLDEMOTE ist die Abkürzung für Cache Line Demote, dementsprechend betrifft die Instruktion den CPU-Cache. Konkret gibt sie die Anweisung, dass ein Kern einen bestimmten Teil des Caches auf ein höheres Cache-Level verlegen soll - also beispielsweise vom L1- in den L3-Cache.
Diese Verschiebung auf eine langsamere und zugleich größere Cache-Stufe kann zwei Einsatzzwecke haben. Einerseits ist es durch CLDEMOTE möglich, dass man Daten sozusagen auf die Reservebank legt, wenn man sie nicht sofort wieder braucht. Dadurch wird Speicherplatz in den kleinen L1- und L2-Caches frei, gleichzeitig bleiben die Daten aber in der CPU und werden nicht in den Arbeitsspeicher ausgelagert.
Der zweite Einsatzzweck liegt beim Datenaustausch zwischen Kernen. Verschiedene CPU-Kerne teilen sich meist den L3-Cache, während die unteren Ebenen pro Kern einzeln aufgeführt sind. Wenn ein Kern die Daten eines anderen Kern lädt, müssen diese Daten also zuerst in den L3-Cache kopiert werden - und genau das kann mit CLDEMOTE nun schon im Voraus erzwungen werden.
Ebenso interessant: Comet Lake-S: Intel nennt Power Limits aller Prozessoren
Wie bei neuen Instruktionen üblich, dürfte bei Sapphire Rapids, Alder Lake und Tremont allein durch die Unterstützung von CLDEMOTE kein Leistungsvorteil entstehen. Dazu muss erst die jeweilige Software entsprechend angepasst werden. Wie viel Einfluss die CLDEMOTE-Instruktion in einem durchschnittlichen und optimalen Einsatzfall haben kann, ist dabei momentan noch kaum abzuschätzen. Vermutlich dürfte es sich aber eher um ein Werkzeug für die Feinoptimierung handeln, das keine immensen Performance-Zuwächse mit sich bringt.
Quellen: Intel, Utexas via Techpowerup, Twitter
Anders sähe dies aus, wenn sich die Befehlssätze der Kerne untereinander unterscheiden. Das wäre eine weitereichende, neue Herausforderung.
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.
Denn XP wird von den Boards noch offiziell unterstützt.
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.
[Ins Forum, um diesen Inhalt zu sehen]
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?