Intel e High Performance Computing: MIC contro GPGPU

Intel e High Performance Computing: MIC contro GPGPU

Nel mondo HPC Intel deve iniziare a fronteggiare le crescenti minacce delle soluzioni GPGPU. Ma il colosso di Santa Clara è convinto di poter avere un asso nella manica

di Andrea Bai pubblicata il , alle 14:57 nel canale Server e Workstation
Intel
 

La scorsa settimana abbiamo avuto modo di osservare quale sia l'approccio di Intel allo scenario High Performance Computing, soffermandoci in modo particolare sulla recente introduzione della soluzione Many Integrated Core (MIC) conosciuta con il nome di Knights Ferry e presentata in occasione della Supercomputing Conference di New Orleans.

Su questo tema il sito web HPC Wire ha avuto modo di intervistare Rajeeb Hazra, responsabile del gruppo High Performance Computing per Intel, e di sottolineare interessanti spunti di approfondimento dai quali emerge, come già avevamo avuto modo di scrivere nella notizia precedente, che sarà l'ottimizzazione software il terreno di scontro tra Intel ed i grandi dell'accelerazione GPGPU.

Il confronto con le soluzioni GPGPU è inevitabile: se da un lato le soluzioni MIC sono architetturalmente molto diverse da una GPGPU, dall'altro conservano una serie di importanti affinità in termini di parallelismo e semplicità dei nuclei di elaborazione fondamentali che consentono di arrivare ad un elevato rapporto performance/watt.

L'approccio di Intel è pertanto quello di arrivare ad un livello di performance per watt confrontabile a quello di una soluzione GPGPU ma all'interno dell'ambiente x86. In questa maniera le applicazioni potranno passare da codice single-threaded a codice altamente parallelo senza alcuna variazione del modello sottostante. Sarà impegno di Intel mettere a disposizione compilatori e runtime, oltre a fornire un set di strumenti di sviluppo comuni sia per le soluzioni multicore Xeon sia per le soluzioni MIC. L'obiettivo ultimo è quello di poter ricompliare qualsiasi sorgente x86 in modo tale che possa essere eseguibile su soluzioni MIC.

La visione di Intel si basa sulla considerazione che, seppur anch'essa eterogenea, una piattaforma Xeon-MIC e molto più coerente dal punto di vista del set di istruzioni rispetto ad una piattaforma Xeon-GPGPU dal momento che su entrambi i fronti (CPU e acceleratore HPC) vi è la possibilità di sfruttare le istruzioni x86.

Guardando al futuro, Intel sta portando avanti lo sviluppo della soluzione MIC conosciuta con il nome in codice di Knights Corner, che sarà caratterizzata dalla presenza di 50 core di elaborazione e prodotta con processo a 22 nanometri. Dal momento che presso le fabbriche a 22 nanometri avranno la precedenza i processori destinati al mercato mainstream, è ragionevole supporre che la prima concretizzazione di Knights Corner apparirà sul mercato non prima del 2012.

Intel continuerà a seguire lo sviluppo delle soluzioni Xeon multicore, destinando tali processori a quegli ambiti dove l'accelerazione many-core non è necessaria: impieghi enterprise e soluzioni HPC "di massa". Lo sviluppo delle soluzioni Xeon continuerà ad essere portata avanti con il consueto modello tick-tock a cadenza annuale (ovvero la riduzione del processo produttivo negli anni dispari seguita dall'aggiornamento architetturale negli anni pari) che viene impiegata anche per i processori x86 destinati al mercato mainstream.

Al contrario, il percorso di sviluppo delle soluzioni MIC non seguirà, a quanto pare, la cadenza tick-tock: Intel dovrebbe mettere in atto un ciclo di aggiornamento più lungo, di 18 o addirittura 24 mesi, dove ad ogni aggiornamento di processore vi saranno comunque variazioni architetturali di una certa importanza. Il ciclo di aggiornamento 18-24 va a sincronizzarsi strettamente con il passo tenuto da NVIDIA e AMD per lo sviluppo delle proprie soluzioni GPGPU.

Non è un caso che Intel tenga nel mirino le soluzioni GPGPU dei due colossi della grafica: nel corso del mese di Ottobre il supercomputer Tianhe-1A ha conquistato la prima posizione della lista Top500, la classifica dei 500 più veloci supercomputer del pianeta. Tianhe-1A è un supersistema ibrido CPU-GPU e, come questo, altri 28 supersistemi ibridi sono presenti nei primi 100 supercomputer del mondo. Per il colosso di Santa Clara risulta quindi particolarmente strategico poter realizzare un acceleratore HPC in grado di competere con le proposte GPGPU di AMD e NVIDIA se non vuole essere relegata, in questi ambiti, al ruolo di comprimario nei supersistemi del futuro.

14 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
homero07 Dicembre 2010, 15:12 #1

questa è bella!

la HPC con istruzioni x86!!! della serie W i brevetti!!!
finalmente ci stiamo liberando delle istruzioni x86!!!
WarDuck07 Dicembre 2010, 15:38 #2
Originariamente inviato da: homero
la HPC con istruzioni x86!!! della serie W i brevetti!!!
finalmente ci stiamo liberando delle istruzioni x86!!!


