Bild 1: Ein Datenflussdiagramm auf Hardwareebene als grundlegendes Rechenwerk ist der Schlüssel zum Erfolg von Graph-Streaming-Processing.

Bild 1: Ein Datenflussdiagramm auf Hardwareebene als grundlegendes Rechenwerk ist der Schlüssel zum Erfolg von Graph-Streaming-Processing. (Bild: Thinci)

| von Val Cook

Herkömmliche KI-/ML-Architekturen basieren auf Grafikprozessoreinheiten (Graphics Processor Unit, GPU), die ursprünglich zur Bildsynthese (Rendering) von 3D-Bildern entwickelt wurden. Während GPUs Billiarden von Gleitkommaoperationen pro Sekunde (TFLOPS) bereitstellen, sind sie im Allgemeinen für die Ausführung einer einzelnen von gleichzeitig stattfindenden Aufgaben ausgelegt und die Berechnung erfolgt mit Datentransfer über den Speicher. Dies erfordert immense Datenraten und umfangreiche Datenstrukturen im Speicher, was weiterhin zu höherem Energieverbrauch und geringerer Gesamtrechenleistung führt.

Mehr Rechenleistung bei weniger Energiebedarf

Bild 1: Ein Datenflussdiagramm auf Hardwareebene als grundlegendes Rechenwerk ist der Schlüssel zum Erfolg von Graph-Streaming-Processing.

Bild 1: Ein Datenflussdiagramm auf Hardwareebene als grundlegendes Rechenwerk ist der Schlüssel zum Erfolg von Graph-Streaming-Processing. Thinci

Die GSP-Architektur (Graph-Streaming-Processing) von Thinci verwendet im Gegensatz dazu ein grafisches Datenflussdiagramm als Ausführungsmodell, bei dem verschiedene Tasks verschiedenen Knoten eines Graphen zugewiesen sind (Bild 1). Eine On-Chip-Hardware plant dynamisch die gleichzeitige Ausführung dieser Tasks und verfolgt ihre Datenabhängigkeiten in sehr feinstrukturierter Weise. So können die zwischen Tasks ausgetauschten Informationen auf dem Chip verbleiben, was zu einem schnelleren Datenzugriff bei geringerem Energiebedarf führt, als bei bestehenden Lösungen mit externem Speicherzugriff, wie etwa bei GPUs. Die dynamische feinstrukturierte Planung ermöglicht automatisch eine ausgewogenere Rechenlastverteilung für eine bessere Hardwareauslastung.

Die GSP-Architektur lässt sich leicht skalieren, um größere und komplexere KI-Arbeitslasten zu bewältigen, etwa durch eine höhere Prozessoranzahl auf einem einzelnen Chip, oder durch die Gruppierung mehrerer Chips, die alle Tasks eines grafischen Datenflussplans auf beliebige mit ihnen verbundene Prozessoren verteilen, und das ohne jegliche Modifikation des Programmcodes von Anwendungen. Dieser grundlegende architektonische Vorteil stellt für lange Zeit die Erfüllung zukünftiger Berechnungsanforderungen in der KI sicher. Das Gesamtergebnis sind niedrigere Gesamtbetriebskosten und Investitionen für Unternehmen, die in KI-Nutzungsmodelle, -Dienstleistungen und -Gerätschaften investieren.

Parallelisierung auf mehreren Ebenen

Um die Einzigartigkeit des Graph-Streaming-Processing zu verstehen, beginnen wir mit der Philosophie, die der Konstruktion zugrunde liegt. In erster Linie war die Umsetzung von mehreren Ebenen der Parallelität für den Aufbau der Architektur entscheidend – Task-Ebene, Thread-Ebene, Daten-Ebene und Anweisungs-Ebene. Die Architektur umfasst auch mehrere Techniken, um einen außergewöhnlich niedrigen Energiebedarf in Kombination mit hoher Rechenleistung, die KI-/ML-Anwendungen benötigen, zu erreichen. Mit dem ursprünglichen Fokus auf das Edge-Computing (dezentrale, ausgelagerte Datenverarbeitung) sind geringer Energiebedarf und ein hoher Durchsatz somit besondere Merkmale dieser Architektur. Das bedeutet gegenüber konkurrierender Lösungen einen großen Vorteil, den das Graph-Streaming-Processing für zukünftiges Marktwachstum nutzen kann.

Eckdaten

