Intervista: la promessa di Intel oneAPI e Direct Parallel C++

Intel non è il primo nome che viene in mente quando si pensa allo sviluppo del software, anche se è una delle aziende tecnologiche più influenti e innovative del pianeta. Quattro decenni fa, il processore Intel 8088 ha contribuito a lanciare la rivoluzione dei PC e, se stai leggendo questo articolo su un desktop o un laptop, è probabile che tu abbia un Intel Inside. Lo stesso vale per i server e una gamma di altri hardware su cui facciamo affidamento ogni giorno. Questo non vuol dire che AMD e altri fornitori non abbiano prodotti competitivi perché ce l'hanno, ma Intel domina ancora il mercato delle CPU x86.

Gli ingegneri del software utilizzano le piattaforme hardware Intel da decenni, in genere senza nemmeno considerare il software e il firmware dietro di esse. Se avevano bisogno di maggiori prestazioni di virtualizzazione, hanno optato per prodotti Multicore, Hyperthreaded Core i7 o Xeon. Per l'armeggiare del database locale, potrebbero ottenere un SSD Intel. Ma ora Intel vuole che anche gli sviluppatori inizino a utilizzare più software.

Cos'è Intel oneAPI?

Entra in oneAPI, pubblicizzato da Intel come un unico modello di programmazione unificato che mira a semplificare lo sviluppo su diverse architetture hardware: CPU, GPU, FPGA, acceleratori di intelligenza artificiale e altro ancora. Tutti hanno proprietà molto diverse ed eccellono in diversi tipi di operazioni.

Intel è ora impegnata in una strategia "software-first" e si aspetta che gli sviluppatori se ne accorgano. La grande idea alla base di oneAPI è consentire l'uso di una piattaforma per una gamma di hardware diverso, quindi gli sviluppatori non dovrebbero utilizzare linguaggi, strumenti e librerie diversi quando codificano per CPU e GPU, ad esempio. Con oneAPI, la cassetta degli attrezzi e la base di codice sarebbero le stesse per entrambi.

Per rendere ciò possibile, Intel ha sviluppato Data Parallel C++ (DPC++) come alternativa open source ai linguaggi proprietari generalmente utilizzati per programmare hardware specifico (ad es. GPU o FFPGA). Questo nuovo linguaggio di programmazione dovrebbe fornire la produttività e la familiarità del C++ includendo un compilatore da distribuire su diversi target hardware.

Data Parallel C++ incorpora anche SYCL di Khronos Group per supportare il parallelismo dei dati e la programmazione eterogenea. Intel offre attualmente l'accesso gratuito al suo DevCloud, consentendo agli ingegneri del software di provare i loro strumenti e armeggiare con oneAPI e DPC++ nel cloud senza troppi problemi.

Ma aspetta, funzionerà su hardware prodotto da altri fornitori? E la licenza, è gratuita? Sì e sì: oneAPI è progettata per essere indipendente dall'hardware e open source e questo non cambierà.

Per saperne di più su oneAPI, abbiamo discusso della sua genesi e futuro con Sanjiv M. Shah, vicepresidente dell'architettura, grafica e software di Intel e direttore generale del settore tecnico, aziendale e cloud computing di Intel.

Sanjiv: In termini di cosa c'è in oneAPI, penso che siano quattro pezzi. Uno è un linguaggio e una libreria standard, il secondo è un insieme di strumenti di deep learning, il terzo è in realtà un livello di astrazione hardware e un livello di driver software che può astrarre diversi acceleratori e il quarto pezzo è un insieme di librerie focalizzate sul dominio , come Matlab e così via. Queste sono le quattro categorie di cose in oneAPI, ma possiamo approfondire e parlare dei nove elementi di oneAPI. Questi nove elementi sono fondamentalmente il nuovo linguaggio che stiamo introducendo chiamato Data Parallel C++ e la sua libreria standard.

Ci sono due librerie di apprendimento, una per le reti neurali e una per le comunicazioni. C'è la libreria che chiamiamo livello zero che è per l'astrazione hardware e ci sono quattro librerie incentrate sul dominio. Lo stiamo facendo in un modo molto, molto aperto. Le specifiche per tutti questi sono già aperte e disponibili. Li chiamiamo versione 0.5. Intendiamo raggiungere la versione 1.0 entro la fine del 2020 e disponiamo anche di implementazioni open source di tutto ciò. Ancora una volta, il nostro obiettivo è consentire alle persone di sfruttare ciò che è già disponibile. Se un fornitore di hardware desidera implementare questo linguaggio, può prendere ciò che è open source ed eseguirlo.

D: Per quanto riguarda algoritmi e implementazione, come funziona?

