Parallelisierung mit Vektor-Processing Was ist Scalable Vector Extension (SVE)?

Anbieter zum Thema

Vertiv GmbH

Schneider Electric GmbH

VON ZUR MÜHLEN'SCHE GmbH

Unter den Parallelisierungs-Strategien ist die schon 50 Jahre alte Vektor-Processing-Technik eine interessante Alternative. Besonders wenn sie so flexibel umgesetzt ist wie bei der Scalable Vector Extension (SVE).

Ob komplexe wissenschaftliche Simulationsrechnungen, maschinelles Lernen oder KI-Aufgaben aller Art: alle diese Anwendungen benötigen Hochleistungsrechner (High Performance Computing, HPC) mit leistungsfähigen Allzweck-Prozessoren einerseits und Spezialprozessoren als Beiboote andererseits; oder auch einen maßgeschneiderten Spezialprozessor „all-in-one“. Die Bewältigung der genannten Aufgabenstellungen läuft eigentlich immer auf eine Form von Parallelverarbeitung hinaus, sei es auf der Basis eines digitalen Signalprozessors, eines Grafikprozessors oder eines so genannten KI-Prozessors, in dem quasi künstliche Synapsen in Silizium gegossen sind.

Ein alter Bekannter: Vektorprocessing

Varianten solcher KI-Prozessoren gibt es mittlerweile fast wie Sand am Meer, was einerseits Anwendern eine große Auswahlmöglichkeit bietet, andererseits sie auch vor neue Herausforderungen stellt. Denn Parallelverarbeitung ist eine vertrackte Sache.

Nicht jede Aufgabe ist für Parallelisierung geeignet und viele können zwar „irgendwie“ parallelisiert werden, erzeugen aber im Falle der Parallelisierung hohen Entwicklungs- und Ressourcenaufwand. Nicht zu reden von Compilern, Programmbibliotheken und sonstiger Software, die erst einmal überhaupt nicht für Parallelisierung ausgelegt sind.

Angesichts dieser Herausforderungen kann für einige (viele?) Anwendungsfälle das Vektorprocessing eine interessante Alternative sein. Entsprechende Prozessoren haben einen Befehlssatz, der 1- oder mehr-dimensionale Datenfelder (Vektoren) statt eines Einzeldatums (Zahl, Zeichen) als Operanden hat.

Rechnen mit Vektoren ist Parallel-Computing der dritten Art

Was ist ein Vektorprozessor?

Vektor-Processing gibt es schon seit den 1970er-Jahren und hat besonders im Rahmen der Cray-Supercomputer lange das Hochleistungsrechnen dominiert. In den vergangenen Jahren brachten viele Prozessor-Hersteller Vektor-Processing-Architekturen auf den Markt. „Intel MMX“, „SSE“ und „AVX“-Befehlssätze sind dafür ebenso ein Beispiel wie die „3DNow!„-Extensions von AMD, die „VIS“ Extension von „Sparc“ oder die „AltiVec“-Technologie von IBM im „Power“-Rechner

Die Crux mit der Vektorlänge

Eine besondere ausgefeilte und vielfältig nutzbare technologische Implementierung der Vektor-Prozessor-Architektur ist die Scalable Vector Extension (SVE) der 64-Bit-ARM-Prozessoren. Innerhalb der „ARMv8-A“-Reihe haben die ARM-Entwickler eine Vektoreinheit eingebaut, bei der der Programmierer zwischen Vektorlängen von 128 bis zu 2048 Bit frei entscheiden kann. Diese Entscheidungsfreiheit verbirgt sich hinter dem Wort „Scalable“. Die Leistungsmerkmale von SVE sind so gestaltet, dass neuere, leistungsfähige Vektorisierungs-Compiler aus existierendem (!) Code automatisch feinkörnige parallele Strukturen hervorbringen.

SVE bietet die Möglichkeit, ein Programm erst einmal unabhängig von einer bestimmten Vektorlänge zu schreiben. Das heißt im Klartext: Wenn die Vektorlänge im Laufe des Entwicklungsprozesses geändert wird, muss das geänderte Programm nicht neu kompiliert werden. Das verschafft den Programm-Entwicklern eine bisher nicht gekannte Flexibilität bei der Programmierung. Darüber hinaus reduziert dieses Feature den Aufwand für die Inbetriebnahme von Programmen deutlich.

Warum größere Vektorlängen? Das ist eine durchaus berechtigte Frage, die nur auf den ersten Blick leicht beantwortet werden kann. Wenn beispielsweise Supercomputer mit Speichersystemen, die sehr breitbandig angesprochen werden können (high bandwidth memory systems), zum Einsatz kommen, dann scheinen sich größere Vektorlängen geradezu anzubieten. Auf den zweiten Blick und bei näherem Nachdenken wird aber klar, dass man größere Vektorlängen in ihrer positiven Wirkung auf die Gesamtleistung nicht überschätzen darf.

Tatsächlich ist die Menge an Code, der nicht parallelisiert werden kann, die Leistungsbremse für die Vektorisierungstechnik (auch als Gesetz von Amdahl bekannt). Um längere Vektorlängen ausnützen zu können, muss man also eine Aufgabe in erster Linie so in Code umsetzen, dass möglichst viel parallelisiert werden kann

SVE benötigt Software-Anpassungen

Rund drei Viertel des Adress-Raums sind bei der ARMv8-A-Reihe vor-allokiert, der Rest gehört der SVE-Technologie und ist somit offen für künftige parallele Erweiterungen. Die Software-Anpassungen (Compiler, Bibliotheken, Werkzeuge von Drittanbietern zum Beispiel) sind eine große (software-)technische Herausforderung.

Die Open-Source-Community spielte und spielt bei den nötigen Anpassungen eine wichtige Rolle. Die Vektorisierungstechnik „NEON“ beim „ARM 7 Advanced SIMD“, schon ein echtes gut 15 Jahre altes Vektor-Processing-Urgestein, wird durch SVE nicht ersetzt, sondern ergänzt.

(ID:46698519)