In klassischen KI-/ML-Architekturen eingesetzte Grafikprozessoren sind aufgrund ihrer sequenziellen Task-Planung weniger effizient. Die GSP-Architektur von Thinci verwendet im Gegensatz dazu ein grafisches Datenflussdiagramm als Ausführungsmodell in Hardware und erreicht durch Parallelisierung auf Task-, Thread, Daten- und Anweisungs-Ebene einen außergewöhnlich niedrigen Energiebedarf bei gleichzeitig hoher Rechenleistung. Eingesetzt in neuronalen Netzen schafft die Prozessor-Pipeline einen Auslastungsgrad von bis zu 95 %.

Einzigartig beim GSP ist es, die Parallelisierung auf Task-Ebene direkt auf der Hardware auszuführen. Die Task-Planung erfolgt in Form eines grafischen Task-Datenflussplans (Bild 2). Die Implementierung dieses Datenflussdiagramms auf Hardwareebene als grundlegendes Rechenwerk ist der Schlüssel zum Erfolg von Graph-Streaming-Processing. Thread-Level-Parallelisierung ist eine gängige Technik in GPUs. Verbesserungen im GSP stellen sicher, dass die Hardware-Task-Planung dieses auch klar adressieren kann. Das GSP bringt auch einige neue Ideen zur Parallelisierung auf Datenebene mit. Anstatt eines einfachen linearen Vektors kann man 2D-Vektoren sowie Anweisungen zur parallelen Reduktion ausführen. Zuletzt bietet die Parallelisierung in der GSP-Anweisungsebene neue Ebenen in der Hardware-Task-Planung, wie auch Komplexitäten und Vorteile, die sich aus dieser Planung ergeben.

Task-Planung in Hardware ist effizienter

Im Rahmen der Parallelisierung auf Task-Ebene ist ein Task-Graph eine Formalisierung von Tasks, die sowohl Entwicklern als auch dem Compiler eine klare Abgrenzung zwischen Eingängen und Ausgängen vorgibt. Das Task-Diagramm reduziert nun auch Nebeneffekte, die Systeme komplex machen können, was eine hocheffiziente Beschleunigung ermöglicht. Noch wichtiger ist, dass die GSP-Task-Parallelisierung in einer Weise erfolgt, die industrielle Standards unterstützt und einfach zu programmieren ist. Der Entwickler befindet sich nicht auf Assembler-Code-Ebene und er benötigt außer Standard OpenCL C++ keine weitere spezielle Expertise zur Programmierung.

Der nächste Schritt in der Evolution von KI-/ML-Prozessoren besteht darin, der Hardware mehr Wissen über die von ihr verrichteten Arbeit zu vermitteln. Ein Task-Graph besteht aus Knoten, Puffern zwischen den Knoten und klar definierten Ein- und Ausgängen an jedem Knoten. Knoten sind an den Kernel oder an Programme gebunden, die auf den Knoten arbeiten. Die Datenpuffer für diese Knoten können strukturiert oder unstrukturiert und dicht oder dünn verteilt sein. Im Kontext des GSP weiß die Hardware, was ein Task-Graph ist. Der Schreibzugriff auf einen einzelnen Memory Mapped Intput/Output (MMIO) erfolgt vom Host, um die Ausführung des gesamten Task-Graphen einzuleiten. Die Interaktion mit dem Host ist dabei minimal und die Hardware übernimmt die Verwaltung des Speichers und steuert die Lastverteilung in der gesamten Maschine.

Graphenstruktur und Speicherzuordnung aus dem Compiler

Bild 2: Konventionelle GPUs und DSPs planen Tasks der Reihe nach, wogegen GSP durch parallele Task-Planung in Hardware deutlich schneller ist.

Bild 2: Konventionelle GPUs und DSPs planen Tasks der Reihe nach (links), wogegen GSP durch parallele Task-Planung in Hardware deutlich schneller ist (rechts). Thinci

Machine-Learning-Frameworks sind die vorherrschende Programmiermethode für ML-Anwendungen. ML-Frameworks und Bibliotheken führen Task-Graphen sequenziell aus. Zum Beispiel planen die Scheduling-Algorithmen unter Tensor-Flow jeweils einen Knoten, indem sie verschiedene Bibliotheken aufrufen um Operationen auszuführen. Die Beschleunigungsmodelle planen linear einen Knoten nach dem anderen. Der Kommunikationstransfer erfolgt über den Speicher und das Bewegen von Daten zum Chip bedeutet jedes mal Aufwand.

Im Gegensatz dazu ist der Compiler von Thinci zweistufig optimierend. Er ist vollständig automatisch vektorisierend und bietet alles, was der Kernel benötigt. Darüber hinaus führt der Compiler eine enorme Menge an statischen Analysen auf dem Kernel durch. Diese Analyse erzeugt weitere Metadaten, welche die Speicherzugriffsmethoden und so weiter beschreiben, die der Kernel ausführt. Diese Information gelangt dann weiter an einen globalen optimierenden Compiler, der die tatsächliche Graphenstruktur und die erforderlichen Pufferressourcenzuordnungen für die Zwischenpuffer bestimmt. Die generierten spezifischen Strukturen zu Ablaufsteuerung stehen dann der Hardware zur Verfügung, die wiederum die gesamte Task-Planung durchführt. Somit können Kernels mit unterschiedlichen Ausführungszeiten laufen, während sich gleichzeitig die Menge an in Prozess befindlichen Tasks auf dem Chip minimiert.

