Interview: Das Versprechen von Intel oneAPI und Direct Parallel C++

Intel ist nicht der erste Name, der einem in den Sinn kommt, wenn man an Softwareentwicklung denkt, obwohl es eines der einflussreichsten und innovativsten Technologieunternehmen der Welt ist. Vor vier Jahrzehnten trug der 8088-Prozessor von Intel dazu bei, die PC-Revolution zu starten, und wenn Sie dies auf einem Desktop-PC oder Laptop lesen, haben Sie wahrscheinlich Intel Inside. Das Gleiche gilt für Server und eine Reihe anderer Hardware, auf die wir uns täglich verlassen. Das soll nicht heißen, dass AMD und andere Anbieter keine konkurrenzfähigen Produkte haben, aber Intel dominiert immer noch den x86-CPU-Markt.

Softwareingenieure verwenden seit Jahrzehnten Hardwareplattformen von Intel, in der Regel ohne die Software und Firmware dahinter überhaupt zu berücksichtigen. Wenn sie mehr Virtualisierungsleistung benötigten, entschieden sie sich für Multicore-, hyperthreaded Core i7- oder Xeon-Produkte. Für lokale Datenbankbasteleien könnten sie eine Intel-SSD bekommen. Aber jetzt möchte Intel, dass Entwickler auch mehr von seiner Software verwenden.

Was ist Intel OneAPI?

Geben Sie oneAPI ein, das von Intel als ein einziges, einheitliches Programmiermodell angepriesen wird, das darauf abzielt, die Entwicklung über verschiedene Hardwarearchitekturen hinweg zu vereinfachen: CPUs, GPUs, FPGAs, KI-Beschleuniger und mehr. Alle von ihnen haben sehr unterschiedliche Eigenschaften und zeichnen sich durch unterschiedliche Arten von Operationen aus.

Intel hat sich nun einer „Software-First“-Strategie verschrieben und erwartet, dass die Entwickler dies bemerken. Die großartige Idee hinter oneAPI ist es, die Verwendung einer Plattform für eine Reihe unterschiedlicher Hardware zu ermöglichen, sodass Entwickler beispielsweise beim Codieren für CPUs und GPUs nicht unterschiedliche Sprachen, Tools und Bibliotheken verwenden müssen. Mit oneAPI wären die Toolbox und die Codebasis für beide gleich.

Um dies zu ermöglichen, hat Intel Data Parallel C++ (DPC++) als Open-Source-Alternative zu proprietären Sprachen entwickelt, die typischerweise zum Programmieren für bestimmte Hardware (z. B. GPUs oder FFPGAs) verwendet werden. Diese neue Programmiersprache soll die Produktivität und Vertrautheit von C++ bieten und gleichzeitig einen Compiler enthalten, der auf verschiedenen Hardwarezielen bereitgestellt werden kann.

Data Parallel C++ enthält auch SYCL der Khronos Group, um Datenparallelität und heterogene Programmierung zu unterstützen. Intel bietet derzeit kostenlosen Zugang zu seiner DevCloud an, sodass Softwareentwickler ihre Tools ausprobieren und ohne großen Aufwand in der Cloud an oneAPI und DPC++ basteln können.

Aber warten Sie, funktioniert es auf Hardware anderer Anbieter? Was ist mit der Lizenzierung, ist es kostenlos? Ja und ja: oneAPI ist hardwareunabhängig und Open Source konzipiert, und das wird sich nicht ändern.

Um mehr über oneAPI zu erfahren, haben wir seine Entstehung und Zukunft mit Sanjiv M. Shah, Vice President der Intel Architecture, Graphics and Software Group und General Manager of Technical, Enterprise, and Cloud Computing bei Intel, besprochen.

Sanjiv: In Bezug auf das, was in oneAPI enthalten ist, sehe ich es als vier Teile an. Eines ist eine Sprache und eine Standardbibliothek, das zweite ist eine Reihe von Deep-Learning-Tools, das dritte ist wirklich eine Hardware-Abstraktionsschicht und eine Software-Treiberschicht, die verschiedene Beschleuniger abstrahieren können, und das vierte Teil ist eine Reihe von domänenorientierten Bibliotheken , wie Matlab und so weiter. Das sind die vier Kategorien von Dingen in oneAPI, aber wir können tiefer gehen und über die neun Elemente von oneAPI sprechen. Diese neun Elemente sind im Grunde die neue Sprache, die wir einführen, genannt Data Parallel C++ und ihre Standardbibliothek.

