Bericht Intel Sapphire Rapids: Elite-Einheiten als Workload-Spezialisten

@fdsonne wir sind von Intel auf AMD Server umgestiegen. So ein Leistungsplus und so viel sparsamer, bei so viel Einsparung... wenn die Software es zulässt, dann kannst du Intel in der Pfeife rauchen.
Man sieht es ja schon an der Anzahl, Intel hat einfach einen an der Waffel.

Die Zahlen von Intel, in ihrer Serversparte, sprechen ja Bände.
 
  • Gefällt mir
Reaktionen: Illithide, eXe777, Qyxes und 2 andere
ghecko schrieb:
Sprich: die Beschleuniger sind für generischen Workflow nutzlos. Und das bei dieser wilden Anzahl an Beschleunigern, die alle angepassten Code benötigen. Jetzt verstehe ich, warum Intel das Zeug optional freischalten will. Wird eh kaum jemand nutzen. Bleibt abzuwarten, ob die Performance ohne Beschleuniger ausreicht, um im Markt zu bestehen.
Das sollte jetzt nicht verwundern. Es gibt multi-purpose CPUs, die ein Kompromiss aus Flexibilität und Durchsatz darstellen. Will man den Durchsatz spezifischer (Sub-)Berechnungen erhöhen, verschiebt man diesen Kompromiss weg von der Flexiblität hin zu erhöhtem Durchsatz. Das dies Niemand nutzen wird ist unwahrscheinlich, schau dir einfach aktuelle PCs, Smartphones etc. an. Neben der Haupt CPU hat es da GPUs samt Control CPUs für die GPU, Secure Elements, mehrere DSPs für Audio, Video neben zig Coprozessoren für Wifi, Netzwerk, USB, PCIe, ...
Wird alles genutzt, fällt nur kaum auf.

Und da Intel Ökosystem an Software schaut derzeit nicht schlecht aus. Wenn die OneApi so weitergetrieben wird wie bisher, stehen die gut da. Intel geht ja derzeit sogar soweit, dass sie ihre OneAPI derart gestalten, dass man auch Nvidia CUDA und AMD RoCm anflanschen kann[1]. Wenn das nicht sinnlos torpediert wird, ist es alsbald das sinnvollste gegen Intels API zu schreiben.

[1] Fragt mich nicht nach Quellen, hab da vor kurzem nur was überflogen. Aber es soll wohl geplant (schon umgesetzt?) sein, dass die OneApi u.a. auch SPIR-V rauslassen kann und von da an, ginge es dann auch nicht GPUs anzusprechen.
https://www.khronos.org/spir/
 
Da müsste man nun wissen wie groß der Markt für die teils doch etwas speziellen Anwendungen sind. Andererseits kann man sich eigentlich darauf verlassen dass der Bedarf an Prozessorleistung steigt, recht egal wo. >.>
Dass Intel aber kurzerhand SPEC als nicht-'real world' deklariert weil man schlechter abschneidet hat was. real world workloads sind diejenigen die von den intel <technologie hier> unterstützt wird ^^
Ich dachte die Idee bei SPEC int war dass man produktivanwendungen nimmt und einen standardisierten benchmark daraus macht.

Dazu sprang mich doch glatt ein Tippfehler in dem 10. Bild an. 'In-field Scan' vs. 'In-Filed Scan', das wurde entweder hektisch getippt, oder nicht genug korrekturgelesen.
Aber da die auch mit Tabellenspalten überfordert waren wars wohl einfach zu eilig. ^^

Kann mich jemand aufklären was mit 'Glueless Topologies' gemeint ist? Die Kleber-anspielungen kenne ich nur aus dem Spott über das chiplet design, doch das macht Intel ja nun selbst und hat mit Sockeln auf den ersten Blick auch nicht viel zu tun. Bezieht sich das darauf dass AMD keine 8-Sockel-Systeme bietet?
 
  • Gefällt mir
Reaktionen: Mcr-King
@Bigeagle Intel sollte mal den Rand halten von wegen Kleber. Haben die doch selbst gemacht auf dem C2Q. Also, Intel, Schnabel halten und zeigen, was ihr habt. Jede Menge Lego, was eine gute Analogie ist, von wegen "die großen Teile, die werden teuer, aber hier sind 5.000 kleine Teile, die ohne große Teile einfach Mist sind."
 
