Rocket Lake S: Erste Samples noch vor Comet Lake S in Datenbanken

[gaussmath]

Caches ohne feine Strukturen sind nur teuer in der Herstellung, aber das ist Intels Problem. Kritischer sind tatsächlich die Kerne: Sunny Cove hat auch an den Pipelines Erweiterungen vorgenommen, die sich im Strombudget niederschlagen müssen. Es nützt nichts, diese IPC 1:1 in den taktstärkeren 14-nm-Prozess zu übertragen, wenn man dann aus Effizienzgründen doch auf 4 GHz beschränkt bleibt.

Caches haben einen hohen Anteil am Powerbudget, soweit ich weiß, und somit auch an der Effizienz.

 

[PCGH_Torsten]

Das Gerücht zu PCIe 4.0 machte Ende Januar die Runde und die PCGH hat das einen Tag später auch selbst aufgegriffen. Konkret schrieb hier u. a. THW:

"[...] And while we've assumed the company wouldn't move forward to PCIe 4.0 until it moved to a new microarchitecture, we were told by several independent sources, which requested anonymity, that Intel intended to add support for the interface with the Comet Lake platform. As a result, most iterations of Socket 1200 motherboards currently have the necessary componentry, like redrivers and external clock generators, to enable the feature.
The PCIe 4.0 interface comes with twice the bandwidth of PCIe 3.0, but that also comes along with tighter signal integrity requirements. Unfortunately, Intel reportedly ran into issues with the chipset and untenable amounts of jitter (we're told the Comet Lake processors themselves are fine), thus requiring cost-adding external clock generators to bring the interface into compliance. In either case, the issues reportedly led Intel to cancel PCIe 4.0 support on the Comet Lake platform. [...]"

Intel Gets the Jitters: Plans, Then Nixes, PCIe 4.0 Support on Comet Lake | Tom's Hardware

Liest sich hier eigentlich relativ glaubwürdig bzgl. PCIe 4.0, das anscheinend tatsächlich vorgesehen war und implementiert zu sein scheint, auch wenn man es nicht vorab offiziell ankündigte, anderfalls wäre die Aussage "told by several independent sources" eine handfeste Lüge.

Es ist zumindest eine handfeste Lesermanipulation. Die Aussage zu den vielen Quellen bezieht sich nämlich auf den gesamten Absatz, in dem es mehrheitlich um die Comet-Lake-Plattform als ganzes geht. Hier gab es tatsächlich mehrere Leaks, die auf 4.0-Pläne hinweisen. Aber nur der Einschub in der Klammer macht eine Aussage darüber, welcher Teil der Plattform 4.0-Geschwindigkeit bieten sollte. Und für diese Aussagen in der Klammer kenne ich nicht einmal eine zweite Quelle, nur THG. Und die waren in der Vergangenheit nie nah an den kritischen Intel-Leaks dran. Da die Klammer in sich der von Intel gewohnten Plattformpolitik und allen anderen Leaks zur Beziehung zwischen Z490 und älteren Intel-PCHs wiederspricht, würde ich die Klammer tatsächlich als Fehlaussage deuten. Nicht unbedingt eine Lüge – aber wenn diese Information über mehrere möglicherweise fachunkundige Zwischenschritte ohne weitere Bestätigung an THG herangetragen wurde, sind Verfremdungen denkbar.

Caches haben einen hohen Anteil am Powerbudget, soweit ich weiß, und somit auch an der Effizienz.

Eigentlich nicht. Ich kenne zwar keine aktuellen Zahlen, aber weder bei AMD noch bei Intel wird von deutlich mit den aktiven Cache-Bereichen skalierenden Verbräuchen berichtet (im professionellen Segment gibt es da ja einige Sonder-SKUs) und die letzte offizielle Bestätigung in Form des Pärchens Northwood-C/Galatin ergibt ein TDP-Budget von circa 0,09 nW pro L3-Cache-Transistor inklusive der Cache-Logik. Wenn man diesen Wert auch für den L2 annimmt, ergeben sich für die restlichen Transistoren, also Rechenkerne, FSB und L1-Caches, 3 nW pro Transistor. Das wäre ein Unterschied von Faktor 34, wobei der Überschlag hinkt natürlich, da ein breiter angebundene L2 energiehungriger als ein träger L3 ist. Umgekehrt wird aber der Verbrauch der Recheneinheiten auch durch den Einschluss der sparsameren L1 beschönigt, sodass man grob von 1,5 Größenordnungen Verbrauchsunterschied sprechen kann und da sich an den grundsätzlichen Schaltungen nichts geändert hat, würde ich das Verhältnis auch auf heutige Architekturen mit ihrem absolut natürlich deutlich kleinerem Energieumsatz pro Transistor übertragen.

Was dagegen wirklich energieintensiv ist und heute oft mit den Caches zusammen als Uncore gezählt wird: Die Kommunikation zwischen den Kernen. In der Zen+-Generation hat Ian Cutress für die großen Epycs mal 50 Prozent Anteil am Gesamtverbrauch unter Volllast gemessen, wobei die Leistung primär mit der IF-Konfiguration und nicht mit den Caches skalierte.

 

[gaussmath]

Laut diesem Thread sind's beim StrongARM bis zu 30% nur für den L2! Es wird sogar ein Paper verlinkt. Inwiefern das mit x86 vergleichbar ist, weiß ich nicht. Ich mache mal ne Anfrage auf Twitter. Hab ein paar Nerds in der Follower Liste... ^^

Zusätzlich wird ein Wärmebild gezeigt weiter unten. Der L3 heizt ganz gut mit.

 

[gerX7a]

Es ist zumindest eine handfeste Lesermanipulation. Die Aussage zu den vielen Quellen bezieht [...]

Ich würde zumindest eine gewisse Sorgfaltspflicht erwarten und als medienschaffendes Unternehmen nicht einfach ungeprüfte Aussagen in die Welt setzen (oder auch nur weitergeben). Die Leseart ist eindeutig und das wäre denen dann schon als "verwerfliches Vorgehen" anzulasten, wenn es so wäre. Abseits dessen werden die MB-Hersteller wohl kaum PCIe 4-Funktionalität auf "gut Glück" implementiert haben, sondern aufgrund interner Aussagen seitens Intel gehandelt haben. Die arbeiten mit so knappen Margen, dass die sich derartiges gar nicht leisten können und ebenso könnten sie es sich nicht leisten jetzt schon PCIe 4 zu implementieren, wenn für Comet Lake gar kein PCIe 4 vorgesehen gewesen wäre, denn die Aussicht "die Nachfolge-CPU wird dann auch echt PCIe 4 unterstützen", dürfte da den Absatz auch nicht auffangen oder gar anheben können.
Die Aussagen, dass die CPUs selbst angeblich keine Probleme aufweisen, jedoch der Chipsatz dagegen Probleme mit der Signalqualität hat, sind schon sehr konkret und wenn das nicht zutrifft, darf man das denen getrost als schweres Versäumnis (oder gar mehr) anlasten.
Ich bin gespannt. Wenn es tatsächlich ein vollständiger Support hätte sein sollen, nun aber nur die CPU-Lanes einwandfrei funktionieren, sollten sie einfach diese freigeben, denn anderfalls ist keinem geholfen, weder ihrem Absatz, noch den MB-Herstellern, die ihre Designs nicht mal eben kurzfristig "umkrempeln" können.

 

[PCGH_Torsten]

Wie gesagt: Eine Implementation von 4.0 nur für die CPU wird durch den PCH nicht behindert. Umgekehrt dagegen schon – einen 4.0-PCH an eine 3.0-CPU zu hängen wäre von vorneherein zum scheitern verurteilt gewesen beziehungsweise durch die DMI-Limitierung sinnlos.

Laut diesem Thread sind's beim StrongARM bis zu 30% nur für den L2! Es wird sogar ein Paper verlinkt. Inwiefern das mit x86 vergleichbar ist, weiß ich nicht. Ich mache mal ne Anfrage auf Twitter. Hab ein paar Nerds in der Follower Liste... ^^

Zusätzlich wird ein Wärmebild gezeigt weiter unten. Der L3 heizt ganz gut mit.

Nice. Beim Core-i-L3-Wärmebild halte ich aber meinen Interconnect-Hinweis aufrecht: Das der L3 vor allem mit einem Kern im Turbo-Modus zu glühen scheint, nicht aber bei verteilter Last auf allen Kernen, spricht für den Ringbus als primäre Wärmequelle. Denn der muss dann den einen Kern auch mit Daten aus der letzten Cache-Slice versorgen, die in normaler Anwendung primär von ihrem direkten Nachbarn benutzt werden würde. Dazu passt auch die intensivere Wärmeentwicklung an den sechsmal vorhandenen Schaltungen zwischen den regelmäßigen Speicher-Strukturen: Das sind meiner Einschätzung nach die Nodes des Ringbus (4 Kerne + IGP + IMC) und keine Teile des Caches.

Wie es bei anderen Architekturen aussieht, weiß ich aber nicht. Einerseits lässt skaliert Cache sicherlich schlechter auf niedrige Leistung, weil SRAM auch beim nichtstun Energie braucht. Der Anteil am Stromverbrauch solllte bei breiten, niedrig taktenden Designs also höher liegen, weil dort die Rechenlogik viel sparsamer ist. Letztlich sind die dicken Server-ARMs und auch SPARCs ja mit ähnlichen Methoden auf Effizienz getrimmt, wie mobile-CPUs. Obiges Beispiel mit einem REE-Netburst stellt praktisch das gegenteilige Extrem dar.

Bei ARM und SPARC würde ich wegen RISC eine weitere Verschiebung erwarten: Diese CPUs müssen praktisch gar keine Leistung für Decoding aufwenden und, je nach Implementation, auch weniger bis keine für die Sprungvorhersage, weil ihre Befehlssätze direkt und mit viel kürzerer Latenz verarbeitet werden. Offizielle Zahlen zu deren Verbrauch in x86 schwanken zwar, aber wie schon in der Zen-Analyse angesprochen: Bei modernen x86-Kernen ist der eigentliche Kern ja nur noch ein namensgebender Spitzensportler in der Mitte eines großen, energieintensiven Teams, ohne das praktisch gar nichts liefe. Umgekehrt, und da bin ich jetzt auf einem wirklich dünnem Ast unterwegs, könnten die simpleren Instruktionen bei ARM zu deutlich mehr Befehlsdurchläufen für die gleiche Rechenarbeit führen und damit auch zu mehr Load- und Storevorgängen. Dann hätte man also mehr Verbrauch im Speichersystem und gleichzeitig deutlich weniger in den Kernen, was das Verhältnis natürlich extrem verschiebt. Das ist aber, wie gesagt, hochspekulativ. Gegenüber echtem CISC müsste es stimmen, aber über die Micro-OPs von AMD und Intel weiß ich schlichtweg nicht genug, um sie mit RISC-Instruktionen vergleichen zu können.