Es gibt zwei Lernbibliotheken, eine für neuronale Netze und eine für Kommunikation. Es gibt die Bibliothek, die wir Ebene Null nennen, die für die Hardware-Abstraktion bestimmt ist, und es gibt vier domänenorientierte Bibliotheken. Wir tun dies auf sehr, sehr offene Weise. Die Spezifikationen für all diese sind bereits offen und verfügbar. Wir nennen sie Version 0.5. Wir beabsichtigen, bis Ende 2020 auf 1.0 umzusteigen, und wir haben auch Open-Source-Implementierungen von all diesen. Auch hier ist es unser Ziel, den Menschen zu ermöglichen, das zu nutzen, was bereits da draußen ist. Wenn ein Hardwareanbieter diese Sprache implementieren möchte, kann er Open Source nehmen und damit ausführen.

F: Wie funktioniert das in Bezug auf Algorithmen und Implementierung?

Was wir bereitstellen, sind die Grundelemente, die die Algorithmen verwenden würden: die zugrunde liegenden mathematischen Grundelemente und Kommunikationsgrundelemente. Typischerweise findet die Innovation von Algorithmen auf einer höheren Ebene statt, wo sie nicht wirklich die grundlegende Mathematik, Matrixmathematik, Faltungsmathematik und so weiter wiederholen. Es geht darum, neue Wege zu finden, diese Mathematik zu nutzen, und neue Wege, Kommunikationsmuster zu nutzen. Unser Ziel ist es wirklich, das Primitiv, die Ebene Null, bereitzustellen, damit andere darauf aufbauend innovativ sein können.

F: Wie funktioniert es auf Hardwareebene?

Wenn Sie ein Hardwareanbieter sind, nehmen wir zum Beispiel eine KI-Matrix, jemanden, der einen KI-ASIC erstellt – es gibt zwei Möglichkeiten für diesen Hardwareanbieter, sich „anzuschließen“ und das KI-Ökosystem zu nutzen. Eine wäre, diese Low-Level-Hardwareschnittstelle bereitzustellen, die wir Level Zero nennen, und wenn sie ihre Version von Level Zero mithilfe der Standard-API bereitstellen, können sie Open Source nutzen, wenn sie möchten, und dann alle darüber liegenden Softwareschichten kann das automatisch nutzen.

Das könnte für segmentorientierte ASICs schwierig sein, die volle Allgemeingültigkeit von Level Zero bereitzustellen. Als Alternative dazu können sie also auch nur die mathematischen Kernel und Kommunikationskerne bereitstellen, die sich in unseren Domänen- und Deep-Learning-Bibliotheken befinden, und dann werden wir die Aufgabe übernehmen, diese Bibliotheken in die übergeordneten Frameworks einzubinden sie würden das automatisch bekommen.

F: Sie haben erwähnt, dass die Version, die Sie derzeit haben, als 0.5 bezeichnet wird und die vollständige Spezifikation bis Ende 2020 fertig sein sollte.

Unsere oneAPI-Initiative besteht also aus zwei Teilen. Einer ist der Industrieteil und einer sind Intel-Produkte. Die Branchenspezifikation liegt bei 0,5, und Mitte des Jahres möchten wir sie auf 1,0 bringen. Parallel dazu baut Intel eine Reihe von Produkten, und die Produkte, die Intel baut, befinden sich heute in der Beta-Phase und implementieren die 0.5-Spezifikation. Bis Ende des Jahres möchten wir zu einem 1.0-Produkt kommen.

Das Produkt von Intel geht über die neun Elemente von oneAPI hinaus, da wir zusätzlich zu den grundlegenden Programmierelementen, die wir bereitstellen, auch die Dinge bereitstellen möchten, die Programmierer wirklich benötigen, wie Debugger, Analysatoren und Kompatibilitätstools, damit sie von vorhandenen Sprachen in die Daten migrieren können Parallele C++-Sprache.

F: Wie schwierig ist der Übergang für den Entwickler? Ist die breitere Umgebung ähnlich der, die sie seit Jahren verwenden?

