Interviu: Promisiunea Intel oneAPI și Direct Parallel C++

Intel nu este primul nume care îți vine în minte când te gândești la dezvoltarea de software, deși este una dintre cele mai influente și inovatoare companii de tehnologie de pe planetă. Acum patru decenii, procesorul Intel 8088 a ajutat la lansarea revoluției PC-urilor, iar dacă citiți acest lucru pe un desktop sau un laptop, sunt șanse să aveți un Intel Inside. Același lucru este valabil și pentru servere și o gamă de alte componente hardware pe care ne bazăm în fiecare zi. Asta nu înseamnă că AMD și alți furnizori nu au produse competitive pentru că au, dar Intel domină în continuare piața procesoarelor x86.

Inginerii de software folosesc platformele hardware Intel de zeci de ani, de obicei fără să ia în considerare software-ul și firmware-ul din spatele lor. Dacă aveau nevoie de mai multă performanță de virtualizare, au optat pentru produse multicore, hyperthreaded Core i7 sau Xeon. Pentru modificarea bazelor de date locale, ar putea obține un SSD Intel. Dar acum, Intel dorește ca dezvoltatorii să înceapă să folosească și mai mult din software-ul său.

Ce este Intel oneAPI?

Introduceți oneAPI, prezentat de Intel ca un model de programare unic și unificat, care își propune să simplifice dezvoltarea în diferite arhitecturi hardware: CPU-uri, GPU-uri, FPGA-uri, acceleratoare AI și multe altele. Toate au proprietăți foarte diferite și excelează la diferite tipuri de operațiuni.

Intel se angajează acum să adopte o strategie „în primul rând software-ul” și se așteaptă ca dezvoltatorii să ia notă. Ideea mare din spatele oneAPI este de a permite utilizarea unei platforme pentru o serie de hardware diferit, prin urmare dezvoltatorii nu ar trebui să folosească diferite limbi, instrumente și biblioteci atunci când codifică pentru procesoare și GPU-uri, de exemplu. Cu oneAPI, setul de instrumente și baza de cod ar fi aceleași pentru ambele.

Pentru a face acest lucru posibil, Intel a dezvoltat Data Parallel C++ (DPC++) ca o alternativă open-source la limbajele proprietare utilizate de obicei pentru programarea pentru hardware specific (de exemplu, GPU-uri sau FFPGA-uri). Acest nou limbaj de programare ar trebui să ofere productivitatea și familiaritatea C++, incluzând în același timp un compilator pentru a fi implementat în diferite ținte hardware.

Data Parallel C++ încorporează, de asemenea, SYCL-ul Khronos Group pentru a sprijini paralelismul datelor și programarea eterogenă. Intel oferă în prezent acces gratuit la DevCloud, permițându-le inginerilor de software să-și încerce instrumentele și să joace cu oneAPI și DPC++ în cloud fără prea multe bătăi de cap.

Dar stai, va funcționa pe hardware făcut de alți furnizori? Ce zici de licențiere, este gratuită? Da și da: oneAPI este conceput pentru a fi independent de hardware și open-source, iar asta nu se va schimba.

Pentru a afla mai multe despre oneAPI, am discutat despre geneza și viitorul acestuia cu Sanjiv M. Shah, Vicepreședintele Grupului Intel de Arhitectură, Grafică și Software și director general pentru Tehnic, Enterprise și Cloud Computing la Intel.

Sanjiv: În ceea ce privește ceea ce este în oneAPI, cred că sunt patru bucăți. Unul este un limbaj și o bibliotecă standard, al doilea este un set de instrumente de învățare profundă, al treilea este într-adevăr un strat de abstractizare hardware și un strat de driver software care poate abstrage diferite acceleratoare, iar a patra piesă este un set de biblioteci concentrate pe domeniu. , ca Matlab și așa mai departe. Acestea sunt cele patru categorii de lucruri din oneAPI, dar putem merge mai adânc și vorbim despre cele nouă elemente ale oneAPI. Aceste nouă elemente sunt practic noul limbaj pe care îl introducem, numit Data Parallel C++ și biblioteca sa standard.

Există două biblioteci de învățare, una pentru rețele neuronale și una pentru comunicații. Există biblioteca pe care o numim nivel zero, care este pentru abstractizarea hardware și există patru biblioteci concentrate pe domeniu. Facem asta într-un mod foarte, foarte deschis. Specificațiile pentru toate acestea sunt deja deschise și disponibile. Le numim versiunea 0.5. Intenționăm să trecem la 1.0 până la sfârșitul anului 2020 și avem, de asemenea, implementări open-source ale tuturor acestora. Din nou, scopul nostru este de a le permite oamenilor să folosească ceea ce există deja. Dacă un furnizor de hardware dorește să implementeze acest limbaj, poate lua ceea ce este open-source și poate rula cu el.

