Ich will einen guten Parallelrechner

• GPUs sind 10- bis 100-mal leistungsfähiger als CPUs, haben aber Schwierigkeiten mit dynamischen Workloads und es gibt zu wenige Werkzeuge für paralleles Programmieren, sodass ihre Leistung bei allgemeinen Aufgaben nicht ausreichend genutzt wird
• In der Vergangenheit gab es Parallelrechner-Designs wie Connection Machine, Cell und Larrabee, die aber unter anderem an der Komplexität ihrer Programmiermodelle scheiterten
• Bei modernen GPUs ist die Performance-Optimierung wegen Problemen bei der Speicherverwaltung und komplexer Ausführungsmodelle schwierig; benötigt wird eine effiziente Struktur zur Datenübergabe auf Queue-Basis
• Neue Architekturen wie AI-Beschleuniger und Verbünde paralleler Kerne könnten die Grenzen der GPU überwinden
• Die Entwicklung von Parallelrechnern ist noch nicht abgeschlossen; nötig sind einfachere und effizientere Ausführungsmodelle sowie bessere Programmierwerkzeuge

Die starke Leistung und die Grenzen der GPU

• GPUs sind etwa 10- bis 100-mal leistungsfähiger als CPUs (je nach Art der Aufgabe)
• Bei Echtzeit-Grafik-Rendering und Machine Learning wird diese Leistung gut genutzt
• Dennoch wird die GPU-Leistung bei allgemeinen Aufgaben nicht ausreichend ausgeschöpft

Ursachen für die Grenzen der GPU

• Schwaches Ausführungsmodell
  • GPUs sind stark bei vorhersehbaren Massendaten (z. B. dichter Matrixmultiplikation), verlieren aber bei dynamischen Workloads an Leistung
• Mangel an Sprachen und Werkzeugen
  • Das Programmieren von Parallelrechnern ist an sich schon sehr schwierig

Zunehmende Komplexität

• Moderne GPUs werden rasant komplexer
• Neue Funktionen wie Mesh Shaders und Work Graphs wurden eingeführt, aber einige grundlegende Aufgaben werden weiterhin nicht unterstützt

Komplexe Probleme bei der GPU-Speichereffizienz

• Der Autor entwickelt derzeit einen fortschrittlichen 2D-Vektorgrafik-Renderer namens Vello
  • Die CPU lädt eine Szenenbeschreibung (im SVG-Format) hoch → ein Compute Shader verarbeitet sie und erzeugt anschließend das Bild
• Problem: schwierige Speicherverwaltung
  • Die Größe der Buffer für die Speicherung von Zwischenergebnissen ist schwer vorherzusagen
  • Wenn ein Buffer überläuft, führt ein Lesevorgang von der GPU zur CPU zu Leistungseinbußen

Lösungsvorschlag

• Verbesserung, sodass Ergebnisse innerhalb der GPU über Queues weitergereicht werden
  • Ein solches Modell wurde bereits 2009 im GRAMPS-Papier vorgeschlagen
  • Auch im Projekt Brook wurde ein ähnlicher Ansatz versucht

Frühere Parallelrechner-Designs

• Connection Machine (1985)

  • Ein Parallelrechner mit 64k Prozessoren, die über ein Hypercube-Netzwerk verbunden waren
  • Jeder Prozessor war leistungsschwach, aber groß angelegte Parallelverarbeitung war möglich
  • Großer Beitrag zur Forschung an parallelen Algorithmen

• Cell (2006, PS3)

  • Ein in der PS3 verbauter Parallelrechner (etwa 87,4 Millionen Einheiten ausgeliefert)
  • 8 parallele Kerne konnten unabhängig voneinander Berechnungen ausführen
  • Die Komplexität des Programmiermodells war der Grund für das Scheitern

• Larrabee (2008)

  • Wurde als x86-basierter Parallelrechner entwickelt
  • Gründe für das Scheitern: Stromverbrauch und fehlende Software-Unterstützung
  • Führte später zu Xeon Phi und den AVX-512-Befehlen

Sich wandelnde Workloads

• Auch in Spielen nimmt der Anteil von Compute-Workloads zu
  • Bei Starfield entfallen rund 50 % der gesamten Laufzeit auf Berechnungen
  • Der Nanite-Renderer verarbeitet sogar die Rasterisierung kleiner Dreiecke als Berechnung

Künftige Entwicklungsrichtungen

• 1. Ausbau von Kernverbünden (Wiederkehr von Cell)

  • Moderne High-End-CPUs enthalten mehr als 100 Milliarden Transistoren
  • Es wäre möglich, Chips mit Hunderten bis Tausenden einfacher stromsparender RISC-Kerne zu bauen
  • AI-Beschleuniger setzen bereits auf eine ähnliche Architektur

• 2. Vulkan-Befehle auf der GPU ausführen

  • Unterstützung dafür, Vulkan-Befehle direkt auf der GPU auszuführen
  • Derzeit nur eingeschränkt in einigen Vulkan-Erweiterungen umgesetzt

