- Dieser auf der Hot Chips 2023 vorgestellte Forschungs-Chip zielt auf die Verarbeitung ultradünn besetzter Daten für DARPA HIVE ab und bietet mit 8 Kernen insgesamt 528 Hardware-Threads
- Die Workload-Analyse zeigte zwar hohe Parallelität, aber eine geringe Cache-Line-Ausnutzung und eine niedrige Effizienz langer Out-of-Order-Pipelines, weshalb ein anderes Design als bei normalen Server-CPUs nötig war
- Der Prozessor basiert nicht auf x86, sondern auf einer RISC ISA und verarbeitet mit 66 Threads pro Kern sowie einer Multithread-Pipeline massive Nebenläufigkeit
- Die Kommunikation zwischen Chips erfolgt über ein direktes optisches Mesh-to-Mesh-Fabric auf Basis von Silizium-Photonik, sodass auch mit Kernen außerhalb des Chassis ohne Switches und NICs direkt kommuniziert werden kann
- Die Implementierung ist eine TSMC-7nm-CPU mit 8 Kernen und 75 W; da mehr als die Hälfte der Leistung für die optischen Verbindungen aufgewendet wird, bleibt es vorerst ein experimentelles Design im Laborstadium
528-Thread-CPU für DARPA HIVE
- Auf der Hot Chips 2023 zeigte Intel zusätzlich zu herkömmlichen Server-Chips die Technologie eines direct mesh-to-mesh optical fabric
- Das zentrale Ziel des Designs ist die Verarbeitung ultradünn besetzter Daten, wie sie im DARPA-HIVE-Programm gefordert wird
- Intels Workload-Profiling zeigte Eigenschaften, die nicht zu einem klassischen CPU-Design passen
- Es gibt massive Parallelität
- Die Cache-Line-Ausnutzung ist gering
- Lange Out-of-Order-Pipelines werden nicht ausreichend genutzt
- Daraufhin wurde der Prozessor als 8-Kern-Sockel-Design entworfen
- 66 Hardware-Threads pro Kern
- insgesamt 528 Threads
- RISC ISA statt x86
- Jeder Kern verwendet eine Multithread-Pipeline
Direkte Chip-zu-Chip-Verbindung mit Silizium-Photonik
- Der Chip verwendet eine Konfiguration, bei der 16 Sockel in einem einzelnen OCP Compute Tray untergebracht und per optischem Netzwerk verbunden werden
- Ein Hochgeschwindigkeits-I/O-Chip verbindet elektrische Signale mit optischen Funktionen
- Im On-Die-Netzwerk sind Router platziert; die Hälfte der 16 Router dient dazu, dem High-Speed-I/O mehr Bandbreite bereitzustellen
- In der physischen Verbindungsschicht innerhalb des Packages kommt EMIB zum Einsatz
- Bei der Off-Die-Verbindung treibt jeder Chip das optische Netzwerk über Silizium-Photonik an
- Verbindungen zwischen Kernen können direkt über Chip-Grenzen hinweg erfolgen
- Auch außerhalb desselben Chassis ist eine Verbindung ohne Switches und NICs möglich
- Der gesamte Chip besteht aus einem EMIB-basierten Multi-Chip-Package
- Durch die Integration der Silizium-Photonik-Engine entstanden zusätzliche Herausforderungen an der Stelle, an der das Package in Glasfaserstränge übergeht
- Hinsichtlich des Stromverbrauchs handelt es sich um eine 8-Kern-75W-CPU; mehr als die Hälfte der Leistung entfällt auf die Silizium-Photonik
- Auf realen Die-Fotos wurde die Nutzung des TSMC-7nm-Prozesses bestätigt, und die Arbeiten laufen weiterhin im Labor
- Beim optischen Verbindungsteil erhielt Intel Unterstützung von Ayar Labs
- Der von Intel auf der Innovation 2022 vorgestellte steckbare Connector wurde in dieser Implementierung nicht verwendet
1 Kommentare
Meinungen auf Hacker News
Bei 66 Threads pro Kern sieht das mehr als alles andere nach einem Barrel-Prozessor aus.
Man sollte wohl nicht erwarten, dass jeder Thread schnell ist, aber wenn der Prozessor genug zu tun hat, kann er die meiste Zeit nützliche Arbeit verrichten, statt auf den Speicher zu warten.
Die größte Schwäche von Barrel-Prozessoren liegt auf der menschlichen Seite. Es gibt nur sehr wenige Leute, die Code so entwerfen können, dass er ihr Potenzial wirklich ausschöpft. Gewöhnlicher Code läuft auch einigermaßen, daher wirkt es auf Code-Ebene vertraut, aber für jemanden, der nur Code für CPUs geschrieben hat, muss man ihn auf eine sehr seltsame Weise strukturieren, sonst kommt kaum Performance heraus.
Es ist eine ungewöhnliche Architektur für den Entwurf von Datenstrukturen und Algorithmen, und es gibt auch nicht viel Literatur zum Algorithmendesign für Barrel-Prozessoren.
Ich habe seit den alten Tera-Systemen Code für mehrere Barrel-Prozessor-Architekturen entworfen und bin ziemlich gut darin geworden; meiner Ansicht nach können sie bei General-Purpose-Computing mit einem vergleichbaren Siliziumbudget rechnerisch effizienter sein als fast jede andere Architektur, wenn jemand sie nutzt, der sich wirklich damit auskennt.
Um effizienten Code zu schreiben, muss man allerdings ein deutlich komplexeres Modell im Kopf behalten als bei entsprechendem CPU-Code. Wirtschaftlich sind Architekturen wie CPUs im Vorteil, bei denen auch durchschnittliche Engineers eine ordentliche Effizienz erreichen können.
Trotz der Vorteile bei der reinen Recheneffizienz habe ich die Erwartung aufgegeben, dass wir noch einmal einen Mainstream-Barrel-Prozessor sehen werden.
Dieser Teil des Kerns ist einer herkömmlichen GPU sehr ähnlich.
Der Unterschied bei dieser experimentellen Intel-CPU ist, dass jeder Kern zusätzlich zu dem GPU-artigen Teil auch 2 sehr schnelle Threads enthält. Diese 2 führen Out-of-Order aus, laufen mit einem deutlich höheren Takt als die langsamen Threads und haben jeweils eigene, nicht geteilte Ausführungseinheiten.
Die 2 schnellen Threads und die 64 langsamen Threads ähneln für sich betrachtet älteren CPUs bzw. GPUs; neu ist, dass sie in einem einzigen Kern mit gemeinsamem Scratchpad-Speicher und Cache kombiniert sind.
https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&d...
Ich würde wetten, dass das DARPA-Projekt, das diese Forschung unterstützt hat, aus derselben Linie von Drei-Buchstaben-Akronym-Interessen stammt, durch die Tera genug Geld bekam, um Cray zu kaufen.
Wenn man „auf Speicher warten“ durch „auf Ein-/Ausgabe warten“ ersetzt, ist das fast dasselbe Bild.
Während ein langsamer Fetch läuft, kann das System parallel mehr Instruktionen anderer Threads ausführen.
Marvell hat eine SMT8-ARM-CPU gebaut, die mit 768 Threads Per Node beworben wurde.
https://www.servethehome.com/marvell-thunderx3-arm-server-cp...
Soweit ich mich erinnere, zielte sie auf Datenbank-Workloads, und die Kernlogik war dieselbe: Wenn Kerne normalerweise untätig auf RAM warten, kann man in der Zwischenzeit andere Threads abarbeiten.
IBM und Zen4C decken diese Nachfrage bis zu einem gewissen Grad ab, aber ich würde mir mehr SMT16-Cloud-Instanzen wünschen, die ausdrücklich auf solche Workloads mit niedrigem Instruktionsdurchsatz zielen.
Bei solchen Barrel-Prozessor-Designs wirkt CMT8/SMT8 wie ein sinnvoller Sweet Spot.
Es klingt nach dem Vorschlag, dass man bei optischen Interconnects mit guter Effizienz praktisch distanzunabhängige Geschwindigkeit bekommen kann, wenn man die Die-Kosten und Geschwindigkeitsverluste für die Umwandlung elektrischer Signale in optische Signale amortisieren kann.
Ganz so ist es natürlich nicht, aber wenn man es auf Entfernungen zwischen Chip-Carriern in einem einzelnen Chassis beschränkt, gibt es wenig Interferenzen, und die Verdrahtung ist innerhalb des Biegeradius der Lichtleiter ebenfalls flexibel.
Vielleicht habe ich es auch falsch gelesen. Die optischen Komponenten könnten auch einem anderen Zweck wie Die-Stacking dienen, oder es könnte darum gehen, ein Gitter von Chips auf einem Super-Carrier zu bauen und sie über optische Interconnects zu verbinden.
Echte Die-Fotos und die Bestätigung, dass es bei TSMC in 7 nm gefertigt wurde – das dürfte für Intel ziemlich schmerzhaft sein.
Wenn man für so etwas die Fab eines Konkurrenten nutzen muss, ist das für einen Chiphersteller wohl ein ziemlicher Tiefpunkt.
Allerdings war der 10-nm-Node für Intel eine Katastrophe und hat das Unternehmen im Chipfertigungsgeschäft wohl um etwa 5 bis 10 Jahre zurückgeworfen.
Bei einem Forschungsprojekt kann man sich leicht vorstellen, dass TSMC bevorzugt wird.
Das erklärt, warum solche ungewöhnlichen Dinge zu TSMC gehen. Silicon Photonics selbst läuft zum Beispiel in Albuquerque, einem Standort, der ohnehin schon am Aussterben war.
Wenn man bei Google den Zeitraum auf 2001–2010 einschränkt, findet man entsprechende Nachrichten.
Es wird schon einen Grund geben, warum HN-Nutzer sich mit Halbleitern nicht besonders gut auskennen. Vermutlich, weil die Leserschaft hauptsächlich aus der Software-Ecke kommt. Auf dieser Site scheint das der Bereich mit dem höchsten Verhältnis von Selbstbewusstsein zu Qualität der Erklärungen zu sein.
AMD hat dasselbe getan, als es GlobalFoundries aufgab, und man kann sagen, dass das ein Hauptgrund dafür war, Intel zu überholen.
Am Ende nutzen ohnehin alle ASML-Lithografieanlagen, daher ist es eher zweitrangig, wer den Wafer in die Maschine legt.
Das sieht eher nach einer Proof-of-Concept-CPU aus als nach einem verkaufbaren Produkt.
Sie ist stark spezialisiert, und man muss offenbar erst noch herausfinden, welche Probleme und Workloads sie lösen soll.
Ich erwarte, dass Photonen künftig auch im General-Purpose-Computing Einzug halten werden – mindestens, um das wachsende Problem der überschüssigen Abwärme zu bewältigen. Besonders auffällig ist dabei der Prozesswechsel von 10 nm auf 7 nm.
Sun hat vor langer Zeit etwas Ähnliches gemacht, es bei späteren UltraSPARC-CPUs aber wieder aufgegeben.
Waren die Threads ausgehungert? Kam man zu dem Schluss, dass weniger, dafür schnellere Kerne besser sind? Details dazu sind schwer zu finden.
Es wäre schön, wenn bcantrill von HN etwas über die Interna erzählen könnte.
Für Performance musste man oft deutlich mehr Parameter abstimmen oder neu kompilieren.
Bei mir fiel das auch in eine Zeit, in der der Bedarf an SSL stark zunahm. SSL war auf x86 gut optimiert, auf Sparc aber nicht. Deshalb mussten wir zusätzliche Komplexität wie SSL-Offloading-Karten oder Reverse Proxies handhaben.
Letztlich war es außerhalb einiger Nischen zu schwierig, es gut zum Laufen zu bringen.
Vielleicht war es kein großer Faktor, aber auch aus Sicht der Systemadministration war es lästig. Ein großer Teil unserer Aufgaben war seriell und Single-Core-lastig. Mit anderen Worten: Genau der Gruppe, die normalerweise Vendor-Budgets freigibt, zeigte man damit die schlechteste Seite.
Das scheint perfekt für Graph-Reduktion und Dataflow-Programmierung zu sein.
Falls so etwas tatsächlich in Produktion geht, könnte man damit ziemlich coole Dinge bauen.
528 Threads bei 8 Kernen – wie geht diese Rechnung auf? Ich dachte erst an 512 und musste noch einmal lesen.
Wegen des Workloads scheint der Cache nicht gut genutzt zu werden, und es handelt sich nicht um x86, sondern um einen RISC-Befehlssatz.
Dabei steht 2 für langsame Threads wie bei heutigen CPUs, und 64 ist eher mit GPU-Threads vergleichbar.
Diese Architektur könnte der nächste Schritt der GPU-Integration sein. Hoffentlich schreiben sie effiziente Implementierungen der Standard-Mathebibliotheken. Das könnte schneller sein als separate CPU+GPU in einem Package.
Warum es 66 sind, wird nicht erklärt.
Jetzt ist es an der Zeit, endlich den ganzen Code event-driven, mit io_uring usw. neu zu schreiben.
Die von anderen erwähnte Tera MTA hatte bzw. hat dafür Hardware-Synchronisation im Speichersystem.
Es gab keine Interrupts, nur Threads, die darauf warteten, von jemandem geweckt zu werden.
Habe ich den Artikel richtig gelesen? Bedeutet das, dass 32 GB DRAM auf dem Chip sind, oder werden einfach Standard-DIMMs verwendet?
Interessant ist, dass sie Custom-DIMMs und einen Memory Controller nutzen, um Zugriffe in 8-Byte-Einheiten durchzuführen. Außerdem hat, wie auf dem Die-Foto zu sehen, jeder Kern seinen eigenen Memory Controller.
Wenn jeder Memory Controller 4 GB DRAM verwaltet, erklärt das 32 GB pro Chip.
Es gibt auch Material, das das genauer erklärt; Nvidia scheint es bei Grace Hopper ebenfalls so zu machen, und Apple macht bei den M-Series-Chips etwas Ähnliches.
Update: In diesem Fall scheint es einfach DDR5 zu sein, genauer gesagt „custom DDR5-4400 DRAM“.