Das Ergebnis ist ein Datenstrom, der sich ununterbrochen durch eine Anordnung von Verarbeitungsknoten bewegt. Jeder Knoten im Datenstrom akzeptiert Eingaben von seinem Vorgängern und sendet sein Ergebnis an die nachfolgenden Knoten weiter.

Parallelisierung auf Thread-Ebene

Die Thread-Level-Parallelisierung erleichtert diese Datenstromberechnung. Eine der wichtigsten Innovationen von Thinci ist ein fortschrittlicher Thread-Scheduler, von dem industrielle Anwendungen künftig profitieren. Er plant und verteilt die Arbeit über eine Gruppe von Prozessoren – datenabhängig und mit hohem Datendurchsatz. Um dies zu erreichen, muss der Scheduler die Datenbeziehungen verstehen, anstatt die parallele Task-Ebenen-Planung an eine Software zu übertragen.

In vielen SIMD-Maschinen (Single Instruction Multiple Data) gibt es Verteilungs- und Zusammenführungs-Einheiten (Scatter-/Gather-Units) für den Datenpfad. Es besteht ein großes Interesse, ein entsprechendes Steuerungskonzept zu haben, bei dem die Threads zwecks Ausführung verteilt und danach in bestimmter Weise wieder zusammengeführt werden. Das Graph-Streaming-Processing verwendet ebenfalls diesen Scatter-Gather-Mechanismus.

Daten direkt in der Registerdatei verarbeiten

Bild 3: Das Arbeiten mit blockbasierten Datenblöcke in den Registerdateien ist deutlich schneller als der herkömmliche Datentransfer über einen externen Speicher.

Bild 3: Das Arbeiten mit blockbasierten Datenblöcke in den Registerdateien ist deutlich schneller als der herkömmliche Datentransfer über einen externen Speicher. Thinci

Persistente Datenstrukturen in der gesamten Speicherhierarchie sind blockbasiert und werden von 1D- und 2D-Strukturen unterstützt. Beispielsweise kann GSP die Registerdateien in der Maschine vertikal und sehr effektiv lesen. Jedes Kommando greift auf rechteckige Datenblöcke in den Registerdateien zu (Bild 3). Auf herkömmlichen Prozessorarchitekturen bewirken viele Befehle wie Verschieben von Daten, Anpassungen und Formatkonvertierungen bei der eigentlichen Berechnungsaufgabe in einer Pipelinestruktur kein Vorwärtskommen. Diese Operationen erfolgen jetzt hingegen in der Registerdatei, wo die Ergebnisse auch gespeichert werden. Das Arbeiten mit Daten, ohne sie kontinuierlich bewegen und verschieben zu müssen, ist ein leistungsstarkes Konzept.

Eine weitere im GSP enthaltene Besonderheit besteht in Anweisungen zur Reduzierung – sie übernehmen größere Quelldaten und reduzieren sie in eine kleinere Zielgröße. Das GSP projiziert das Konzept in den 2D-Raum, in eine hocheffiziente, vereinheitlichte, arithmetische Pipeline. Die GSP-Pipeline unterstützt Datentypen wie 8-, 16-, 32-Bit-Integer- sowie 32- und 64-Bit-Fließkommawerte. GSP hat seine Stärke in der Reduzierung von dot-products über min/max, logische ODER- und AND-Operationen und weitere.

Rechenleistung mit hohem Nutzungsgrad planen

Die GSP-Architektur verwendet keinen Place-and-Step-Ansatz zur Auslegung der Prozessoren im Chip. Vielmehr wurde Wert auf ausgewogene Arbeitslastanforderungen gelegt, dem Bedarf an Gleitkomma- und Integer-Pfaden im Verhältnis zu Load-Store-Pfaden in Relation zu speziellen arithmetischen Anweisungen, wie etwa Histogrammfunktionen und Mediumfilter. Diese speziellen Anweisungen benötigen längst nicht den gleichen Durchsatz, wie eine herkömmliche arithmetische Pipeline. Sorgfältig platziert und über eine Gruppe von Prozessoren verteilt, ergeben sich für diese Pipelines Schlüsselvorteile.