• 3. Work Graphs

  • Ein Programm besteht aus Knoten (Kernels) und Kanten (Queues)
  • Es läuft parallel, hat aber folgende Einschränkungen
    • Join-Operationen sind schwierig
    • Die Reihenfolge der Elemente ist nicht garantiert
    • Elemente variabler Größe werden nicht unterstützt

• 4. Weiterentwicklung zur Verschmelzung mit der CPU

  • High-Performance-CPU-Designs könnten sich in Richtung Parallelverarbeitung optimieren
  • Leistung bei paralleler Berechnung und SIMD (Single Instruction, Multiple Data) wird bereits verbessert

• 5. Die Hardware könnte bereits bereit sein

  • Einige GPUs enthalten Befehlsprozessoren, die benutzerdefinierten Code ausführen können
  • Wenn diese Befehlsprozessoren vollständig geöffnet würden, wäre weiteres Performance-Potenzial möglich

Das Komplexitätsproblem

• GPU-Architekturen sind übermäßig komplex
  • Parallelrechner + Spezialhardware + Befehlsverarbeitungsstruktur sind miteinander vermischt
  • Kompatibilitätsprobleme mit verschiedenen APIs und Treibern
• CPUs dagegen verbessern ihre Leistung weiterhin auf Basis einfacher Befehlssätze

Fazit

• Die Entwicklung von Parallelrechnern ist noch nicht abgeschlossen
• Damit GPUs nicht nur für Grafik- und AI-Aufgaben, sondern auch für allgemeine Aufgaben optimiert werden können, braucht es Folgendes
  • ein einfaches Ausführungsmodell
  • leichte Programmierbarkeit
  • niedrigen Stromverbrauch
• Bei anspruchsvollen 2D-Renderern wie Vello könnte die Leistung von Parallelrechnern dann vollständig genutzt werden
• Es braucht eine neue Parallelrechner-Architektur, um die Leistungsgrenzen der GPU zu überwinden

[GN⁺]

Hacker-News-Kommentare

• „Ich glaube, dass zwei Hauptfaktoren das verhindern“

  • Richtlinien dafür, Meinungen wissenschaftlich zu verpacken
  • Die Arbeit mit dem Cell-Prozessor erforderte viel Mikromanagement
  • Moderne Systeme werden mit Blick auf Speicherschutz, Isolation und Stabilität entworfen
  • Wenn man Leute auf einem Amiga Code schreiben ließe, würde das zu neuer Wertschätzung führen

• Das Programmiermodell ist im Jahr 2025 ineffizient

  • Shader-Quellcode/Bytecode muss zur Laufzeit kompiliert werden
  • Die Manipulation von Datenstrukturen zwischen CPU und GPU auf NUMA/diskreten Systemen ist schwierig
  • Datensatzugriffe zwischen CPU und GPU sowie zwischen GPU-Aufgaben müssen synchronisiert werden
  • Wegen nicht standardisierter Hardware müssen verwirrende APIs behandelt werden
  • Es müssen Kombinationen aus verschiedenen Konfigurationen verarbeitet werden

• Erfahrung aus der Arbeit bei einem Unternehmen, das „hunderte kleine CPUs auf einen einzelnen Chip gepackt“ hat

  • Das Programmiermodell ist so seltsam, dass es scheitern wird
  • Die nächste Generation wird keine neue Architektur sein, sondern GPUs mit zusätzlichen Funktionen

• GPUs sind 10- bis 100-mal leistungsfähiger als CPUs

  • Viele Aufgaben benötigen keine zusätzliche Leistung
  • GUIs reagieren seit über 20 Jahren auf Benutzereingaben
  • GPU-Programmierung sollte vereinfacht werden

• Meinung zum Bau eines M4-Mac-mini-Supercomputers

  • Reverse Engineering des Befehlssatzes der Apple M3 Ultra GPU und Neural Engine
  • Kann mehr als 50 Billionen Operationen pro Sekunde ausführen

• Probleme paralleler Computer

  • Viele Menschen müssen Geräte zu Entwicklungszwecken übernehmen
  • Code von der CPU auf die GPU zu portieren ist eine große Aufgabe
  • AMD und andere Unternehmen untersuchen die Idee, GPUs näher an die CPU zu rücken

• Es ist nicht klar, warum ein 2D-Renderer eine GPU braucht

  • Ein 3D-Renderer braucht Hilfe
  • Vulkan liegt unterhalb der Ebene des Renderers
  • Es gibt Reibungspunkte beim Renderer-Design in Rust 3D

• Es wird viel Larabee erwähnt, aber nicht Xeon Phi

  • CPU-Designs teilen sich in Richtungen auf, die Single-Core-Leistung und Energieeffizienz optimieren
  • Wenn es mehr E-Cores gibt, könnten Algorithmen gewinnen, die Parallelität ausnutzen

• Die Opfer, die den hohen Durchsatz von GPUs ermöglichen

  • Es gibt das Unified-Memory-System von Apple Silicon
  • GPU-Programmier-APIs behandeln den Speicher, als wäre er nicht vereinheitlicht