Bigeagle schrieb:
Kann mich jemand aufklären was mit 'Glueless Topologies' gemeint ist? Die Kleber-anspielungen kenne ich nur aus dem Spott über das chiplet design, doch das macht Intel ja nun selbst und hat mit Sockeln auf den ersten Blick auch nicht viel zu tun. Bezieht sich das darauf dass AMD keine 8-Sockel-Systeme bietet?
Edit: Stellt sich raus, hier steht Mist zum "glueless", hätte mal nachschauen sollen.

Wohlwollend gegenüber Intel interpretiert: Intel nutzt EMIB[1] und AMD klebt derzeit "nur" Chips auf den organischen Träger und wickelt darüber alle Verbindungen ab.
Was aber so ein bisschen sinnlos ist als Punkt für die Vermarktung. Zum einen hat AMD mit RDNA3 gezeigt, wie sie zusammen mit Partnern die Verbindungsdichte auf organischen Trägern deutlich steigern konnten und zum Anderen nimmt man halt auch kein EMIB samt Kostensteigerung, solang es nicht zwingend ist. Wobei Infinity Fabric bei AMD Zen4 CPUs derzeit wirklich grenzwertig sein kann: https://chipsandcheese.com/2023/01/05/amds-zen-4-part-3-system-level-stuff-and-igpu/

[1] Verbindung zwischen den großen Chips über ein Silizium Die zwischen den großen Chips
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Bigeagle und Mcr-King
Ich glaube die AMD MI300 ist um einiges schneller und hat auch mehr speicher
 
  • Gefällt mir
Reaktionen: Mcr-King
@Ghostshield
Beim Speicher, ja Mi300 hat mehr HBM Speicher, Sapphire Rapids kann aber insgesamt mehr DDR5 Speicher anbinden. Kommt auf die Anwendung drauf an.

Und ob $foo schneller ist als $bar kommt oft auf die Anwendung, Optimierung und Softwareökosystem an. Es wird Fälle geben, wo MI300 mehr schafft als Sapphire Rapids fürs selbe Geld und umgekehrt. Wobei ich bei AMD derzeit Lücken sehe. Deren AVX512 Vektorimplementierung ist derzeit ja "nur" 256bit + 256bit, Matritzenoperationen wie sie Intel AMX bietet gibt es derzeit meines Wissens nach nicht und AMDs RoCm/AOCC Ökosystem gegen Intels OneApi + Bibliotheken ist unschön.

Edit: Kurz nachgeschaut, AMDs CDNA2/3 kann Matrixoperationen. CDNA3 macht gar einen großen Sprung im Durchsatz, da müsste sich aber mal jemand der sich damit auskennt anschauen wie gut das für Machine Learning taugt.
 
Zuletzt bearbeitet:
Piktogramm schrieb:
@Ghostshield
Beim Speicher, ja Mi300 hat mehr HBM Speicher, Sapphire Rapids kann aber insgesamt mehr DDR5 Speicher anbinden.
Gut Sapphire Rapids hat viel Speicher.
Dafür liefert MI300 2 Exaflops pro Sockel.
Und auch dort lässt sich sicherlich noch mehr speicher verbauen, also mehr als die 128GB HBM3
 
  • Gefällt mir
Reaktionen: sebastian_uniq und Mcr-King
@Ghostshield
Die reine Angabe von Exaflops ist vergleichsweise sinnlos, wenn man nicht rein zufällig perfekt vektorisierbare Probleme bzw. voll gefüllte Matritzen zu berechnen hat. Bei so komplexen Systemen muss man genauer hinschauen, welche Anwendung unter Welchen Bedingungen wie skaliert und umsetzbar ist.
Bei den spärlichen Informationen die AMD zu Mi300 geteasert hat, ist bisher nur HBM-Speicher und ein PCIe (bzw. CXL3) Interface ersichtlich. Also nach bisherigem Stand keine Erweiterung von DDR5 Speicher, ohne dass der Umweg über eine normale CPU genommen werden muss. Da kommt es dann wieder darauf an, ob sich eine bestimmte Anwendung mit dem Flaschenhals dieser Schnittstellen gut abbilden lässt oder nicht.

Und Videos.. ich schau mir kein +15min Video an, vor allem wenn du nichtmal hinschreibst auf welchen springenden Punkt du mit dem Video verweisen willst. Verlinke Text und wenn es irgendwas nur als Video/Audio geben sollte doch bitte Zeitstempel und schreib 1..2 Sätze dazu, worauf du dich in der Quelle beziehst.
 
  • Gefällt mir