http://www.top500.org/lists/2010/11

Guarda che CPU usano i primi 5 supercomputers del mondo
coschizza07 Dicembre 2010, 15:49 #3
Originariamente inviato da: homero
la HPC con istruzioni x86!!! della serie W i brevetti!!!
finalmente ci stiamo liberando delle istruzioni x86!!!


brevetti per cosa ? mica devi pagare il brevetto per comprare una cpu x86.
Liberando delle istruzioni x86 per usare? e che vantaggio?.

Comuqnue ci siamo gia liberati delle istruzioni x86 sul HPC perche loro usano unicamente le estensioni a 64bit che non sono propriamente x86.
coschizza07 Dicembre 2010, 15:53 #4
Originariamente inviato da: WarDuck
http://www.top500.org/lists/2010/11

Guarda che CPU usano i primi 5 supercomputers del mondo


esatto, dei 500 sistemi in classifica SOLO 450 usano cpu x86, e sono in aumento.
blackshard07 Dicembre 2010, 18:41 #5
Originariamente inviato da: coschizza
esatto, dei 500 sistemi in classifica SOLO 450 usano cpu x86, e sono in aumento.


Ma le usano come controllo, i calcoli li dovrebbero fare altri processori.
WarDuck07 Dicembre 2010, 18:47 #6
Originariamente inviato da: blackshard
Ma le usano come controllo, i calcoli li dovrebbero fare altri processori.


http://www.top500.org/stats/list/36/procfam
frankie07 Dicembre 2010, 19:21 #7
quello che mi chiedo io è:
Ha senso utilizzare 50 mini core x86 al posto dei 6-8-12 core fisici?

Sempre x86 sono, mi sembra un po' un controsenso sto MIC.
Pleg07 Dicembre 2010, 19:25 #8
"In questa maniera le applicazioni potranno passare da codice single-threaded a codice altamente parallelo senza alcuna variazione del modello sottostante."

Ma questo non e' particolarmente significativo: chissenefrega di non cambiare il modello sottostante se devi cambiare il modello soprastante?

Voglio dire: si' il compilato sara' x86 come il resto, ma devi comunque riscrivere il programma per sfruttare multithreading e unita' vettoriali, o pregare che il compilatore lo faccia per te (non banale). Quindi che alla fine venga prodotto x86 (e non solo, se quella roba deriva da LArrabee sara' x86 + LArrabee New Instructions, che lo rende incompatibile con processori x86 normali), che grandi vantaggi ha?
blackshard07 Dicembre 2010, 21:07 #9
Originariamente inviato da: WarDuck


Si ok, ma non vedo architetture eterogenee. Da quello che sentivo dire, tanti gflops arrivano da processori vettoriali (tipo cell o GPGPU). Per esempio, lì non vedo questo qui:

http://en.wikipedia.org/wiki/IBM_Roadrunner

che nel novembre 2008 era al top:

http://www.top500.org/lists/2008/11

e che monta opteron + cell.

Questo pure è un'architettura eterogenea, con CPU intel e GPU amd, immagino però finisca nella categoria degli x86 intel.
avvelenato08 Dicembre 2010, 12:31 #10
Originariamente inviato da: Pleg
"In questa maniera le applicazioni potranno passare da codice single-threaded a codice altamente parallelo senza alcuna variazione del modello sottostante."

Ma questo non e' particolarmente significativo: chissenefrega di non cambiare il modello sottostante se devi cambiare il modello soprastante?

Voglio dire: si' il compilato sara' x86 come il resto, ma devi comunque riscrivere il programma per sfruttare multithreading e unita' vettoriali, o pregare che il compilatore lo faccia per te (non banale). Quindi che alla fine venga prodotto x86 (e non solo, se quella roba deriva da LArrabee sara' x86 + LArrabee New Instructions, che lo rende incompatibile con processori x86 normali), che grandi vantaggi ha?


penso che alla fine intel punti su compilatori altamente specializzati nel riconoscere codice parallelizzabile: non sarà banale ma neanche impossibile, i compilatori già oggi creano ottimizzazioni molto spinte.
Potrebbero certo non essere ottimizzazioni "definitive" come quelle ricavabili attraverso un progetto scritto ad-hoc con l'architettura in mente e un team skillato su architetture ad elevato parallelelismo, però pensaci:
le soluzioni gpgpu ti impongono di riarchitetturare il software per poter girare ottimalmente;
la soluzione intel ti propone di scegliere tra rifare da zero il software, con un notevole guadagno prestazionale, oppure semplicemente ricompilarlo e lasciare l'onere dell'ottimizzazione al compilatore: potrebbe anche non essere efficiente come un'ottimizzazione fatta da esseri umani, ma ne ricaverebbe comunque un boost prestazionale, e tutto questo risparmiando soldi e tempi di messa in esercizio (quindi altri soldi).
Questa flessibilità potrebbe far gola a molte aziende quando si tratterà di scegliere tra mic e gpgpu.

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^