Rocket Lake S: Erste Samples noch vor Comet Lake S in Datenbanken
Von Rocket Lake S sind die ersten Samples noch vor dem Release von Comet Lake S in Datenbanken aufgetaucht. Das befeuert weiter Gerüchte, Comet Lake S werde nur ein kurzes Gastspiel haben, ähnlich wie damals Broadwell E - die heute bei Sammlern beliebten Core i5-5675C und i7-5775C lassen grüßen.
Die Gerüchteküche ist ja für gewöhnlich oft schon zeitig dran, aber dass nun ein Rocket Lake S auftaucht, während Intel noch nicht einmal Comet Lake S auf den Weg gebracht hat, lässt wohl tief blicken und sorgt gleich für die nächste Schwemme an Spekulationen. Wer noch nicht auf dem aktuellen Stand ist, hier die Kurzform: Comet Lake S soll mit neuem Sockel LGA 1200 und leichten Anpassungen Coffee Lake S im Mainstream beerben. Hauptneuerungen sind ein paar MHz mehr, SMT für alle Modelle und als Topmodell eine CPU mit 10 Kernen. Gefertigt wird weiter im hochoptimierten 14-nm-Format.
Die CPUs sind bislang noch nicht angekündigt, da taucht nun ein Rocket Lake S in der Datenbank des Geekbench auf. Das frühe Sample spuckt noch keine verwertbaren Daten aus, aber damit dürfte auch klar sein, dass die ersten Muster bereits unterwegs sind.
Da dürfte nun die Gerüchte darum noch weiter befeuern, dass Comet Lake S so eine Art Broadwell E werden könnte. Wer sich erinnert: Schon damals gabs Probleme bei der Einführung und am Ende wurden für den Mainstream eigentlich nur zwei Modelle angeboten, die nur kurz verfügbar waren und heute bei Sammlern recht beliebt sind, zumal sie als Dreingabe einen netten L4-Cache von 128 MiB haben. Der große Erfolg blieb aus und lange wurden die Prozessoren auch nicht verkauft. Man vermutet nun, dass dies auch Comet Lake S droht, denn hätten angeblich schon eingeführt werden sollen und aus welchen Gründen auch immer zieht sich die Sache nun hin. Die Corona-Krise alleine wird es nicht sein. Man nimmt an, dass Intel PCI Express 4.0 plante, aber nicht fertig wurde. Spekuliert wurde auch schon darüber, dass die hohen Taktraten in 14 nm +++ Probleme machen. Rocket Lake S wird übrigens auch in 14 nm gefertigt und hat auch nicht die Sunny-Cove-Kerne, die Intel mit fast 20 Prozent mehr IPC einordnet. Das käme erst in der Generation danach. Stattdessen soll es wohl PCI Express 4.0 geben.
Auch lesenswert: Grafik zu Rocket Lake: Intel wohl 2021 mit PCI-Express 4.0
So oder so dürfte das Thema spannender sein als die erwarteten ~10 Prozent Mehrleistung, die man üblicherweise bei einem Generationswechsel dieser Art hat. Mit mehr Spannung als die mittlerweile ohnehin weitestgehend geleakten technischen Daten wird auch die Preisgestaltung erwartet.
Zusätzlich wird ein Wärmebild gezeigt weiter unten. Der L3 heizt ganz gut mit.
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.
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.
Zusätzlich wird ein Wärmebild gezeigt weiter unten. Der L3 heizt ganz gut mit.
" 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.
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.