Î: În ceea ce privește algoritmii și implementarea, cum funcționează?

Ceea ce oferim sunt primitivele pe care algoritmii le-ar folosi: primitivele matematice subiacente și primitivele de comunicare. În mod obișnuit, inovarea algoritmilor are loc la un nivel mai înalt decât acesta, în cazul în care nu refac cu adevărat matematica fundamentală, matematica matriceală, matematica convoluției și așa mai departe. Este vorba despre găsirea unor noi modalități de a folosi matematica și noi moduri de a folosi modelele de comunicare. Scopul nostru este într-adevăr să oferim primitivul, nivelul zero, astfel încât alții să poată inova pe deasupra.

Î: Cum funcționează la nivel hardware?

Dacă sunteți un furnizor de hardware, să luăm o matrice AI, cineva care construiește un AI ASIC, de exemplu - există două moduri prin care acel furnizor de hardware se „conecta” și să folosească ecosistemul AI. Una ar fi să oferim această interfață hardware de nivel scăzut pe care o numim nivel zero și, dacă oferă versiunea lor de nivel zero folosind API-ul standard, pot folosi sursa deschisă dacă doresc, și apoi toate straturile software de mai sus. poate folosi automat asta.

Ar putea fi greu pentru un ASIC-uri focalizate pe segment, să ofere întreaga generalitate a nivelului zero. Deci, ca o alternativă la asta, ei pot furniza doar nucleele de matematică și nucleele de comunicare care sunt în domeniul nostru și bibliotecile de deep learning, iar apoi vom face treaba de a „instala” acele biblioteci în cadrele de nivel superior, deci ar primi asta automat.

Î: Ați menționat că versiunea pe care o aveți acum este desemnată 0.5, iar specificațiile complete ar trebui să fie gata până la sfârșitul anului 2020.

Deci, există două părți ale inițiativei noastre oneAPI. Una este partea din industrie, iar una este produsele Intel. Specificațiile din industrie sunt la 0,5, iar pe la jumătatea anului, am dori să o aducem la 1,0. În paralel, Intel construiește un set de produse, iar produsele pe care Intel le construiește sunt astăzi în versiune beta și implementează specificația 0.5. Până la sfârșitul anului, am dori să ajungem la un produs 1.0.

Produsul Intel depășește cele nouă elemente ale oneAPI deoarece, pe lângă elementele de programare de bază pe care le oferim, dorim să oferim și lucrurile de care programatorii au nevoie cu adevărat, cum ar fi depanatoare, analizoare și instrumente de compatibilitate, astfel încât să migreze din limbile existente în Data. Limbajul C++ paralel.

Î: Cât de greu este pentru dezvoltator să facă tranziția? Mediul mai larg este similar cu cel pe care l-au folosit de ani de zile?

Da, este foarte asemănător. Permiteți-mi să descriu puțin Data Parallel C++, deoarece aceasta este o mare parte a ceea ce facem. DPC++ este trei lucruri. Se bazează pe limbajul standard internațional ISO C++. Există un grup numit Khronos care definește standardul numit SYCL, iar SYCL este stratificat deasupra C++. Luăm SYCL și apoi adăugăm extensii peste SYCL. Modul în care construim Data Parallel C++, este într-adevăr doar C++ cu extensii pe el, ceea ce este SYCL.

Orice compilator C++ îl poate compila. Frumusețea DPC++ este că orice compilator îl poate compila, doar un compilator cu cunoștințe poate profita de ceea ce este în limbajul respectiv și poate genera cod accelerator. Modul în care conducem acest limbaj, o facem foarte, foarte deschis, așa că toate discuțiile noastre despre Data Parallel C++ au loc cu comitetul SYCL. Implementările sunt open-source, toate extensiile sunt deja publicate și lucrăm foarte, foarte atent pentru a ne asigura că avem o cale de alunecare bună către viitoarele standarde SYCL. Privind în jos la 5-10 ani de acum înainte, o cale de alunecare și în ISO C++.

Î: În ceea ce privește compilatoarele și migrarea către DPC++, curba de învățare nu ar trebui să fie o problemă?

Da, depinde de unde porniți, desigur. Pentru un programator C++, curba de învățare ar fi foarte mică. Pentru un programator C, ar trebui să treci peste obstacolul de a învăța C++, dar asta e tot. Este foarte familiar C++. Pentru un programator obișnuit cu limbaje precum OpenCL, ar trebui să fie foarte asemănător.