Ja, es ist sehr ähnlich. Lassen Sie mich Data Parallel C++ ein wenig beschreiben, denn das ist ein großer Teil dessen, was wir tun. DPC++ ist drei Dinge. Es baut auf der internationalen ISO-Standardsprache C++ auf. Es gibt eine Gruppe namens Khronos, die den Standard namens SYCL definiert, und SYCL ist auf C++ aufgesetzt. Wir nehmen SYCL und fügen dann Erweiterungen über SYCL hinzu. So wie wir Data Parallel C++ bauen, ist es wirklich nur C++ mit Erweiterungen darauf, was SYCL ist.

Jeder C++-Compiler kann es kompilieren. Das Schöne an DPC++ ist, dass jeder Compiler es kompilieren kann, nur ein sachkundiger Compiler kann die Vorteile dieser Sprache nutzen und Beschleunigercode generieren. Die Art und Weise, wie wir diese Sprache führen, tun wir sehr, sehr offen, daher finden alle unsere Diskussionen über Data Parallel C++ mit dem SYCL-Komitee statt. Die Implementierungen sind Open Source, alle Erweiterungen sind bereits veröffentlicht, und wir arbeiten sehr, sehr sorgfältig, um sicherzustellen, dass wir einen guten Gleitpfad in die zukünftigen SYCL-Standards haben. Mit Blick auf 5-10 Jahre ab jetzt auch ein Gleitpfad in ISO C++.

F: In Bezug auf die Compiler und die Migration zu DPC++ sollte die Lernkurve kein großes Problem darstellen?

Ja, es kommt natürlich darauf an, wo man anfängt. Für einen C++-Programmierer wäre die Lernkurve sehr gering. Für einen C-Programmierer müssten Sie die Hürde überwinden, C++ zu lernen, aber das ist alles. Es ist sehr vertrautes C++. Für einen Programmierer, der an Sprachen wie OpenCL gewöhnt ist, sollte es sehr ähnlich sein.

Der andere Teil, den ich betonen muss, ist, dass wir die Arbeit in Open Source unter Verwendung der LLVM-Infrastruktur erledigen. Alle unsere Quellen sind bereits offen, es gibt ein Intel GitHub-Repository, in dem Sie sich die Sprachimplementierung ansehen und sogar einen Open-Source-Compiler herunterladen können. Alle Intel-Tools, unsere Beta-Produktangebote, sind ebenfalls kostenlos für jedermann zum Spielen und Herunterladen verfügbar. Wir haben auch eine Entwickler-Cloud zur Verfügung, in der die Leute nichts herunterladen oder installieren müssen, sie können einfach den Code schreiben und anfangen, alle Tools zu verwenden, über die wir gesprochen haben.

F: C++ ist leistungsfähig und relativ einfach, aber wir alle wissen, dass es alt wird, die Entwicklung langsam ist, es zu viele Beteiligte gibt, also verlangsamen sie alles. Dies wäre bei DPC++ offensichtlich nicht der Fall. Sie hätten viel schnellere Iterationen und Updates?

Ich denke, Sie haben einen sehr, sehr wichtigen Punkt für uns erreicht, nämlich eine schnelle Entwicklung, die nicht durch Standards gebremst wird. Also wollen wir unsere Diskussionen offen mit dem Standard führen, also gibt es einen Weg, in die Standards einzusteigen, aber wir wollen es auch schnell tun.

Sprachen funktionieren am besten, wenn sie von ihren Benutzern und Implementierern gemeinsam entworfen werden, während sich Architekturen weiterentwickeln. Unser Ziel ist ein wirklich schnelles iteratives Codedesign, bei dem wir Dinge üben, den besten Weg finden, Dinge zu tun, und sie zum Standard machen. Also, absolut schnelle Iteration ist ein großes Ziel.

F: Eine Frage, die von einigen meiner Kollegen aufgeworfen wurde (Sie können wahrscheinlich verstehen, dass sie etwas besorgt sind über die Offenheit bei allem, was von einem großen Unternehmen kommt): Wird DPC++ immer für alle Benutzer und Anbieter offen bleiben?

Absolut! Die Spezifikation erfolgt mit einer Creative-Commons-Lizenz. Jeder kann die Spezifikation verwenden, sie nehmen und forken, wenn er möchte, und sie weiterentwickeln. Ich möchte betonen, dass nicht alle Elemente von oneAPI Open Source sind, aber wir sind auf dem Weg, fast alle Elemente Open Source zu machen. All das kann jeder greifen und nutzen – es steht für die Implementierung zur Verfügung.

