News Intel Sapphire Rapids: Next-Gen-Server-CPU mit HBM wird ab Q1 2022 gefertigt
- Ersteller Volker
- Erstellt am
- Zur News: Intel Sapphire Rapids: Next-Gen-Server-CPU mit HBM wird ab Q1 2022 gefertigt
Draco Nobilis
Banned
- Registriert
- Jan. 2012
- Beiträge
- 2.943
Hm also Irgendwas musste ja kommen, nachdem AMD da mit Cache stapeln News kam.
Es wurde ja auch echt langsam "Zeit".
Da Release noch in den Sternen (2022, oder so...) steht, ähnlich wie bei AMD, abwarten.
Bis etwa Umsatzparität herrscht darf meinetwegen AMD gerne weiter vorneweg laufen.
Finde die Sprünge inzwischen bei beiden Anbietern sehr extrem, vgl. zu intel Core 4-8th Gen.
Wettbewerb ist halt leider geil.
Es wurde ja auch echt langsam "Zeit".
Da Release noch in den Sternen (2022, oder so...) steht, ähnlich wie bei AMD, abwarten.
Bis etwa Umsatzparität herrscht darf meinetwegen AMD gerne weiter vorneweg laufen.
Finde die Sprünge inzwischen bei beiden Anbietern sehr extrem, vgl. zu intel Core 4-8th Gen.
Wettbewerb ist halt leider geil.
Piktogramm
Admiral
- Registriert
- Okt. 2008
- Beiträge
- 9.254
Jain,Skysnake schrieb:
HBM braucht für einzelne Zugriffe länger, erlaubt es theoretisch aber die 128bit Kanäle auf 2*64bit aufzuteilen. Bei einer Anbindung mit 1024bit resultieren also 16 parallel agierende Kanäle. Was bei parallelen Zugriffen die gemittelte Latenz etwas besser dastehen lässt als Dram der 1-8Kanäle nutzt[1]. Bei Desktopsystemen mit typischerweise zwei Kanälen wäre das schon ein ordentlicher Unterschied. Bei Servern kommt es dann drauf an was wirklich in den Memory Slots steckt. Bei einer Bestückung von 8x unregistered Dram Modulen wird es nicht mehr so viel bringen. Wenn aber 8x registered Dram steckt, dürfte so ein HBM Stack wieder besser dastehen.
[1] Voraussetzung ist natürlich, dass es überhaupt entsprechend viele, parallelisierbare Zugriffe gibt.
PS: Welche zu berechnenden Abhängigkeiten meinst du? Wenn der Speicher als Cache drinnen hängt, dann wird da meist sowieso wenig gerechnet und wenn der das HBM Modul als Arbeitsspeicher adressiert ist, macht MMU was sie immer macht.. hoffen das die benötigten Daten im TLB liegen
Da sehe ich keine große Änderung.
Bei indirekter Addressieung z.b. die Adresse des Speicherzugriffes berechnen. Da hängst du voll in der seriellen Performance vom Core und wenn es spare/random genug ist auch voll im RAM. Ubd genau bei solchen Problemen wo es richtig weh tut hilft zwar ein größerer Cache (SRAM/eDRAM) aber kein HBM oder HMC, auch wenn er wie ein Cache funktioniert.
- Registriert
- Juni 2001
- Beiträge
- 18.788
Artikel-Update: Lisa Spelman, bei Intel verantwortlich für Xeon- und Speicher-Produkte, hat weitere Informationen zur nächsten Generation Xeon auf Basis von Sapphire Rapids bekanntgegeben. Dazu zählt neben dem Termin für den Start der Fertigung, die im 1. Quartal an- und im 2. Quartal 2022 dann hochlaufen soll, auch eine Aussage zum von Intel erwarteten Leistungsvorteil durch die Integration von Advanced Matrix Extensions (AMX). AMX beschleunigt die beim KI-Training und Inferencing so wichtige Matrizen-Multiplikation, gegenüber der aktuellen Generation sei Intel im Labor bereits „mühelos über 100 Prozent Leistungszuwachs“ erzielt worden. Dass Sapphire Rapids AMX bieten wird, ist bereits seit einem Jahr offiziell bekannt.
Erstmals von Spelman erwähnt wird, dass Sappire Rapids auch einen Data Streaming Accelerator (DSA) enthalten wird, wie ihn Intel als Nachfolger von QuickData bereits im Jahr 2019 vorgestellt hatte – damals aber noch ohne Produkt-Bezug. DSA soll in Umgebungen, in denen es vorrangig um das Bewegen oder Bearbeiten von Daten geht, Leistung auf den klassischen CPU-Kernen freischaufeln und die Leistungsfähigkeit des Gesamtsystems so signifikant erhöhen.
Mit signifikanten Stückzahlen vermutlich erst ab dem 3. Quartal 2022 erscheint die neue Intel-Xeon-Generation später, als es noch zum Start von Ice Lake-SP erwartet wurde. Intel kommentiert das zwar nicht direkt, verweist aber auf die vielen Anpassungen, für deren Validierung man sich mehr Zeit eingeräumt hätte, bevor die Serienproduktion startet.
Erstmals von Spelman erwähnt wird, dass Sappire Rapids auch einen Data Streaming Accelerator (DSA) enthalten wird, wie ihn Intel als Nachfolger von QuickData bereits im Jahr 2019 vorgestellt hatte – damals aber noch ohne Produkt-Bezug. DSA soll in Umgebungen, in denen es vorrangig um das Bewegen oder Bearbeiten von Daten geht, Leistung auf den klassischen CPU-Kernen freischaufeln und die Leistungsfähigkeit des Gesamtsystems so signifikant erhöhen.
Mit signifikanten Stückzahlen vermutlich erst ab dem 3. Quartal 2022 erscheint die neue Intel-Xeon-Generation später, als es noch zum Start von Ice Lake-SP erwartet wurde. Intel kommentiert das zwar nicht direkt, verweist aber auf die vielen Anpassungen, für deren Validierung man sich mehr Zeit eingeräumt hätte, bevor die Serienproduktion startet.
Schau nur kurz
Banned
- Registriert
- Mai 2021
- Beiträge
- 100
Verlässlich holt jeder Intel-Artikel die Trolle und AMD-Basher aus ihren HöhlenBAR86 schrieb:
. Aber von Technik keine Ahnung.
Nö! Meines Wissens soll Genoa irgendwann im kommendem Jahr kommen, Sapphire Rapids ist hingegen für dieses Jahr geplant. Den Schritt zu DDR5, PCIe5.0, CXL und HBM Cache zieht Intel also gut ein Jahr vor AMD durch, mit Genoa soll im kommendem Jahr dann Granite Rapids konkurrieren.Makso schrieb:
Draco Nobilis
Banned
- Registriert
- Jan. 2012
- Beiträge
- 2.943
Hm das lese ich aber anders, hast du dafür eine Quelle?xexex schrieb:
Volker hat diesbezüglich den Artikel schon geupdatet. Und Seien wir ehrlich, Intel hat bisher vor allem durch Verspätungen geglänzt, während AMD/TSMC in letzten Jahren da eher weniger auffielen. Da fehlt es eher an DIE-Kontingenten, die AMD sich einfach nicht auf x Jahre im Vorraus sichern konnte. Intel bekommt wegen Aurora selbst von der USA schon mächtig eine Pistole auf die Brust gesetzt.
Beleg wegen Aurora Verzögerung, weil Intel:
https://www.heise.de/news/Exascale-...s-Fertigungsproblemen-verzoegert-4924337.html
Liest sich wie das man mit den gruseligen Yields erstmal die Server und Datacenter bedienen will, bevor man völlig das Gesicht verliert.Volker schrieb:
Piktogramm
Admiral
- Registriert
- Okt. 2008
- Beiträge
- 9.254
@Skysnake
Das berechnen von Speicheraddressen juckt eine super skalare OoO CPU doch kaum. Mir fallen auf Anhieb keine Alltags/Desktopanwendungen ein, bei dem mir das realistisch erscheint, dass eine CPU ein Großteil seiner Zeit zum Berechnen von Adressen benutzt. Selbst Server sollten da nur selten rein laufen.
Selbst wenn, selbst dann wäre es schon nützlich 16 statt 1-8 parallele r/w auf den HBM Cache zu werfen anstatt auf den Ram. Natürlich unter der Voraussetzung, dass sich Zugriffsmuster abbilden, die sinnvolles Caching erlauben. Darauf ist aber jede Form von Cache angewiesen.
Das berechnen von Speicheraddressen juckt eine super skalare OoO CPU doch kaum. Mir fallen auf Anhieb keine Alltags/Desktopanwendungen ein, bei dem mir das realistisch erscheint, dass eine CPU ein Großteil seiner Zeit zum Berechnen von Adressen benutzt. Selbst Server sollten da nur selten rein laufen.
Selbst wenn, selbst dann wäre es schon nützlich 16 statt 1-8 parallele r/w auf den HBM Cache zu werfen anstatt auf den Ram. Natürlich unter der Voraussetzung, dass sich Zugriffsmuster abbilden, die sinnvolles Caching erlauben. Darauf ist aber jede Form von Cache angewiesen.
Solange Intel nicht auch die Leistung bei dem bereits Angekündigtem Aurora Supercomputer noch drastisch erhöht, mache ich mir wenig bis keine Gedanken um meine AMD Aktien.
die Verbesserungen waren Intel längst bekannt und sind bei der Berechnung der Arora Leistung mit eingeflossen, gut das es nun bisschen später wird shit happens.
Hoffe nur AMD gewinnt noch ein paar mehr wichtige Marktanteile bevor Intel wieder auf oder schlimmsten falls überholt hat
die Verbesserungen waren Intel längst bekannt und sind bei der Berechnung der Arora Leistung mit eingeflossen, gut das es nun bisschen später wird shit happens.
Hoffe nur AMD gewinnt noch ein paar mehr wichtige Marktanteile bevor Intel wieder auf oder schlimmsten falls überholt hat
OK ... das Ding kommt also Q4 2022 🤦♂️
Jedesmal wenn sich Intel zu Sapphire Rapids äußert, kommt das Teil irgendwie 1-2 Quartale später. Kann das sein?
Die Chancen stehen nicht schlecht, dass SPR im gleichen Zeitraum (+/- 1-3 Monate) wie Genoa kommt ... und dann natürlich wieder haushoch verliert.
Und SPR wird sich natürlich gegen Milan schon schwer tun (besonders wenn es davon dann auch Versionen mit 3D V-Cache gibt)
Ich schätze AMD wird bis Ende 2022 auf 30% Market Share kommen mit Epyc. (Wenn nicht sogar mehr). Und dann bis 2025 auf 50% od mehr. Davor kommt GARANTIERT nix, was Epycs mit Zen 5 auf TSMC 3nm (bzw, dann Zen 6 od. irgendwelche nextgen Cores in 2nm) auch nur ansatzweise gefährlich werden könnte)
Jedesmal wenn sich Intel zu Sapphire Rapids äußert, kommt das Teil irgendwie 1-2 Quartale später. Kann das sein?
Die Chancen stehen nicht schlecht, dass SPR im gleichen Zeitraum (+/- 1-3 Monate) wie Genoa kommt ... und dann natürlich wieder haushoch verliert.
Und SPR wird sich natürlich gegen Milan schon schwer tun (besonders wenn es davon dann auch Versionen mit 3D V-Cache gibt)
Ich schätze AMD wird bis Ende 2022 auf 30% Market Share kommen mit Epyc. (Wenn nicht sogar mehr). Und dann bis 2025 auf 50% od mehr. Davor kommt GARANTIERT nix, was Epycs mit Zen 5 auf TSMC 3nm (bzw, dann Zen 6 od. irgendwelche nextgen Cores in 2nm) auch nur ansatzweise gefährlich werden könnte)
TechFA
Lieutenant
- Registriert
- Okt. 2018
- Beiträge
- 731
Naja, einst war Sapphire Rapids 2017 für 2020 angekündigt, dann hieß es schon 2019 dass Sapphire Rapids erst 2021 kommt. Und jetzt geht man Anfang 2022 überhaupt erst in Produktion für breite Verfügbarkeit ab Mitte 2022 bis Anfang 2023! Das sind drei Jahre Verspätung!tarkin77 schrieb:
Tut mir leid, aber Wer Intel nach all den zahllosen Prozess-Problemen noch irgendeinen Funken Glauben schenkt, dem ist wirklich selbst damit nicht mehr zu helfen, dass Intel faktisch seit ihrem 32nm-Prozess anno dazumal niemals mehr zeitlich terminiert abgeliefert hat, ohne vorher den Termin wenigstens einmal verschoben zu haben.
Wenn man wie Intel ständig nachträglich die Ziel-Linie vorverlegt, ist man halt immer "pünktlich" …
Der Laden hat wirklich ein ernsthaftes Wahrheitsproblem, wenn jede schlechte Nachricht grundsätzlich scheibchenweise in feinster Salami-Taktik enthüllt wird, nur damit es den geringst-möglichen Einfluss auf ihren Aktienkurs hat. Es kann mir Keiner erzählen, dass es nicht schon 2017 absehbar war, dass es 2020 nix wird.
Erinnerst sich noch Wer, dass Intel 2016 noch Stein und Bein geschworen hat, dass die ersten 10nm-Chips noch 2017 auf den Markt kommen und jegliche Gerüchte über Verzögerungen vehement bestritten haben?
… weiß TechFA
sehr lustig! Das schreib ich übrigens grad auf meiner Radeon, aber du hast halt von Menschenkenntnis keine AhnungSchau nur kurz schrieb:Verlässlich holt jeder Intel-Artikel die Trolle und AMD-Basher aus ihren Höhlen
Ergänzung ()
Die haben auch von Technik keine Ahnung und spielen nicht besonders schnell, stimmt. Aber dafür teilweise herrlich aggressive FansSmartbomb schrieb:
Ergänzung ()
hat dir Intel irgendwas getan? Beide Firmen haben schon oft Termine verschieben müssen oder Produkte gar gecancelt, Paperlaunches rausgehauen etcMakso schrieb:
Zuletzt bearbeitet:
Das Problem ist nicht die execution oder sonst was, sondern serielle Code der keine spekulative execution oder OoO zulässt weil er eben vom vorherigen Ergebnis abhängt und/oder random access ist. Sowas hat man besonders gerne bei C++ Code oder sonstigen Desktop Anwendungen.Piktogramm schrieb:
Und sowas ist gar nicht so selten wie man meint.
Piktogramm
Admiral
- Registriert
- Okt. 2008
- Beiträge
- 9.254
@Skysnake
In solchen Fällen verbringt die CPU aber großteils mit Warten und nicht mit dem Berechnen von Speicheradressen?! Bei genau diesem Warten hilft es dann auch, wenn mehrere CPUs/CPU-Threads Treffer auf dem HBM Cache landen können, wenn dieser mehr parallele Zugriffe schafft als der RAM. Wenn auch mit etwas höheren Latenzen für jeden einzelnen Vorgang.
Beim Desktop fällt mir dann auch nicht viel an Anwendungen ein, die sowas ernsthaft betreiben. Vor allem nicht, wenn ich mal knappe 1GB HBM-Cache annehme.
In solchen Fällen verbringt die CPU aber großteils mit Warten und nicht mit dem Berechnen von Speicheradressen?! Bei genau diesem Warten hilft es dann auch, wenn mehrere CPUs/CPU-Threads Treffer auf dem HBM Cache landen können, wenn dieser mehr parallele Zugriffe schafft als der RAM. Wenn auch mit etwas höheren Latenzen für jeden einzelnen Vorgang.
Beim Desktop fällt mir dann auch nicht viel an Anwendungen ein, die sowas ernsthaft betreiben. Vor allem nicht, wenn ich mal knappe 1GB HBM-Cache annehme.
Der "Cache" hilft dir aber nur, wenn das DDR Interface nicht ausreichen würde. Und um in den Fall zu laufen müsstest du schon sehr viele Threads laufen haben. Typischerweise wohl mehr als cores inkl SMT.
Wie gesagt, man kann relativ leicht testen, ob der "Cache" was bringen würde indem man ein Server Modell mit wenigen Cores wie die Desktops nimmt und dann einmal mit 4und einmal mit 8 RAM Channels testet. Da wird man bei Desktopanwendungen kaum einen Unterschied sehen.
Das ist wirklich nur für Server interessant und da auch nicht für jeden. Datenbanken, Webserver etc werden davon nicht profitiere, sondern nur Server die Simulationen machen. Aber auch nicht alle. Wenn man Graphen oder sonst was mit spare Vektor/Mateix macht, wirds auch schon schwierig wegen der indirekten Addressierung. Wobei man da dann mit mehr Threads was reißen kann und eventuell genug Fleisch an Berechnung mit dem Datum hat.
Am Ende läuft es halt doch wieder auf Amdahl raus.
Wie gesagt, man kann relativ leicht testen, ob der "Cache" was bringen würde indem man ein Server Modell mit wenigen Cores wie die Desktops nimmt und dann einmal mit 4und einmal mit 8 RAM Channels testet. Da wird man bei Desktopanwendungen kaum einen Unterschied sehen.
Das ist wirklich nur für Server interessant und da auch nicht für jeden. Datenbanken, Webserver etc werden davon nicht profitiere, sondern nur Server die Simulationen machen. Aber auch nicht alle. Wenn man Graphen oder sonst was mit spare Vektor/Mateix macht, wirds auch schon schwierig wegen der indirekten Addressierung. Wobei man da dann mit mehr Threads was reißen kann und eventuell genug Fleisch an Berechnung mit dem Datum hat.
Am Ende läuft es halt doch wieder auf Amdahl raus.
