Un’intervista con James Reinders di Intel – EEJournal

Intel sta puntando molto sui miglioramenti dei processi dei semiconduttori, sulla costruzione di nuovi stabilimenti e impianti di produzione in tutto il mondo, sulle nuove tecnologie di confezionamento e persino sul software. Una di queste scommesse, o forse un gruppo di scommesse, è oneAPI e Data Parallel C++ (DPC++), che sono un modello di programmazione aperto e multiarchitettura che consente agli sviluppatori di utilizzare una singola base di codice su più architetture e una variante di programmazione parallela di C/C++ basato su Khronos SYCL. Queste scommesse sono progettate per rendere più facile per gli sviluppatori di software creare codice relativamente portatile per sistemi basati su architetture informatiche eterogenee.

James Reinders è tornato di recente in Intel dopo un’assenza di quattro anni. In precedenza ha trascorso 27 anni in Intel e ha una tonnellata di esperienza nell’elaborazione parallela alle spalle. È l’autore del libro intitolato “Data Parallel C++: padronanza di DPC++ per la programmazione di sistemi eterogenei utilizzando C++ e SYCL”, che puoi scaricare gratuitamente facendo clic sul collegamento.

Di recente ho passato un’ora a intervistare Reinders e ha trattato una vasta gamma di argomenti. Ecco una versione modificata delle sue opinioni su un insieme selezionato di quegli argomenti relativi all’elaborazione parallela e al calcolo eterogeneo.

Una API e SYCL:

“Sia oneAPI che SYCL sono strumenti fondamentali che condividono una visione dell’elaborazione accelerata basata su specifiche aperte e progetti aperti. Sia oneAPI che SYCL devono soddisfare le esigenze di più fornitori e più architetture. Non solo le esigenze di un fornitore. Non solo GPU, CPU o FPGA. Gli strumenti devono essere aperti nella misura massima che possiamo capire come renderli aperti, perché questi linguaggi e ambienti di programmazione ti offrono una base ad alte prestazioni per tutto il resto che fai.”

Su Python rispetto a C/C++ o DPC++ sotto oneAPI

“Python è in gran parte scritto in C. Anche le librerie di chiavi sono scritte in C, quindi non è che ignori Python quando sviluppi oneAPI. Se ottieni le basi giuste, accadono altre cose buone. OneAPI dice: “Ehi, i linguaggi C o C++ non sono il mondo intero. Hai bisogno di biblioteche. Hai bisogno di strumenti. Hai bisogno di altre lingue”. Quindi oneAPI è una specie di nome generico non solo per le lingue, ma per tutte le altre cose di cui hai bisogno per sviluppare software per l’elaborazione eterogenea”.

Su “Golden Age of Computers” di David Hennessy e John Patterson

“David Hennessy e John Patterson sono leggende nel nostro settore. Ogni volta che hanno parlato in pubblico negli ultimi quattro anni, hanno discusso di una nuova età dell’oro dell’architettura dei computer. La versione che di solito indico di più è l’articolo che hanno inserito in Communications of the ACM all’inizio del 2019, in cui fanno un ottimo lavoro nel discutere la progressione delle architetture dei computer nel tempo e finiscono con la risposta. Dicono che stiamo entrando in una nuova età dell’oro dell’architettura dei computer in cui le architetture specifiche di dominio (DSA) specializzate sono sempre più utilizzate per accelerare i carichi di lavoro e ottenere prestazioni migliori per watt, il che è una preoccupazione trainante per alcuni problemi. OneAPI è progettato per gestire quei DSA in un ambiente di programmazione unificato”.

Su Chiplets e UCIe:

“Se guardi solo al portafoglio di Intel, abbiamo tutti i tipi di capacità di accelerazione. Mettiamo acceleratori hardware specializzati sullo stesso dado con i nostri processori. Abbiamo le GPU. Abbiamo gli FPGA. Abbiamo Gaudi, che è ottimizzato per il deep learning. Abbiamo ASIC blockchain e progetti di ricerca che includono il lavoro sull’elaborazione neuromorfica e sulla grafica, e questo è solo Intel. Vai più ampiamente nel settore e vedi ancora più diversità.

