Autor: Dr. Andreas Ehmanns, MBDA Deutschland GmbH<\/p>\n
Vektoreinheiten sind seit vielen Jahren in den g\u00e4ngigen Prozessorfamilien Standard und dennoch werden sie – auch im embedded Bereich – h\u00e4ufig von den Softwareentwicklern nicht verwendet. Gerade bei ARM-Prozessoren ist die Entwicklung in diesem Bereich in den letzten Jahren deutlich voran geschritten und er\u00f6ffnet dem (embedded) Entwickler neue Leistungsbereiche. Von diesen sehr leistungsf\u00e4higen Einheiten Gebrauch zu machen und zu entscheiden, wann deren Nutzen brauchbare Vorteile bringt, erscheint h\u00e4ufig wesentlich schwieriger, als es wirklich ist.<\/strong><\/p>\n Beim Namen Vektoreinheit denken Software-Entwickler h\u00e4ufig, dass dies irgendetwas mit Super-Computing zu tun h\u00e4tte, und sind sich gar nicht bewusst, das aber auch nahezu jeder PC, die meisten Tablets und Smartphones und auch viele embedded Ger\u00e4te SIMD-Einheiten verbaut haben. SIMD (Single Instruction, Multiple Data) bezeichnet die Ausf\u00fchrung einer Instruktion auf mehreren Datenelementen. Je nach Prozessor-Familie werden unterschiedliche Namen f\u00fcr die verbauten SIMD-Einheiten verwendet. Bekannte Vertreter dieser Gruppe sind:<\/p>\n Obwohl es die ersten Versionen dieser Einheiten schon Ende der 90er Jahre gab, fanden sie nur z\u00f6gerlich Unterst\u00fctzung durch Software. Da die SIMD-Einheiten durch „normal“ geschrieben Programme nicht genutzt werden, m\u00fcssen sie explizit durch die Software programmiert werden. Erst die Einf\u00fchrung der „Autovektorisierung“, bei der der Compiler versucht, parallel ausf\u00fchrbare Rechenaufgaben zu erkennen und die Vektoreinheit mit zu benutzen, verbesserte die Situation, allerdings erreichen auch aktuelle Compiler (Stand Herbst 2018) noch nicht die Performance, die mit einer direkten Programmierung der SIMD-Einheit m\u00f6glich ist. Im Bereich Grafik und Multimedia erkannte man zuerst die M\u00f6glichkeiten der Leistungssteigerung durch die SIMD-Einheit, da hier h\u00e4ufig gleiche Operationen auf mehrfachen Daten (z.B. Pixeln) auszuf\u00fchren sind. Dies mag auch ein Grund daf\u00fcr sein, warum einige Software-Entwickler die SIMD-Einheiten auch heute – rund 20 Jahre sp\u00e4ter \u2013 immer noch nur mit Grafik und Multimedia in Verbindung bringen. Abgesehen von spezielle Datentypen (wie z.B. „Pixel“ bei Altivec) sind diese Einheiten jedoch nicht auf einen bestimmten Einsatzzweck beschr\u00e4nkt, sondern lassen sich f\u00fcr allerlei Rechnungen hernehmen, sofern die Rechenaufgabe parallelisierbar ist.<\/p>\n Auch wenn die Nutzung der SIMD-Einheiten heute wesentlich mehr verbreitet ist, so h\u00e4lt sich bei einigen Software-Entwicklern immer noch hartn\u00e4ckig das Ger\u00fccht, dass es sehr kompliziert sei, die Vektoreinheiten zu programmieren und dass man ein Hardware- und\/oder Assembler-Guru sein m\u00fcsse. Compiler, wie z.B. der gcc, bieten sogenannte Builtins, d.h. die Benutzung der Befehle zur Programmierung der Vektoreinheit k\u00f6nnen ganz einfach durch Parameter eingeschaltet werden, z.B. durch\u00a0-maltivec -mabi=altivec<\/span>\u00a0beim PowerPC, oder durch\u00a0-mavx2<\/span>\u00a0f\u00fcr x86 AVX2. Die dann vorhandenen sogenannten Intrinsics sind eine Art C-API und mappen in den meisten F\u00e4llen 1-1 auf die entsprechenden Assembler-Befehle. Umfangreiche Dokumentationen zu den einzelnen Funktionen, den Parametern und Varianten sind im Internet zu finden.<\/p>\n Bevor es an die Nutzung der SIMD-Einheit geht, stellt sich zun\u00e4chst die Frage, ob der zu optimierende Code parallelisierbar ist, oder ob einzelne Rechenschritte voneinander abh\u00e4ngen. Klassische Beispiele f\u00fcr gut parallelisierbare Rechenaufgaben sind Schleifen, bei denen die Berechnung der einzelnen Durchl\u00e4ufe nicht von den Ergebnissen der vorherigen abh\u00e4ngen. Also z.B. Vektoraddition, -Multiplikation, das Rechnen mit Matrizen und vieles mehr.<\/p>\n Weiterhin muss vorher gekl\u00e4rt werden, ob die Hardware eine SIMD-Unterst\u00fctzung hat und in welchem Umfang. Gerade bei ARM gibt es auch durchaus den Fall, dass die SIMD-Einheit komplett fehlt. Und umgekehrt bei x86 ist die F\u00fclle der Erweiterungen, die Intel regelm\u00e4\u00dfig eingef\u00fchrt hat, sehr gro\u00df und auf den ersten Blick un\u00fcbersichtlich. Angefangen von MMX \u00fcber SSE, SSE2, \u2026 AVX, AVX-256, AVX-512, \u2026<\/p>\n Ja nach Erweiterung sind dann bestimmte Befehle verf\u00fcgbar oder nicht. Genauere Informationen dazu sind z.B. in den Referenzdokumenten im Internet zu finden.<\/p>\n Ist die Software-Aufgabe parallelisierbar und ist die Unterst\u00fctzung der Hardware vorhanden, so steht der Nutzung der SIMD-Einheit nichts mehr im Weg. Aktuelle Compiler unterst\u00fctzen problemlos die g\u00e4ngigen SIMD-Einheiten und ihre Varianten.<\/p>\n Ein grunds\u00e4tzliches Thema bei der Programmierung von SIMD-Einheiten ist das Format der Daten. Die meisten aktuellen Einheiten haben eine Breite von 128 Bit (Ausnahmen: AVX-256: 256 Bit, AVX-512: 512 Bit), d.h. es passen z.B. vier 32-Bit Float oder vier 32-Bit breite Integer hinein. Daf\u00fcr gibt es eigene Datenformate, was wiederum bedeutet, dass Daten, die in einem nicht-Vektorformat vorliegen, erst in diese kopiert werden m\u00fcssen und nach der Berechnung eventuell auch wieder zur\u00fcckgewandelt werden. Dazu gibt es spezielle Funktionen, die diese Aufgabe elegant \u00fcbernehmen.<\/p>\n Beispiel: Ein 4-fach Vektor f\u00fcr 32-Bit Float hei\u00dft bei NEON:\u00a0float32x4_t<\/span><\/p>\n Vorsicht: Es gibt viele Beispiele im Internet, bei denen ein union verwendet wird, um von der Vektoreinheit aus auf die Daten zuzugreifen und sich den Kopiervorgang zu sparen. Dies setzt allerdings voraus, dass die Originaldaten im Speicher 16 Byte aligned sind, also genau die Breite der Vektoreinheit. Das ist in der Regel zwar der Fall, aber durch den Compiler nicht immer garantiert. Ist dies nicht der Fall, so gibt es keine Fehlermeldung oder Exception, sondern die unteren vier Bits der Adresse\u00a0 (bei Altivec) werden einfach ignoriert und die verwendeten Daten sind korrupt. Wer auf Nummer sicher gehen will, sollte die vorhanden Funktionen zum Konvertieren verwenden.<\/p>\n Sind die Daten im richtigen Format, kann es mit der Programmierung losgehen. Hier empfiehlt es sich, die Referenz-Handb\u00fccher ein wenig zu studieren, um zu sehen, welche Funktionen \u00fcberhaupt angeboten werden. Das sind zum einen mathematische Funktionen (im Wesentlichen die Grundrechenarten), aber auch Kopier-Funktionen, Bit-Manipulations-Funktionen und einige mehr. Wer mehr als die Grundrechenarten braucht (z.B einen Sinus oder die Exponential-Funktion), wird jedoch schnell an die Grenzen sto\u00dfen. Allerdings gibt es im Internet sehr viele Bibliotheken, die genau diese fehlenden Funktionen anbieten. Selten wird es vorkommen, dass eine Funktion selbst implementiert werden muss. Dann empfiehlt es sich, auf die mathlib zur\u00fcckzugreifen und die ben\u00f6tigte Funktion in der gew\u00fcnschten SIMD-Syntax nachzubilden.<\/p>\n Ist eine bereits klassisch implementierte Funktion (oder ein Teil davon) auf die Verwendung der SIMD-Einheit umgestellt, so sollte als erstes \u00fcberpr\u00fcft werden, ob die Funktion korrekt funktioniert. Dazu empfiehlt es sich, Referenzeingangs- und \u2013ausgangsdaten zu erzeugen und die Korrektheit der Implementierung damit zu \u00fcberpr\u00fcfen. Dabei ist darauf zu achten, dass s\u00e4mtliche Verzweigungen im Programm durchlaufen werden, um nicht Fehler in ungetesteten Zweigen zu \u00fcbersehen.<\/p>\n Funktioniert das Programm korrekt, so k\u00f6nnen die Fr\u00fcchte der Arbeit geerntet werden. H\u00e4ufig ist die Erwartung, dass der optimierte Teil des Programmes um einen Faktor vier schneller wird, wenn man z.B. mit Int32 arbeitet, da mit der SIMD-Einheit vier Berechnungen gleichzeitig ausgef\u00fchrt werden k\u00f6nnen. Diese Annahme ber\u00fccksichtigt aber nicht, dass die SIMD-Einheit je nach Architektur und Design eine komplett eigene Anbindung an die Peripherie und den Speicher hat. Nicht selten sind Geschwindigkeitssteigerungen von deutlich mehr als einem Faktor vier m\u00f6glich. Allerdings kann auch der umgekehrte Fall eintreten. Insbesondere dann, wenn wenig gerechnet werden muss, wenn gro\u00dfe Datenmengen zwischen SIMD- und nicht-SIMD Datentypen hin- und herkopiert werden m\u00fcssen, oder die Hardware (z.B. die Speicheranbindung) den Engpass darstellt.<\/p>\n Eine zuverl\u00e4ssige Aussage, welcher Performance-Gewinn bei der Umstellung auf die SIMD-Einheit zu erwarten ist, kann in aller Regel nicht getroffen werden, da diese von vielen Faktoren abh\u00e4ngt. Prinzipiell empfiehl es sich zun\u00e4chst einmal anzuschauen, an welchen Stellen im (nicht-SIMD) Code die meiste Zeit verbraucht wird (Profiling). Diese Codestellen oder Funktionen empfehlen sich dann daf\u00fcr, umgeschrieben zu werden. Erst so bekommt der Entwickler in Kombination mit dem Compiler und der Ziel-Hardware eine verl\u00e4ssliche Aussage \u00fcber die Performance. Da sie stark von den verwendeten Instruktionen abh\u00e4ngt, l\u00e4sst sie sich nur bedingt auf andere Codeteile \u00fcbertragen.<\/p>\n Trotz der vielen „aber“ wird der Software-Entwickler am Ende des Tages entlohnt, wenn er sieht, welcher Performance-Gewinn mit den SIMD-Einheiten m\u00f6glich ist. Verschiedene Algorithmen haben gezeigt, dass unter optimalen Voraussetzungen der Parallelisierbarkeit Geschwindigkeitssteigerung von Faktor 10-15 m\u00f6glich sind.<\/p>\n Eine recht einfache M\u00f6glichkeit, die Leistung der SIMD-Einheit zumindest teilweise nutzen zu k\u00f6nnen, stellt die Autovektorisierung dar. Die meisten g\u00e4ngigen Compiler unterst\u00fctzen diese und gerade in den letzten Jahren, sind die Compiler in diesem Bereich erheblich besser geworden. Bei der Autovektorisierung versucht der Compiler selbst\u00e4ndig, geeignete Codeteile in SIMD-Form zu bringen und damit die Vektoreinheit zu nutzen, ohne dass der Programmierer explizit entsprechende Intrinsics bei der Erstellung seines Programmes verwenden muss. Wie viel Performance-Gewinn dadurch erzielbar ist, h\u00e4ngt zum einen davon ab, wie das Programm aufgebaut ist und welche Rechenoperationen verwendet werden und welcher Compiler in welcher Version verwendet wird. Existiert bereits ein Programm, so lohnt es sich auf jeden Fall, die Autovektorisierung auszutesten. Allerdings sollte auch hier sicherheitshalber \u00fcberpr\u00fcft werden, dass das Programm mit dieser Option die richtigen Ergebnisse liefert.<\/p>\n Beim gcc l\u00e4sst sich die Autovektorisierung mit dem Switch\u00a0-ftree-vectorize<\/span>\u00a0einschalten. Der gcc schaltet diese Option erst bei \u2013O3 automatisch ein, allerdings gibt es auch Compiler und\/oder Wrapper, die diese Option schon bei -O2 aktivieren.<\/p>\n Um ein Bild zu bekommen, was der Compiler bei der Autovektorierung macht, hilft die\u00a0-ftree-vectorizer-verbose=N<\/span>\u00a0Option.<\/p>\n Ist hingegen die Autovektorisierung nicht erw\u00fcnscht oder soll sie zur Ausf\u00fchrung von Vergleichsmessungen explizit ausgeschaltet werden, kann dies mit Hilfe der Option\u00a0\u2013fno-tree-vectorize<\/span>\u00a0geschehen.<\/p>\n Auch wenn die Compiler in den letzten Jahren immer besser geworden sind, so ist mit einer direkten Programmierung der SIMD-Einheit in aller Regel deutlich mehr an Performance zu gewinnen als mit der Autovektorisierung. Wie gro\u00df der Gewinn sein wird, ist auch hier sehr schwer absch\u00e4tzbar und nur durch eine reale Messung bestimmbar.<\/p>\n Ein Nachteil der SIMD-Einheiten soll hier nicht verschwiegen werden. Dadurch dass die Intrinsics spezifisch f\u00fcr eine Prozessorfamilie sind, leidet die Portierbarkeit des Codes. Die Prozessorhersteller achten zwar darauf, dass neuere Versionen einer Vektoreinheit auch alle alten Befehle unterst\u00fctzen, bei Wechsel der Prozessorfamilie jedoch ist eine Portierung des SIMD-Codes erforderlich. Generell empfiehlt es sich, die Codeteile, die SIMD-Befehle benutzen, in einem Wrapper oder \u00e4hnlichem Konstrukt zu kapseln, soweit dies das Design der Applikation(en) erm\u00f6glicht.<\/p>\n Ist eine Performancesteigerung eines Programmes gew\u00fcnscht oder erforderlich, so lohnt es sich in vielen F\u00e4llen, die Vektoreinheit der Hardware (soweit vorhanden) zu nutzen. Autovektorisierung durch den Compiler kann in einfacheren F\u00e4llen schon eine Steigerung der Rechenleistung bringen, eine direkte Programmierung der SIMD-Einheit bietet jedoch bei parallelisierbarem Code meist einen wesentlich h\u00f6heren Gewinn, der unter optimalen Bedingungen sogar Faktoren betragen kann. Gerade im embedded Bereich, wo die Rechenleistung h\u00e4ufig deutlich limitierter ist, kann damit aus der vorhandenen Hardware entscheidend mehr Leistung herausgeholt werden.<\/p>\n [1] \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Altivec Technology Programming Interface Manual<\/a><\/p>\n [2]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0NEON Intrinsics Reference<\/a><\/p>\n [3]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0Intel Intrinsics Guide<\/a><\/p>\n Andreas Ehmanns besch\u00e4ftigt sich seit mehr als 20 Jahren mit eingebetteten Systemen und den Herausforderungen f\u00fcr weiche und harte Echtzeit-Systeme. Schon Ende der 90er Jahre begann er damit, Linux sowohl auf etablierten als auch auf neuen Systemen mit Echtzeitanforderungen einzusetzen. Er arbeitet als ‚Technischer Berater f\u00fcr Embedded Software Systeme‘ und untersucht unter anderem die Eignung verschiedener Prozessorarchitekturen f\u00fcr den Einsatz im embedded Bereich.<\/p>\n Beitrag als PDF-Datei downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Embedded- und Echtzeit-Softwareentwicklung.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\n\n
Historie<\/h2>\n
Voraussetzungen<\/h2>\n
Umsetzung<\/h2>\n
Autovektorisierung<\/h2>\n
Zusammenfassung<\/h2>\n
Literaturverzeichnis<\/h2>\n
Autor<\/h2>\n
\nEchtzeit – MicroConsult Trainings & Coachings<\/h2>\n
\nEchtzeit – Fachwissen<\/h2>\n