Reaktionen: CCIBS und Novasun
Ich hab jetzt noch nicht verstanden, wo der Unterschied von Intels neuem Beschleuniger "DSA" zu einem klassischen und auf mittlerweile praktisch jedem popeligen 32Bit Mikrocontroller vorhandenem DMA-Controller ist?
Gib nen Pointer zur Start- und Zieladresse, gib die Länge des Datenblock, und ab gehts. Nichts anderes macht laut der Folien auch der DSA...?
Zwischenablage01.jpg
 
fdsonne schrieb:
Die TopEnd Produkte stehen bei Intel seit je her in der Kritik, vor allem wegen des (Listen) Preises - aber kaufen tut den Kram halt nur ein Bruchteil, der große Block kauft irgendwo im Bereich 12, 16, 20C, wenn es überhaupt schon so viel sind...

Ja, bei uns stehen Server mit 8C und 12C herum. In den letzten Jahren haben wir ueberwiegend Ryzens gekauft, aber auch ein paar Intels (Xeon W und Xeon E). Wobei fuer uns die Intels zuletzt folgende Nachteile hatten: Prozessoren nur als Tray-Versionen verfuegbar und das auch nur bei wenigen Haendlern, oft ausverkauft, oder zu sehr hohen Preisen, und bei den Boards schaut es auch so aus. Immerhin ist ersteres jetzt dadurch gefixt, dass man manche Core i-Prozessoren verwenden kann und keinen Xeon W mehr braucht. Aber bei den Boards schaut's schlimm aus: Zwar finde ich inzwischen 5 Boards mit ECC-Unterstuetzung, aber jenseits von EUR450. Bei AM5 faengt's dagegen unter EUR 190 an, und bei AM4 unter EUR 60.

Mag fuer Kunden, die sich fertige Server kaufen, nicht so entscheidend sein, aber wir hatten einmal solche (von HP), danke, nie wieder: lauter proprietaeres Zeug drinnen, und lange gemacht haben sie's auch nicht.

Früher gab es dazu noch parallel ein kleines Lineup - bspw. AMDs C32 neben den G34 Produkten. Oder Intels E3/E/W Xeons analog der Mainstream Plattform. Über geblieben ist heute primär nur noch die embedded Xeon D Reihe - und die ist schwer bis nicht zu bekommen abseits OEM Geschäften.