“Ciò che mi porta davvero a casa tutto questo è l’uso imminente di UCIe, l’Universal Chiplet Interconnect Express. Sai, ai vecchi tempi collegavamo le schede PCIe per inserire diverse funzioni nei computer, comprese le schede audio e alcuni dei primi acceleratori grafici. L’idea era che se si voleva avere un acceleratore o qualcosa che svolgesse una funzione specializzata, anche una scheda audio, lo si inserisse in uno slot della scheda madre.

“Ora la domanda è quando stai accumulando chip, cosa fai? Non ci sono slot. Sempre più spesso i nostri progetti sono dispositivi multichip realizzati con chiplet o tile. [Intel’s top-of-the-line GPU] Ponte Vecchio è realizzato con un numero folle di chiplet, con 47 tessere attive. Come fai a far dialogare tutte quelle tessere quando provengono da fornitori diversi?

“Puoi standardizzare il modo in cui parlano tra loro. C’è stato un po’ di questo fatto ad hoc. Sai, Intel aveva una SKU qualche tempo fa in cui abbiamo accoppiato un processore con una GPU AMD. Ovviamente, qualcuno aveva concordato su come questi dispositivi avrebbero parlato tra loro. Questo è un motivo naturale per creare uno standard.

“Diciamo che Intel ha una CPU Xeon che utilizza questo standard. Qualche altra azienda, forse una startup, può sviluppare un piccolo chiplet che fa qualcosa di molto specifico. Se anche quel chiplet utilizza quello standard, improvvisamente quella società di avvio può semplicemente chiedere a Intel di incollare il proprio chiplet alla CPU Xeon nello stesso pacchetto. È quindi possibile inserire la CPU Xeon aumentata in una scheda madre standard che è possibile ottenere da Dell o da un altro fornitore. Ecco a cosa serve UCIe.

“Ci sono vantaggi immediati in questa capacità. Non è necessario progettare un nuovo sistema o scheda madre. Devi semplicemente distribuire la CPU aumentata in un sistema esistente.

“E poi la domanda è: quanto è difficile inserire il software in un sistema come questo? Se gli strumenti software sono pronti per questo tipo di architettura multi-vendor e se questi strumenti includono il compilatore, le librerie e gli strumenti di analisi delle prestazioni, allora è molto più semplice sviluppare software per questo tipo di architettura aumentata. La barriera all’ingresso del software è ridotta. La barriera all’ingresso dell’hardware diminuisce a causa del passaggio ai chiplet e all’adozione di un’interconnessione chiplet standard. Si arriva sul mercato molto più rapidamente”.

Sull’acquisizione di Codeplay da parte di Intel

“La società Codeplay è diventata disponibile e Intel ha deciso di acquisirli. Sono rimasto basito. Ho lavorato con le persone di Codeplay e mi è piaciuto lavorare con loro. Lavorano da tempo su GPU Nvidia e AMD ma, come azienda commerciale, erano sempre alla ricerca di qualcuno che sottoscrivesse il loro lavoro. Un cliente lo vorrà? Alcuni dei laboratori a volte davano loro denaro iniziale, ma non abbastanza per produrre completamente il loro lavoro. Esito un po’ a dire “assegno in bianco”, ma essenzialmente ora hanno un assegno in bianco da Intel per produrre il loro lavoro e non devono preoccuparsi che qualcun altro lo paghi. Dovresti vedere i risultati di questa acquisizione entro la fine dell’anno.

“Vedrai che i loro strumenti si integrano con le versioni Intel di SYCL in modo che SYCL/DPC++ finisca per essere in grado di indirizzare tutte le GPU di Intel, Nvidia e AMD. Le persone esperte potrebbero creare questo tipo di software utilizzando strumenti open source nell’ultimo anno. Ma ammettiamolo, la maggior parte di noi vuole essere il più pigro possibile. Mi piace davvero poter scaricare un binario con un clic, installarlo e farlo funzionare, invece di costruirlo da file open source e leggere molte istruzioni per trasformare i file in strumenti utilizzabili.

“Stiamo anche affidando la gestione della community oneAPI a Codeplay e loro la trasformeranno in qualcosa che è guidato dal settore. Diciamo che è guidato dal settore, ma Intel ha dovuto tenere la penna molto saldamente per far sì che l’industria la guidasse. Ora Codeplay condurrà lo spettacolo per aiutare la transizione al pieno controllo del settore.

Sull’acquisizione di ArrayFire da parte di Intel