Codeplay, ein Unternehmen aus Großbritannien, hat eine Nvidia-Implementierung von DPC++ angekündigt, und wir ermutigen wirklich alle Hardware- und Softwareanbieter, ihre Portierung vorzunehmen. Wir befinden uns an einem einzigartigen Punkt in der Branche, an dem Beschleuniger für mehrere Anbieter üblich werden. Wenn das in der Geschichte passiert, wenn es nur einen Anbieter gibt, dominiert ihre Sprache. Die Softwareindustrie fordert eine Standardlösung und mehrere Anbieter.

Was wir hier versuchen, ist das, was wir vor etwa zweieinhalb Jahrzehnten mit OpenMP gemacht haben, wo es mehrere parallele Sprachen gab, aber keine einzige, die wirklich dominant war. Wir haben all das genommen und es in einem Standard vereinheitlicht, der jetzt, 25 Jahre später, die Art und Weise ist, für HPC zu programmieren.

F: Wäre es richtig zu sagen, dass sich DPC++ in den nächsten Jahren stark weiterentwickeln wird? Was ist mit Tensoren, was ist mit neuer Hardware, die herauskommt?

Ja, absolut, du hast recht. Wir müssen die Sprache weiterentwickeln, um die neue Hardware zu unterstützen, die herauskommt. Das ist das Ziel der schnelleren Iteration. Ein weiterer Punkt, den ich betonen möchte, ist, dass wir Data Parallel C++ so entwerfen, dass Sie auch architekturspezifische Erweiterungen einbinden können, wenn Sie möchten.

Obwohl es sich um eine Standardsprache handelt, die wir über mehrere Architekturen hinweg ausführen möchten, erkennen wir auch, dass manchmal ein Publikum, ein sehr wichtiges Publikum, die maximal mögliche Leistung benötigt. Sie möchten vielleicht auf sehr niedrige Programmierebene abtauchen, die nicht unbedingt architekturportierbar ist. Wir bauen Erweiterungen und Mechanismen, damit Sie Erweiterungen für Tensoren usw. haben können, die architekturspezifisch wären.

F: Wie viel Kontrolle über den für die Hardware generierten Code könnte ein Entwickler haben? Wie viel Kontrolle können sie über die Speicherverwaltung zwischen dem System und verschiedenen Beschleunigern haben?

Wir leihen uns das Konzept der Puffer von SYCL, die dem Benutzer eine sehr explizite Speicherkontrolle geben, aber zusätzlich fügen wir auch den Begriff des einheitlichen Speichers hinzu. Unser Ziel ist es, dem Programmierer ein Maß an Kontrolle zu geben, das er benötigt, nicht nur um den Speicher zu verwalten, sondern auch um schnellen Code zu generieren. Einige der Erweiterungen, die wir über SYCL hinzufügen, sind Dinge wie Untergruppen, Reduktionen, Pipes und so weiter. Dadurch können Sie viel besseren Code für verschiedene Architekturen generieren.

F: Ein interessanter Punkt ist die oneAPI-Distribution für Python – Intel listet speziell NumPy, SciPy, SciKit Learn auf. Ich bin neugierig auf den Leistungsgewinn und die Produktivitätsvorteile, die durch oneAPI freigeschaltet werden könnten. Hast du irgendwelche Metriken dazu?

Das ist eine ausgezeichnete Frage. Wir unterstützen dieses Ökosystem. Warum sollte Python einen Beschleuniger verwenden wollen? Es soll Leistung aus seinen mathematischen Bibliotheken und Analysebibliotheken herausholen. Was wir tun, ist, NumPy, SciPy, SciKit Learn usw. zu "installieren", damit wir eine gute Leistung erzielen können, indem wir die Bibliotheken nutzen, die wir darüber haben. Die Standardimplementierung von NumPy, SciPy, SciKit Learn usw. kann im Vergleich zu derjenigen, die mit optimierten nativen Paketen richtig ausgelotet wurde, sehr, sehr große Gewinne erzielen. Wir haben Gewinne in der Größenordnung von 200x, 300x usw. gesehen.