Bei AMD kann man einfach eine Desktop-CPU nehmen (bei APUs nur Pro) und ein Desktop-Board mit ECC-Unterstuetzung (gibt's eine Menge, siehe oben); wenn's IPMI sein muss, halt von Asrock Rack (derzeit nicht fuer AM5). Bei Intel gibt's statt Xeon W jetzt Core i, wie oben beschrieben. Xeon E kommt immer deutlich spaeter als die entsprechenden Desktops, derzeit sind's noch Rocket Lakes, und die Verfuegbarkeit war letzten Mai sehr duerftig, wie oben beschrieben; und bei den Boards schaut's auch nicht wirklich besser aus, und teuer ist das alles daher auch.
Ergänzung ()

Bigeagle schrieb:
Kann mich jemand aufklären was mit 'Glueless Topologies' gemeint ist?

Normalerweise heisst das bei Mehrprozessorsystemen, dass die Prozessoren direkt miteinender sprechen statt ueber einen Kommunikationschip (den Glue). Dadurch werden Mehrprozessorsysteme einfacher und billiger zu bauen. M.W. sind die 2P-Epycs glueless miteinander verbunden. Man koennte natuerlich die innere Architektur von EPYCs und Ryzens mit mehr als einem CCD als Architektur mit glue (naemlich dem IO-Die) bezeichnen, aber das ist ja AMDs internes Problem, da das Teil der Kosten des Chips ist; das Board wird dadurch jedenfalls nicht teurer.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Bigeagle und Mcr-King
jusaca schrieb:
Ich hab jetzt noch nicht verstanden, wo der Unterschied von Intels neuem Beschleuniger "DSA" zu einem klassischen und auf mittlerweile praktisch jedem popeligen 32Bit Mikrocontroller vorhandenem DMA-Controller ist?
Gib nen Pointer zur Start- und Zieladresse, gib die Länge des Datenblock, und ab gehts. Nichts anderes macht laut der Folien auch der DSA...?
Anhang anzeigen 1310175
Der Unterschied ist halt, daß man nur eine Instruktion braucht, und nicht ständig hin und her mit "jetzt ein Quad Work kopieren, danke. Achso, jetzt nur 16/8 bit weil wir am Ende sind? Supah."

Einfach ein weiteres Beispiel von spezieller Optimierung. Ist ja auch toll, aber auch nur für strcpy() usw. Fälle wo man weiß, wie lang die buffer sind.
 
60 Kern CPU optimiert für z.B. Virtualisierung. Aber der Preis ist teuer.
 
  • Gefällt mir
Reaktionen: Mcr-King
Also die Idee mit Acceleratoren ist ja schön und gut und kann viel bewirken wenn man einer der glücklichen ist die davon profitieren.
Nur hat quasi jede zweite SKU nur ca. die hälfte oder einfach teilweise gar keine aktiven Acceleratoren.
Der Vergleich dieser mit AMD wirkt auch etwas merkwürdig, wie andere mit der MI300 bsp. ansprachen.

Die generelle Effizienz scheint wohl auch nicht der Bringer zu sein, wenn man damit gar nicht weiter wirbt.

Das AMD eine Roadmap mit pünktlichen Nachfolgern in die Folien packt ist klar, da muss man das Vertrauen und kontinuierliche Fortschritte und Entwicklung aufzeigen, aber Intel? Da kommt es mir immer etwas komisch vor wenn man gleich 1-2 Nachfolger kurz erwähnt.

Das bestärkt mich auch erneut darin, das Intel inzwischen bei Server/HPC nur noch was für die Nische ist, nicht mehr für das normale "Alltagsgeschäft".
 
  • Gefällt mir
Reaktionen: Mcr-King
Gibt halt in der Tat Serveranwendungen wo Du einfach viele Daten im Speicher vorhalten willst, die CPU aber nichts weiter macht als diese Daten auf Anfrage bereit zu stellen.

Dementsprechend ist Intels Hinweis auf "workloads" nicht ganz falsch, wobei man sagen muss dass eine CPU welche auf SPEC INT optimiert ist, wenn sie dort schnell genug ist, diese workloads auch spielend hinbekommt. Ist die Frage nach der Effizienz und da dürfte Intel den accelerator-Weg evtl gehen weil ihre Fertigung bei einem reinen SPEC INT-Monster diese Effizienz vermissen lässt (im Gegensatz zu einem z.B. bei TSMC in deren 5er Prozessen gefertigten SoC) und Intel über specialiced silicon eben wieder auf Effizienz kommt.

Vermutlich werden größere Häuser erstmal benchmarks mit eigenen Anwendungen laufen lassen müssen um belastbare Daten zu haben.
 
  • Gefällt mir
Reaktionen: Col. Jessep
Aus Intel Sicht versuchen sie mit Sicherheit "Intel on demand" weiter auszubreiten und immer mehr Features hinter weiteren Paywalls zu verstecken: wieso nur 1x für Hardware Geld verlangen, wenn man es X-mal, am besten im Abo immer wieder machen kann?

Würde mich nicht wundern, wenn AMD auf den Zug über Kurz oder Lang auch aufspringt weil es so unglaublich lukrativ ist...

Auto, PCs, Filme/Serien, Spiele usw. alles wird immer weiter in Richtung "recurring revenue" verschoben und man schließt zumindest in Fällen wo das Eigentum der Hardware zum Kunden übergeht diese dann auch explizit aus bereits vorhandenen Funktionen des Kunden-Eigentums aus. Solang es aber keine Regeln für Hardware und dessen Features gibt, wird der Trend weitergeführt werden und am Ende darf man dann pro extra 100MHz extra oberhalb von 2GHz 2€ extra im Monat abdrücken weil wieso nicht? Ist legal und die Argumentation "da muss wer am Ende auch wer Low-Level-Software für schreiben" greift auch hier...
 
Piktogramm schrieb:
Wohlwollend gegenüber Intel interpretiert: Intel nutzt EMIB[1] und AMD klebt derzeit "nur" Chips auf den organischen Träger und wickelt darüber alle Verbindungen ab.
Falsch! Hat mit Fertigung aber mal gar nichts zu tun!

Bigeagle schrieb:
Kann mich jemand aufklären was mit 'Glueless Topologies' gemeint ist?
Google kaputt?
1673431909495.png


Vereinfacht ausgedrückt, bei der "glueless" Architektur, kann jede CPU selbsttätig mit einer anderen Daten austauschen, bei "glued" werden Controller für die Kommunikation eingesetzt.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Bigeagle, Piktogramm, hans_meiser und 3 andere
Zurück
Oben