Cealaltă parte pe care trebuie să o subliniez este că lucrăm în sursă deschisă folosind infrastructura LLVM. Toată sursa noastră este deja deschisă, există un depozit Intel GitHub unde poți să te uiți la implementarea limbajului, chiar să descarci un compilator open-source. Toate instrumentele Intel, ofertele noastre de produse care sunt beta sunt, de asemenea, disponibile gratuit pentru ca oricine să se joace și să le descarce. Avem disponibil și un cloud pentru dezvoltatori, unde oamenii nu trebuie să descarce sau să instaleze nimic, pot doar să scrie codul și să înceapă să folosească toate instrumentele despre care am vorbit.

Î: C++ este performant și relativ simplu, dar știm cu toții că îmbătrânește, dezvoltarea este lentă, sunt prea mulți factori interesați, așa că încetinesc totul. Acest lucru, evident, nu ar fi cazul cu DPC++. Ai avea iterații și actualizări mult mai rapide?

Cred că ați atins un punct foarte, foarte important pentru noi, care este evoluția rapidă, care nu este încetinită de standarde. Deci, vrem să ne facem discuțiile deschis cu standardul, deci există o modalitate de a intra în standarde, dar vrem și să o facem rapid.

Limbile funcționează cel mai bine atunci când sunt proiectate în comun de utilizatorii și implementatorii lor, pe măsură ce arhitecturile evoluează. Scopul nostru este proiectarea rapidă a codului iterativ, în care exersăm lucrurile, găsim cea mai bună modalitate de a face lucrurile și le facem standard. Deci, absolut, repetarea rapidă este un obiectiv mare.

Î: O întrebare care a fost ridicată de unii dintre colegii mei (probabil puteți înțelege că sunt oarecum preocupați de deschiderea față de orice vine de la o mare corporație): Va rămâne DPC++ întotdeauna deschis tuturor utilizatorilor și furnizorilor?

Absolut! Specificația este realizată cu o licență creative commons. Oricine poate folosi specificațiile, să o ia și să o bifurcă dacă dorește și să o evolueze. Vreau să subliniez că nu toate elementele oneAPI sunt open-source, dar suntem pe calea de a face aproape toate elementele open-source. Toate acestea, oricine le poate folosi și poate folosi - sunt disponibile pentru implementare.

Codeplay, care este o companie din Marea Britanie, a anunțat o implementare Nvidia a DPC++ și îi încurajăm cu adevărat pe toți furnizorii de hardware și software să-și facă portul. Ne aflăm într-un punct unic în industrie, în care acceleratoarele devin comune pentru mai mulți furnizori. Când asta se întâmplă în istorie, când există un singur furnizor, limba lor domină. Industria software-ului cere o soluție standard și mai mulți furnizori.

Ceea ce încercăm să facem aici este ceea ce am făcut acum aproximativ două decenii și jumătate cu OpenMP, unde existau mai multe limbi paralele, dar nici unul cu adevărat dominant. Am luat toate acestea și le-am unificat într-un standard care acum, 25 de ani mai târziu, este modalitatea de programare pentru HPC.

Î: Ar fi corect să spunem că DPC++ va avea o mare evoluție în următorii câțiva ani? Dar tensorii, cum rămâne cu noul hardware care iese?

Da, absolut, ai dreptate. Trebuie să evoluăm limbajul pentru a sprijini noul hardware care apare. Acesta este scopul unei repetiții mai rapide. Un alt punct pe care vreau să-l subliniez este că proiectăm Data Parallel C++, astfel încât să puteți conecta și extensii specifice arhitecturii dacă doriți.

Așadar, deși este un limbaj standard pe care vrem să îl rulăm în mai multe arhitecturi, ne dăm seama și că uneori, un public, un public foarte important are nevoie de performanța maximă posibilă. Ar putea dori să se scufunde la programarea de nivel foarte scăzut, care nu va fi neapărat portabilă pentru arhitectură. Construim extensii și mecanisme, astfel încât să puteți avea extensii pentru tensori și așa mai departe, care ar fi specifice arhitecturii.

Î: Cât de mult control asupra codului generat pentru hardware ar putea avea un dezvoltator? Cât de mult control pot avea asupra gestionării memoriei între sistem și diverse acceleratoare?

Imprumutăm conceptul de buffere de la SYCL, care oferă utilizatorului un control foarte explicit al memoriei, dar în plus, adăugăm și noțiunea de memorie unificată . Scopul nostru este să oferim programatorului un nivel de control de care are nevoie, nu doar pentru a gestiona memoria, ci și pentru a genera cod rapid. Unele dintre extensiile pe care le adăugăm peste SYCL sunt lucruri precum subgrupuri, reduceri, conducte și așa mai departe. Acest lucru vă va permite să generați cod mult mai bun pentru diferite arhitecturi.

Î: Un punct interesant este distribuția oneAPI pentru Python—Intel enumerate în mod special NumPy, SciPy, SciKit Learn. Sunt curios de câștigul de performanță și de beneficiile de productivitate care ar putea fi deblocate prin oneAPI. Aveți vreo măsură în acest sens?