Unser Ziel mit Python ist, dass wir innerhalb eines vernünftigen Bruchteils, innerhalb des 2-fachen, vielleicht innerhalb von 80 Prozent der nativen Codeleistung kommen möchten. Der heutige Stand der Technik ist, dass Sie häufig bei 10x oder mehr liegen. Wir wollen diese Lücke wirklich überbrücken, indem wir alle Hochleistungsaufgaben so ausloten, dass Sie innerhalb eines Faktors von 2 und sogar viel darüber liegen.

F: Über welche Arten von Hardware sprechen wir? Könnten Entwickler dieses Potenzial auf einer gewöhnlichen Workstation freisetzen, oder würde es etwas Leistungsstärkeres erfordern?

Nein, es wäre überall. Wenn Sie darüber nachdenken, woher der Gewinn kommt, werden Sie verstehen. Die normalen Python-Bibliotheken verwenden keine der Virtualisierungsfunktionen auf CPUs. Sie verwenden keine der Multi-Core-Fähigkeiten auf CPUs. Sie sind nicht optimiert, das Speichersystem und alles, was nicht optimiert ist. Es läuft also auf eine Matrixmultiplikation hinaus, die von einem naiven Programmierer geschrieben und von einem Compiler ohne Optimierung kompiliert wurde, und vergleichen Sie das dann mit dem, was ein Experte in Assemblercode schreibt. Sie können Multi-100-fache Gewinne sehen, wenn Sie diese beiden vergleichen, und in der Python-Welt passiert im Wesentlichen genau das.

Die Python-Interpreter und Standardbibliotheken sind so hoch entwickelt, dass der Code, den Sie erhalten, sehr, sehr naiver Code wird. Wenn Sie es richtig mit optimierten Bibliotheken ausstatten, erhalten Sie diese enormen Gewinne. Ein Laptop hat bereits zwei bis sechs oder acht CPU-Kerne, sie sind multithreaded und haben ziemlich anständige Vektorisierungsfunktionen, vielleicht sind es 256, vielleicht sind es 512. In Laptops und Workstations steckt also viel Leistung. Wenn Sie das auf GPUs hochskalieren, können Sie sich vorstellen, woher die Gewinne kommen, sobald Sie Grafiken zur Verfügung haben.

Wenn Sie sich unsere integrierten Grafiken ansehen, werden sie auch sehr leistungsfähig. Ich bin sicher, Sie haben die Ice Lake Gen 11 gesehen, wo die integrierte Grafik deutlich besser ist als bei der vorherigen Generation. Sie können sehen, woher die Vorteile kommen würden, sogar auf Laptops.

F: Was ist mit der DevCloud-Verfügbarkeit? Wenn ich mich richtig erinnere, ist es im Moment für alle kostenlos, aber wird es so bleiben, wenn Sie nächstes Jahr Gold bekommen?

Das ist eine gute Frage. An diesem Punkt, um ehrlich zu sein, kenne ich die Antwort nicht. Unsere Absicht an diesem Punkt ist, dass es für immer kostenlos ist. Es ist für die Entwicklung, zum Herumspielen, und es gibt eine Menge Pferdestärken, damit die Leute tatsächlich ihre Läufe machen können.

F: Sie hätten also nichts dagegen, wenn wir ein paar tausend Entwickler bitten würden, es auszuprobieren?

Ach, absolut nicht. Wir würden uns freuen, wenn das passiert!

Ich kann zusammenfassen, was wir zu tun versuchen. Erstens sind wir sehr, sehr begeistert von oneAPI. Es ist an der Zeit, dass eine Multi-Vendor-Lösung durchstartet, da mittlerweile mehrere Anbieter auf dem Markt verfügbar sind. Wenn Sie sich unsere Prozessorreihe ansehen, nicht nur die kommenden GPUs, immer leistungsstärkere integrierte GPUs und unsere FPGA-Roadmap, dann ist dies eine aufregende Zeit, um einen Standard für all das zu schaffen. Unser Ziel ist Produktivität, Leistung und Brancheninfrastruktur, damit Sie darauf aufbauen können.

Was die drei Zielgruppen betrifft, über die ich gesprochen habe, können Anwendungsentwickler die Dinge leicht nutzen, da sie bereits verfügbar sind. Hardwareanbieter können den Software-Stack nutzen und neue Hardware anschließen, während Tool- und Sprachanbieter ihn problemlos verwenden können. Intel kann nicht alle Sprachen und Tools der Welt bauen, also ist es eine Open-Source-Infrastruktur, die andere sehr leicht nutzen und darauf aufbauen können.