Ein vollständig hardware-gesteuerter Befehlswähler kann hunderte von Threads untersuchen, die zur Bearbeitung anstehenden Kommandos über Dutzende von Pipelines verteilen und die Rechenleistung mit einem hohen Nutzungsgrad planen. Das Mapping für all diese Pipelines ist eine groß angelegte Suche, die effektiv und effizient in Hardware durchführbar ist. Im Vergleich dazu erreicht eine VLIW-Prozessorarchitektur (very long instruction word) enorme Energieeinsparungen, indem diese Arbeit zum Zeitpunkt der Kompilierung erfolgt. In einer Umgebung mit vielen Threads ist der VLIW-Ansatz jedoch nicht in der Lage, über die vielen Ausführungs-Threads hinweg zu planen.

Bild 4: Die GSP-Architektur ist zunächst über die ML-Frameworks Tensoflow, Caffe und Torch programmierbar.

Bild 4: Die GSP-Architektur ist zunächst über die ML-Frameworks Tensoflow, Caffe und Torch programmierbar. Thinci

Das GSP-Programmiermodell

Während der Entwicklung des GSP fiel die Entscheidung für eine vollständige Programmierbarkeit. Beim Entwurf heutiger KI-/ML-Architekturen stellt sich dabei die Frage, ob man Pipelines mit Fixed-Function-Faltung oder eine Allzweck-Hardware aufbauen sollte. Die Lösung für das GSP ist vollständig programmierbar. Das ermöglicht den Aufbau einer vollständig programmierbaren Architektur – ohne dedizierte Faltungs-Hardware. Mit diesem Ansatz ist man für den Fortschritt des gegenwärtigen KI-Technologiestandes bestens vorbereitet – auch in Hinblick auf einen stark anwachsenden Erkenntnisgewinn, und in Gegenwart vieler sich ändernder Netzwerktopologien und Kundenanforderungen.

Um die GSP-Architektur zu programmieren, wurden drei ML-Frameworks zur Veröffentlichung bei der Produktankündigung ausgewählt. Das Programmiergerüst Tensorflow plant gewöhnlich einen Knoten nach dem anderen. Der darunter liegende Scheduler wurde überarbeitet, um die Graph-Streaming-Fähigkeit von GSP zu nutzen. Darüber hinaus unterstützt ein erweitertes Bereitstellungstool die Einbindung der ML-Frameworks Caffe, Caffe 2 und Pytorch (Bild 4).

OpenVX für eine benutzerdefinierte Kernel-Programmierung

Zusätzlich zu den allgemeinen ML-Frameworks verwendet die GSP-Software-Programmierumgebung OpenVX und eröffnet dem Programmiermodell damit einige Vorteile. Es verfügt über einen robusten, Industriestandards entsprechenden Mechanismus zur Beschreibung von Task-Graphen über die Elemente Knoten, Puffer und Graphen. Ein Problem von OpenVX besteht darin, dass die benutzerdefinierte Kernel-Unterstützung einfach ist und allgemein die Arbeit auf der Host-CPU belässt.

Um dieses Manko zu beheben, erweitert die GSP-Programmierumgebung OpenVX und bietet über OpenCL C++ eine Unterstützung für benutzerdefinierte Kernels. Somit kann der Entwickler per C ++ beliebige Nicht-Standard-Operationen programmieren, während die gesamte Hardwarebeschleunigung des GSP beibehalten bleibt. OpenVX wurde auch erweitert, um alle oben genannten Datentypen sowie einige der integrierten Funktionen des GSP zu unterstützen.

Effiziente Prozessor-Pipeline zum Einsatz in neuronalen Netzen

Beim Einsatz in konvolutionellen neuronalen Netzen wie VGG-16 mit 8-Bit-Auflösung, zur Bildklassifizierung, Gesichtserkennung, semantischen Segmentierung und Objekterkennung, erreicht GSP eine Effizienz von 95 % für die Prozessor-Pipeline. Dies resultiert aus der Fähigkeit, die Pipeline vollständig zu befüllen, wobei ein hocheffizienter Planungs- und Datenlieferungs-Mechanismus die Multiplikatoren kontinuierlich versorgt.

Der erste GSP-Chip wird im 28-nm-Prozess (TSMC HPC+) hergestellt. Das in sich geschlossene System ist in einen Chip integriert (SoC) und besitzt einen On-Chip-Host-Prozessor sowie umfangreiche Peripherie. Der SoC lässt sich auch auf einem PCIe-Beschleuniger-Board einsetzen.

Val Cook

Chef-Software-Architekt bei Thinci

(jwa)

Kostenlose Registrierung

Der Eintrag "freemium_overlay_form_all" existiert leider nicht.

*) Pflichtfeld

Sie sind bereits registriert?