Intel e High Performance Computing: MIC contro GPGPU

[Redazione di Hardware Upg]

Link alla notizia: http://www.businessmagazine.it/news/...gpu_34688.html

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

Click sul link per visualizzare la notizia.

[homero]

la HPC con istruzioni x86!!! della serie W i brevetti!!!
finalmente ci stiamo liberando delle istruzioni x86!!!

[WarDuck]

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

[coschizza]

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.

[coschizza]

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.

[blackshard]

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.

[WarDuck]

Originariamente inviato da blackshard

Ma le usano come controllo, i calcoli li dovrebbero fare altri processori.

http://www.top500.org/stats/list/36/procfam

[frankie]

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.

[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?

[blackshard]

Originariamente inviato da WarDuck

http://www.top500.org/stats/list/36/procfam

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.

[avvelenato]

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.

[LMCH]

Originariamente inviato da avvelenato

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.

Già, la soluzione MIC di Intel nella sostanza è un set d'istruzioni incompatibile con quello degli x86 attuali ma che permette di ricompilare abbastanza agevolmente il codice x86 su di essa e di portare i vari S.O. su di essa abbastanza agevolmente.
Il core x86 "di base" è lo stesso, ma quello che erano le SSE "non c'è più" (sono state sostituite dalle istruzioni della "nuova" VPU).
Visto che le parti che contengono istruzioni SSE o le ha generate automaticamente il compilatore oppure sono spezzoni di codice "piccoli" relativamente facili da riscrivere (e spesso con un fallback su codice x86 oppure C/C++ per supportare i vecchi x86 che non avevano le SSE), la cosa è sensata.

Intel potrà proporre i chip su architettura MIC sia per macchine "multicore" tipo server che per architetture HPC in cui le prestazioni aggiuntive dovute alle VPU dei core si faranno sentire di più (avrà quindi anche maggiori economie di scala rispetto ai concorrenti).

L'unica cosa che potrebbe scombinare le carte ad Intel sarebbe qualche sviluppo (es: le interconnessioni ottiche on-chip) che renderesse più efficienti soluzioni basate su molti più "mini-core" (senza VPU e con cache più piccole).
Uno dei motivi per cui MIC o cpugpu hanno senso è che con le tecnologie attuali molti più core "più piccoli" non possono essere sfruttati a dovere a causa dei limiti di banda sulle interconnessioni tra core e core e tra i core e la memoria esterna, ma se le cose cambiassero ...

[coschizza]

Originariamente inviato da blackshard

Ma le usano come controllo, i calcoli li dovrebbero fare altri processori.

Quindi un supercomputer con 50.000 cpu intel xeon e niente altro dentro usa le cpu come controllo.

E i calcoli chi li fa? E per controllare cosa?

[coschizza]

Originariamente inviato da blackshard

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

le architetture eterogenee sono il futuro nel presente sono usate in una piccola percentuale dei sistemi in elenco compreso nella 1° posizione.

[coschizza]

Originariamente inviato da frankie

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.

ti sei risposto dasolo 50 > 12 > 8 > 6

le cpu moderne sono estremamente potenti ma spesso sono esageratamente complesse per far girare del codice che avrebbe bisogno di una complessita molto minore. Quindi avere cpu standard x86 piu semplici come degi atom ma munite di unita sse o vmx vettoriali avanzate è molto meglio di avere anche 50 core completi ma con solo 1 unita vettoriale avanzata ciascuno. Questo perche i 50 core semplici occupano magari 1/10 dello spazio dei 50 core completi.

Immagina di fare un calcolo del tipi A+B=C, cosa ti serve avere dei core completi se potresti farlo su cpu 100x piu piccole e semplificate.


Una volta esisteva la gara dei GHZ ma siamo arrivati a un limite ora siamo nella gara dei core ma arriveremo a un limite e quindi si arriva alla gara dei mini core per continuare a evolvere i pc.