Aceasta este o întrebare excelentă. Sprijinim acel ecosistem. De ce ar vrea Python să folosească un accelerator? Este pentru a obține performanță din bibliotecile sale de matematică, bibliotecile de analiză. Ceea ce facem este să „instalăm” NumPy, SciPy, SciKit Learn etc., astfel încât să putem obține performanțe bune utilizând bibliotecile pe care le avem deasupra. Implementarea implicită a NumPy, SciPy, SciKit Learn și așa mai departe, în comparație cu cea care este conectată corect cu pachete native optimizate, poate vedea câștiguri foarte, foarte mari. Am văzut câștiguri de ordinul a 200x, 300x etc.

Scopul nostru cu Python este că am dori să ajungem într-o fracțiune rezonabilă, în 2x, poate în 80% din performanța codului nativ. Stadiul actual al tehnicii de astăzi este că sunteți frecvent la 10x sau mai mult. Dorim cu adevărat să reducem această decalaj prin instalarea tuturor sarcinilor de înaltă performanță, astfel încât să fiți în limita unui factor de 2 și, de fapt, mult mai mult decât atât.

Î: Despre ce tipuri de hardware vorbim? Ar putea dezvoltatorii să deblocheze acest potențial pe o stație de lucru obișnuită sau ar necesita ceva mai puternic?

Nu, ar fi peste tot. Dacă te gândești de unde vine câștigul, atunci vei înțelege. Bibliotecile normale Python nu folosesc niciuna dintre capabilitățile de virtualizare de pe procesoare. Ei nu folosesc niciuna dintre capabilitățile multi-core de pe procesoare. Nu sunt optimizate, sistemul de memorie și tot ce nu este optimizat. Deci, se reduce la o înmulțire a matricei care este scrisă de un programator naiv și compilată de un compilator fără nicio optimizare, apoi compară asta cu ceea ce scrie un expert în codul de asamblare. Puteți vedea câștiguri de 100 de ori când le comparați pe cele două, iar în lumea Python, în esență, asta se întâmplă.

Interpreții Python și bibliotecile standard sunt atât de la nivel înalt încât codul cu care ajungeți devine un cod foarte, foarte naiv. Când îl conectați corect cu biblioteci optimizate, obțineți acele câștiguri uriașe. Un laptop are deja două până la șase sau opt nuclee CPU, sunt multithreaded și au capacități de vectorizare destul de decente în ele, poate este 256, poate este 512. Deci, există o mulțime de performanță în laptopuri și stații de lucru. Când scalați până la GPU-uri, odată ce aveți grafică disponibilă, vă puteți imagina de unde vin câștigurile.

Dacă vă uitați la grafica noastră integrată, acestea devin și foarte puternice. Sunt sigur că ați văzut Ice Lake Gen 11, unde grafica integrată este semnificativ mai bună decât generația anterioară. Puteți vedea de unde ar veni beneficiile, chiar și pe laptopuri.

Î: Cum rămâne cu disponibilitatea DevCloud? Dacă îmi amintesc corect, este gratuit de folosit pentru toată lumea în acest moment, dar va rămâne așa după ce vei obține aur anul viitor?

Asta e o intrebare buna. În acest moment, o să fiu sincer, nu știu răspunsul. Intenția noastră în acest moment este ca acesta să fie gratuit pentru totdeauna. Este pentru dezvoltare, pentru a juca, și există o mulțime de cai putere acolo, astfel încât oamenii să își poată alerga.

Î: Deci, nu v-ar deranja dacă am cere câteva mii de dezvoltatori să încerce?

Oh, absolut nu. Ne-ar plăcea să se întâmple asta!

Pot rezuma ceea ce încercăm să facem. În primul rând, suntem foarte, foarte încântați de oneAPI. Este timpul să descopere o soluție cu mai mulți furnizori, deoarece există mai mulți furnizori disponibili pe piață acum. Dacă aruncați o privire la linia noastră de procesoare, nu doar la GPU-urile care vin, la GPU-uri integrate din ce în ce mai puternice și la foaia noastră de parcurs FPGA, acesta este un moment interesant pentru a construi un standard pentru toate acestea. Scopul nostru este productivitatea, performanța și infrastructura industrială, astfel încât să puteți construi pe baza acesteia.

În ceea ce privește cele trei audiențe despre care am vorbit, dezvoltatorii de aplicații pot folosi lucrurile cu ușurință, deoarece acestea sunt deja disponibile. Furnizorii de hardware pot profita de stiva de software și pot conecta hardware nou, în timp ce furnizorii de instrumente și limbi pot utiliza cu ușurință. Intel nu poate construi toate limbile și toate instrumentele din lume, așa că este o infrastructură open-source pe care alții o pot folosi și pe care o pot construi foarte ușor.