“Sai, Codeplay impiega quasi 100 ingegneri. ArrayFire ne ha quattro. Quindi, l’acquisizione di queste due società è diversa da questo punto di vista. Ma le persone di ArrayFire sono molto talentuose e ovviamente hanno una storia profonda con le aziende, con la tecnologia. Sono dei veri pionieri. In effetti, potresti aver visto che ho pubblicato un piccolo blog la scorsa settimana menzionando l’acquisizione di ArrayFire. (Vedere “Il team ArrayFire si unisce a Intel per oneAPI.”)

“Quando ho incontrato Giovanni [Melonakos, CEO & Co-Founder of ArrayFire] la settimana prima di pubblicare il blog, gli ho chiesto di scrivere qualcosa sull’acquisizione e quello che ha scritto è stato davvero modesto. Ho detto: “Oh mio Dio! Ragazzi siete dei pionieri. Abbiamo bisogno di qualcosa di più di questo!” John è d’accordo, quindi ho aggiunto alcune parole sul lavoro pionieristico di ArrayFire perché sono estremamente innamorato delle cose che hanno fatto. Siamo super entusiasti di averli a bordo.

“Solo perché tu lo sappia, i ragazzi di ArrayFire hanno sviluppato molte cose che alla fine sono diventate i toolkit paralleli e gli strumenti correlati in MATLAB. Lo hanno venduto o concesso in licenza quegli strumenti e quindi hanno creato una libreria di intrinseci GPU portatili che sono davvero facili da usare. Questi elementi intrinseci funzionano solo sulle GPU di chiunque. Quindi, stavano risolvendo il problema della scrittura di codice per le GPU senza scrivere quel codice [Nvidia’s] CUDA, in modo che gli sviluppatori di software possano sfruttare la GPU di chiunque. Alcuni ricercatori di Facebook hanno utilizzato gli elementi intrinseci di ArrayFire per sviluppare codice per l’apprendimento automatico e hanno ottenuto fantastici accelerazioni. Il loro codice ha funzionato meglio dell’implementazione CUDA, che è una vera testimonianza dei ragazzi di ArrayFire. Capiscono davvero come ottimizzare le prestazioni della GPU. Qualsiasi GPU.”

Sul futuro di oneAPI

“Vedo un paio di grandi passi avanti per oneAPI nei prossimi anni. Prima di tutto, dobbiamo dimostrare che oneAPI funziona per Intel. Abbiamo fatto un ottimo lavoro dimostrando che un’API fa un ottimo lavoro sulle nostre CPU e sui nostri FPGA. Tutti stanno aspettando [support for] il [Intel] GPU Ponte Vecchio e suoi successori. Succederà. Nascere una nuova architettura è sempre doloroso, non importa quanto diciamo che non lo sarà. Ci sono passato più di un paio di volte, quindi penso che sarà davvero eccitante. Sono davvero entusiasta di quello che farà Ponte Vecchio.

“Ma dimostrare che oneAPI soddisfa davvero le esigenze di Intel e le esigenze dei clienti di Intel su tutta la linea è la prima grande sfida. La prossima sfida è dimostrare che oneAPI funziona bene per altre architetture. Quindi, le cose che ho menzionato su Codeplay, per quanto riguarda il supporto Nvidia e AMD… nei prossimi due anni, vedrai pubblicati alcuni risultati interessanti. Pubblicheremo più risultati quest’anno, ma nel corso dei prossimi due anni, penso che si arriverà al punto in cui diventerà una comprensione comune che un’API è fattibile per gli sviluppatori di software che prendono di mira più architetture da più fornitori. In questo momento, ci sono molte prove per questo aneddoticamente, con i primi utenti che hanno pubblicato molti articoli accurati negli ultimi anni che mostrano risultati positivi, ma non è ancora una conoscenza comune. Penso che tra circa due anni diventerà di dominio pubblico. Questa è la mia aspettativa.

“Quindi questo è il livello alto. Che diavolo è oneAPI? Lo vedrai all’evento Intel Innovation. Spostare lo sviluppo e il supporto di oneAPI in Codeplay è il passo successivo nell’evoluzione degli standard. Penso che Intel abbia fatto un ottimo lavoro dando vita a oneAPI, ma ora ha bisogno di ulteriore aiuto, quindi Intel deve lasciar perdere un po’. Sto aiutando Intel a farlo e incoraggiando il settore a dirci cosa è più importante per guidare oneAPI in avanti da qui”.

Leave a Comment

Your email address will not be published. Required fields are marked *