Quello che stiamo fornendo sono le primitive che gli algoritmi userebbero: le primitive matematiche sottostanti e le primitive di comunicazione. In genere, l'innovazione degli algoritmi sta avvenendo a un livello più alto di quello, in cui non stanno davvero rifacendo la matematica fondamentale, la matematica delle matrici, la matematica delle convoluzioni e così via. Si tratta di capire nuovi modi per usare quella matematica e nuovi modi per usare i modelli di comunicazione. Il nostro obiettivo è davvero quello di fornire il primitivo, il livello zero, in modo che altri possano innovare su di esso.

D: Come funziona a livello hardware?

Se sei un fornitore di hardware, prendiamo una matrice AI, ad esempio qualcuno che costruisce un ASIC AI: ci sono due modi in cui quel fornitore di hardware può "collegarsi" e sfruttare l'ecosistema AI. Uno sarebbe fornire questa interfaccia hardware di basso livello che chiamiamo livello zero e se forniscono la loro versione di livello zero utilizzando l'API standard, possono sfruttare l'open source se lo desiderano, e quindi tutti i livelli software sopra può automaticamente sfruttarlo.

Potrebbe essere difficile per un ASIC focalizzato sul segmento, fornire la piena generalità del livello zero. Quindi, in alternativa a ciò, possono anche fornire i kernel matematici e di comunicazione che sono nel nostro dominio e le librerie di deep learning, e quindi faremo il lavoro di "installare" quelle librerie nei framework di livello superiore, quindi lo otterrebbero automaticamente.

D: Hai menzionato che la versione che hai in questo momento è designata 0.5 e le specifiche complete dovrebbero essere pronte entro la fine del 2020.

Quindi, ci sono due parti nella nostra iniziativa oneAPI. Uno è la parte del settore e uno è i prodotti Intel. La specifica del settore è a 0,5 e verso la metà dell'anno vorremmo portarla a 1,0. Parallelamente, Intel sta creando una serie di prodotti e i prodotti che Intel sta costruendo sono oggi in versione beta e implementano le specifiche 0.5. Entro la fine dell'anno, vorremmo arrivare a un prodotto 1.0.

Il prodotto Intel va oltre i nove elementi di oneAPI perché, oltre agli elementi di programmazione di base che forniamo, vogliamo anche fornire le cose di cui i programmatori hanno veramente bisogno, come debugger, analizzatori e strumenti di compatibilità in modo che migrino dai linguaggi esistenti ai dati Linguaggio C++ parallelo.

D: Quanto è difficile per lo sviluppatore la transizione? L'ambiente più ampio è simile a quello che usano da anni?

Sì, è molto simile. Permettetemi di descrivere un po' Data Parallel C++ perché è una parte importante di ciò che stiamo facendo. DPC++ è tre cose. Si basa sul linguaggio C++ standard internazionale ISO. C'è un gruppo chiamato Khronos che definisce lo standard chiamato SYCL e SYCL è sovrapposto a C++. Prendiamo SYCL e quindi aggiungiamo estensioni sopra SYCL. Il modo in cui stiamo costruendo Data Parallel C++, è davvero solo C++ con estensioni, che è ciò che è SYCL.

Qualsiasi compilatore C++ può compilarlo. La bellezza di DPC++ è che qualsiasi compilatore può compilarlo, solo un compilatore esperto può trarre vantaggio da ciò che è in quel linguaggio e generare codice acceleratore. Il modo in cui stiamo conducendo questo linguaggio, lo stiamo facendo in modo molto, molto aperto, quindi tutte le nostre discussioni su Data Parallel C++ stanno avvenendo con il comitato SYCL. Le implementazioni sono open-source, tutte le estensioni sono già pubblicate e stiamo lavorando con molta, molta attenzione per assicurarci di avere un buon percorso verso i futuri standard SYCL. Guardando verso il basso tra 5-10 anni, anche un percorso di scorrimento verso ISO C++.

D: Per quanto riguarda i compilatori e la migrazione a DPC++, la curva di apprendimento non dovrebbe essere un grosso problema?

Sì, dipende da dove parti, ovviamente. Per un programmatore C++, la curva di apprendimento sarebbe molto piccola. Per un programmatore C, dovresti superare l'ostacolo dell'apprendimento del C++, ma questo è tutto. È molto familiare C++. Per un programmatore abituato a linguaggi come OpenCL, dovrebbe essere molto simile.

L'altra parte che devo sottolineare è che stiamo facendo il lavoro in open source usando l'infrastruttura LLVM. Tutti i nostri sorgenti sono già aperti, c'è un repository Intel GitHub dove puoi andare a guardare l'implementazione del linguaggio, anche scaricare un compilatore open-source. Tutti gli strumenti Intel, le nostre offerte di prodotti che sono beta sono anche disponibili gratuitamente con cui chiunque può giocare e scaricarlo. Abbiamo anche un cloud per sviluppatori disponibile, dove le persone non hanno bisogno di scaricare o installare nulla, possono semplicemente scrivere il codice e iniziare a utilizzare tutti gli strumenti di cui abbiamo parlato.

D: C++ è performante e relativamente semplice, ma sappiamo tutti che sta invecchiando, lo sviluppo è lento, ci sono troppe parti interessate, quindi stanno rallentando tutto. Questo ovviamente non sarebbe il caso con DPC++. Avresti iterazioni e aggiornamenti molto più veloci?

Penso che tu abbia raggiunto un punto molto, molto importante per noi, che è una rapida evoluzione che non è rallentata dagli standard. Quindi, vogliamo condurre le nostre discussioni apertamente con lo standard, quindi c'è un modo per entrare negli standard, ma vogliamo anche farlo rapidamente.

Le lingue funzionano meglio quando sono co-progettate dai loro utenti e implementatori, man mano che le architetture si evolvono. Il nostro obiettivo è la progettazione di codice iterativo davvero veloce in cui ci esercitiamo, troviamo il modo migliore per fare le cose e le rendiamo standard. Quindi, assolutamente, l'iterazione veloce è un grande obiettivo.

D: Una domanda che è stata sollevata da alcuni dei miei colleghi (probabilmente puoi capire che sono in qualche modo preoccupati per l'apertura con qualsiasi cosa proveniente da una grande azienda): DPC++ rimarrà sempre aperto a tutti gli utenti e fornitori?

Assolutamente! La specifica viene eseguita con una licenza Creative Commons. Chiunque può usare la specifica, prenderla e biforcarla se vuole, ed evolverla. Voglio sottolineare che non tutti gli elementi di oneAPI sono open source, ma siamo sulla buona strada per rendere open source quasi tutti gli elementi. Tutto ciò, chiunque può afferrare e sfruttare: è disponibile per l'implementazione.

Codeplay, che è una società con sede nel Regno Unito, ha annunciato un'implementazione Nvidia di DPC++ e stiamo davvero incoraggiando tutti i fornitori di hardware e software a fare il loro port. Siamo a un punto unico nel settore in cui gli acceleratori stanno diventando comuni per più fornitori. Quando ciò accade nella storia, quando c'è un solo fornitore, la loro lingua domina. L'industria del software richiede una soluzione standard e più fornitori.

Quello che stiamo cercando di fare qui è quello che abbiamo fatto circa due decenni e mezzo fa con OpenMP, dove c'erano più linguaggi paralleli ma nessuno veramente dominante. Abbiamo preso tutto questo e l'abbiamo unificato in uno standard che ora, 25 anni dopo, è il modo di programmare per HPC.

D: Sarebbe corretto affermare che DPC++ vedrà molte evoluzioni nei prossimi anni? Che dire dei tensori, e del nuovo hardware in uscita?

Sì, assolutamente, hai ragione. Dobbiamo evolvere il linguaggio per supportare il nuovo hardware in uscita. Questo è l'obiettivo di un'iterazione più veloce. Un altro punto che voglio sottolineare è che stiamo progettando Data Parallel C++ in modo che tu possa anche collegare estensioni specifiche dell'architettura, se lo desideri.

Quindi, sebbene sia un linguaggio standard che vogliamo utilizzare su più architetture, ci rendiamo anche conto che a volte, un pubblico, un pubblico molto importante ha bisogno delle massime prestazioni possibili. Potrebbero voler approfondire la programmazione di livello molto basso che non sarà necessariamente portatile per architettura. Stiamo costruendo estensioni e meccanismi in modo da poter avere estensioni per tensori e così via che sarebbero specifici dell'architettura.

D: Quanto controllo potrebbe avere uno sviluppatore sul codice generato per l'hardware? Quanto controllo possono avere sulla gestione della memoria tra il sistema ei vari acceleratori?

Stiamo prendendo in prestito il concetto di buffer da SYCL, che fornisce un controllo molto esplicito della memoria all'utente, ma in aggiunta a ciò, stiamo aggiungendo anche la nozione di memoria unificata . Il nostro obiettivo è consentire al programmatore il livello di controllo di cui ha bisogno, non solo per gestire la memoria ma per generare codice rapido. Alcune delle estensioni che stiamo aggiungendo su SYCL sono cose come sottogruppi, riduzioni, pipe e così via. Ciò ti consentirà di generare codice molto migliore per diverse architetture.

D: Un punto interessante è la distribuzione oneAPI per Python: Intel ha elencato specificamente NumPy, SciPy, SciKit Learn. Sono curioso del miglioramento delle prestazioni e dei vantaggi in termini di produttività che potrebbero essere sbloccati tramite oneAPI. Hai qualche metrica in merito?

Questa è un'ottima domanda. Stiamo supportando quell'ecosistema. Perché Python dovrebbe voler usare un acceleratore? È per ottenere prestazioni dalle sue librerie matematiche, librerie di analisi. Quello che stiamo facendo è "idraulico" NumPy, SciPy, SciKit Learn, ecc., in modo da poter ottenere buone prestazioni sfruttando le librerie che abbiamo sopra. L'implementazione predefinita di NumPy, SciPy, SciKit Learn e così via, rispetto a quella che è stata integrata correttamente con pacchetti nativi ottimizzati, può vedere guadagni molto, molto grandi. Abbiamo visto guadagni nell'ordine di 200x, 300x, ecc.

Il nostro obiettivo con Python è che vorremmo rientrare in una frazione ragionevole, entro 2x, forse entro l'80% delle prestazioni del codice nativo. Lo stato dell'arte oggi è che sei spesso a 10 volte o più. Vogliamo davvero colmare questo divario regolando tutte le attività ad alte prestazioni in modo che tu sia entro un fattore 2, e in realtà molto più alto di quello.

D: Di quali tipi di hardware stiamo parlando? Gli sviluppatori potrebbero sbloccare questo potenziale su una normale workstation o richiederebbe qualcosa di un po' più potente?

No, sarebbe ovunque. Se pensi da dove viene il guadagno, allora capirai. Le normali librerie Python non utilizzano nessuna delle capacità di virtualizzazione sulle CPU. Non stanno utilizzando nessuna delle funzionalità multi-core sulle CPU. Non sono ottimizzati, il sistema di memoria e tutto ciò che non è ottimizzato. Quindi, si tratta di un moltiplicatore di matrice scritto da un programmatore ingenuo e compilato da un compilatore senza alcuna ottimizzazione, quindi confrontarlo con ciò che scrive un esperto nel codice assembly. Puoi vedere guadagni multi-100x quando confronti questi due, e nel mondo Python, essenzialmente, è quello che sta succedendo.

Gli interpreti Python e le librerie standard sono di così alto livello che il codice che ottieni diventa un codice molto, molto ingenuo. Quando lo esegui correttamente con librerie ottimizzate, ottieni quegli enormi vantaggi. Un laptop ha già da due a sei o otto core CPU, sono multithread e hanno capacità di vettorizzazione abbastanza decenti, forse è 256, forse è 512. Quindi, ci sono molte prestazioni nei laptop e nelle workstation. Quando lo riduci alle GPU, una volta che hai la grafica disponibile, puoi immaginare da dove provengono i guadagni.

Se guardi la nostra grafica integrata, stanno anche diventando molto potenti. Sono sicuro che hai visto Ice Lake Gen 11, dove la grafica integrata è significativamente migliore rispetto alla generazione precedente. Puoi vedere da dove arriverebbero i vantaggi, anche sui laptop.

D: E la disponibilità di DevCloud? Se ricordo bene, al momento è gratuito per tutti, ma rimarrà così dopo che diventerai oro l'anno prossimo?

Questa è una buona domanda. A questo punto, sarò onesto, non so rispondere. La nostra intenzione a questo punto è che sia libero per sempre. È per lo sviluppo, per giocare, e c'è un sacco di potenza lì, quindi le persone possono davvero fare le loro corse.

Q: Quindi, non ti dispiacerebbe se chiedessimo a qualche migliaio di sviluppatori di provarlo?

Oh, assolutamente no. Ci piacerebbe che ciò accadesse!

Posso riassumere quello che stiamo cercando di fare. Innanzitutto, siamo molto, molto entusiasti di oneAPI. È giunto il momento che una soluzione multi-vendor decolli, poiché ci sono più fornitori disponibili sul mercato ora. Se dai un'occhiata alla nostra linea di processori, non solo alle GPU in arrivo, alle GPU integrate sempre più potenti e alla nostra roadmap FPGA, questo è un momento entusiasmante per costruire uno standard per tutto questo. Il nostro obiettivo è la produttività, le prestazioni e l'infrastruttura del settore in modo che tu possa costruirci sopra.

Per quanto riguarda i tre segmenti di pubblico di cui ho parlato, gli sviluppatori di applicazioni possono sfruttare le cose facilmente, poiché sono già disponibili. I fornitori di hardware possono sfruttare lo stack software e collegare il nuovo hardware, mentre i fornitori di strumenti e linguaggi possono utilizzarlo facilmente. Intel non è in grado di creare tutti i linguaggi e tutti gli strumenti del mondo, quindi è un'infrastruttura open source su cui gli altri possono sfruttare e costruire molto facilmente.