Knights Landing è la futura GPU Intel per il calcolo parallelo

Knights Landing è la futura GPU Intel per il calcolo parallelo

Anticipate alcune delle caratteristiche tecniche delle soluzioni Xeon Phi della famiglia Knights Landing: oltre 60 core della famiglia Silvermont, la nuova interconnessione Omni Scale Fabric e memorie on package

di Paolo Corsini pubblicata il , alle 16:03 nel canale Server e Workstation
Intel
 

Anche Intel non manca con importanti novità annunciate in concomitanza con l'International Supercomputing Conference che si sta svolgendo in questi giorni a Lipsia. Per l'azienda americana parliamo di soluzioni per l'HPC, con le proposte Xeon Phi note con il nome in codice di Knights Landing che sono al centro dell'attenzione.

knights_landing_2.jpg (77485 bytes)

La principale novità di queste proposte riguarda l'utilizzo della Omni Scale Fabric, una nuova tecnologia di interconnessione che sarà presente nella nuova generazione di proposte Xeon Phi e che verrà adottata anche nei futuri processori Xeon tradizionali. L'interconnessione Omni Scale Fabric è integrata nel chip a livello di die, offrendo immediati benefici a livello di latenza e velocità di trasferimento dei dati.

Intel Omni Scale è stato progettata e ottimizzata dall'azienda americana per la prossima generazione dell'HPC, basato su una combinazione di proprietà intellettuali (IP) acquisite da Cray e QLogic oltre che da innovazioni interne di Intel. A livello di codice è compatibile con le installazioni attuali, basate su fabric Intel True Scale: questo permette agli amministratori di sistema di migrare codice da una piattaforma all'altra senza doversi preoccupare di eventuali incompatibilità lato codice.

knights_landing_1.jpg (105926 bytes)

Altra importante caratteristica delle soluzioni Knights Landing riguarda la presenza di memoria di tipo on package, montata quindi direttamente sullo stesso package del chip. Intel ha sviluppato questo design in collaborazione con Micron, ottenendo un valore di bandwidth pari a 5 volte quella delle memorie DDR4 con un aumento di 5 volte dell'efficienza energetica, una riduzione dell'ingombro a 1/3 e la possibilità di integrare da subito sino a 16 Gbytes di memoria. Per ambiti HPC, molto sensibili in termini prestazionali alle caratteristiche della memoria abbinata alla GPU, si tratta di specifiche tecniche molto interessanti.

Le soluzioni Knights Landing adotteranno tecnologia produttiva a 14 nanometri e per questo motivo debutteranno sul mercato nel corso della seconda metà del prossimo anno. Queste architetture saranno proposte da Intel sia in versione socket tradizionale, da installare sulla scheda madre, sia montate su scheda PCI Express come una tradizionale scheda video a seconda delle specifiche necessità del cliente.

Intel ha dichiarato per Knights Landing l'integrazione di oltre 60 core della famiglia Silvermont, specificamente ottimizzati per utilizzi in ambiti HPC, per una potenza di calcolo attesa superiore a 3 TeraFLOPS in double precision, oltre che di 3 volte superiore a quella delle attuali proposte Xeon Phi con elaborazioni in single precision. La peculiarità di Knights Landing è legata alla compatibilità con le CPU Xeon a livello di codice binario delle APP: per gli sviluppatori sarà quindi possibile spostare software sviluppato per CPU su Knights Landing in modo molto semplice.

70 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
Kino8724 Giugno 2014, 19:02 #1
Ho dei seri dubbi sia corretto chiamarle gpu, sono schede (se di scheda si parla e non del chip da inserire direttamente su mobo) acceleratrici per calcolo parallelo, non hanno ne le componenti ne le funzionalità di una gpu.

Detto questo: ma queste soluzioni si usano già o sono ancora dei kit distribuiti più che altro agli sviluppatori per fargli prendere dimestichezza con architettura e api come per le prime versioni?
AceGranger24 Giugno 2014, 19:12 #2
Originariamente inviato da: Kino87
Ho dei seri dubbi sia corretto chiamarle gpu, sono schede (se di scheda si parla e non del chip da inserire direttamente su mobo) acceleratrici per calcolo parallelo, non hanno ne le componenti ne le funzionalità di una gpu.

Detto questo: ma queste soluzioni si usano già o sono ancora dei kit distribuiti più che altro agli sviluppatori per fargli prendere dimestichezza con architettura e api come per le prime versioni?



se intendi queste nuove versioni credo che siano in mano agli sviluppatori, gli Xeon PHI prima serie invece sono tranquillamente acquistabili.


piu che altro vorrei capire se una volta montate sei socket la ram si somma a quella di sistema e diventa unica o se rimane separata, perchè le Xeon PHI attuali su PCI-EX hanno lo stesso problema delle GPU che devono caricare il tutto nella ram della GPU, niente memoria condivisa :/
massimo79m24 Giugno 2014, 19:29 #3
ram su cpu? paura!
devil_mcry24 Giugno 2014, 19:36 #4
Questa soluzione fa davvero paura
Genera più TeraFlops della metà di schede video di fascia medio alta, credo che sia sui livelli di una GTX 770 ed equivalente AMD (prendo le GPU a campione per ovvi motivi)

In un'altra news leggevo che in teoria tutta questa potenza non necessita nemmeno di una revisione del codice (immagino codice comunque scritto per le precedenti versioni di questa scheda).

Davvero tanta roba
AceGranger24 Giugno 2014, 20:39 #5
Originariamente inviato da: devil_mcry
Questa soluzione fa davvero paura
Genera più TeraFlops della metà di schede video di fascia medio alta, credo che sia sui livelli di una GTX 770 ed equivalente AMD (prendo le GPU a campione per ovvi motivi)


no no, qui si parla di 3 TeraFlops Double Precision che è ancora piu paura

la FirePro Top gamma S10000 con 2 chip Thaiti fa 1,48 TFlops
la Quadro Top gamma K6000 fa 1,7 TFlops

Originariamente inviato da: devil_mcry
In un'altra news leggevo che in teoria tutta questa potenza non necessita nemmeno di una revisione del codice (immagino codice comunque scritto per le precedenti versioni di questa scheda).

Davvero tanta roba


ancora meglio, è riferito al codice X86 classico; queste "GPU" hanno i core che sono X86; quindi basta poco per adattare il classico codice X86 a queste schede; deve solo esserci software/calcolo che si presta bene ad essere parallelizzato.

nella prima versione di queste schede erano i core del chip erano i vecchi core del Pentium originale modificati, questa nuova versione sara basata su un massimo di 72 core Silvermont ( gli attuali Atom Bay trail ) modificati per gestire 4 thread per core

EDIT

sara un mostro di potenza controller SIX-CHANNEL DDR4 2400 Up to 384 GB di RAM

http://www.extremetech.com/extreme/...-supercomputing
devil_mcry24 Giugno 2014, 20:56 #6
Non avevo letto che era in doppia precisione, davvero un mostro niente da dire.

Non vedo l'ora di leggere qualcosa di più approfondito e magari qualche test.
cdimauro24 Giugno 2014, 22:59 #7
Originariamente inviato da: Kino87
Ho dei seri dubbi sia corretto chiamarle gpu, sono schede (se di scheda si parla e non del chip da inserire direttamente su mobo) acceleratrici per calcolo parallelo, non hanno ne le componenti ne le funzionalità di una gpu.

Infatti non lo sono.
Detto questo: ma queste soluzioni si usano già o sono ancora dei kit distribuiti più che altro agli sviluppatori per fargli prendere dimestichezza con architettura e api come per le prime versioni?

A livello di API credo che non dovrebbe cambiare molto rispetto agli attuali Knights Corner, dunque tutto il software già scritto dovrebbe girare tranquillamente.

Comunque per prendere confidenza con lo sviluppo di software per Xeon Phi non ti serve necessariamente avere la scheda o il computer: puoi scrivere codice che gira automaticamente sulla CPU nel caso in cui non venga trovato alcun sistema Xeon Phi. In questo modo puoi già lavorare al codice vero e proprio, e sfruttare le schede o il computer non appena le avrai, senza dover toccare più niente.
Originariamente inviato da: AceGranger
piu che altro vorrei capire se una volta montate sei socket la ram si somma a quella di sistema e diventa unica o se rimane separata, perchè le Xeon PHI attuali su PCI-EX hanno lo stesso problema delle GPU che devono caricare il tutto nella ram della GPU, niente memoria condivisa :/

Con Xeon Phi può già mappare in maniera trasparente la memoria di CPU e Xeon Phi in modo che siano condivise. Per essere chiari, puoi, ad esempio, dichiarare un vettore e mapparlo in memoria allo stesso indirizzo sia sulla CPU sia su Xeon Phi. Si occuperà poi il runtime di Xeon Phi a sincronizzare opportunamente le rispettive memoria locali.

Se la CPU scrive qualcosa nel vettore, ad esempio, le modifiche verranno ricopiate nella scheda (o nelle, se le schede/sistemi sono più d'una) memoria di Xeon Phi, in modo che sia CPU sia Xeon Phi abbiano sempre dei dati coerenti.

Questo particolare modello di sviluppo per Xeon Phi (ce ne sono diversi, a seconda del linguaggio e degli obiettivi) si chiama MYO. Qui trovi informazioni sulle diverse possibilità di sviluppo.

La cosa interessante di MYO è che consente di scambiare velocemente strutture dati anche molto complesse (es: grafi) senza che sia necessaria alcun marshalling per lo scambio di dati (come avviene, invece, per altre modalità di sviluppo / funzionamento, o normalmente con altre architetture GPGPU o GPU).

Comunque se hai già del codice esistente lo puoi convertire velocemente e in maniera molto semplice per sfruttare Xeon Phi, usando delle apposite direttive (#pragma). Oppure Intel mette a disposizione una libreria di funzioni matematiche (MKL) molto usate in ambito scientifico, e che sono già ottimizzate per sfruttare automaticamente Xeon Phi.

Questo è tutto, se il discorso che facevi sulla memoria integrata in Xeon Phi riguardava la condivisione di dati fra CPU e Xeon Phi. Altrimenti dovresti chiarire meglio lo scenario di cui parlavi.
Originariamente inviato da: devil_mcry
In un'altra news leggevo che in teoria tutta questa potenza non necessita nemmeno di una revisione del codice (immagino codice comunque scritto per le precedenti versioni di questa scheda).

Originariamente inviato da: AceGranger
ancora meglio, è riferito al codice X86 classico; queste "GPU" hanno i core che sono X86; quindi basta poco per adattare il classico codice X86 a queste schede; deve solo esserci software/calcolo che si presta bene ad essere parallelizzato.

Rispondo a entrambi. A differenza di Knights Corner, Knights Landing mette a disposizione dei core perfettamente compatibili con IA-32, per cui possono far girare qualunque codice per IA-32 o Intel64/x64 senza alcuna modifica.

Quindi è possibile installare qualunque s.o. e utilizzare qualunque software già esistente, e se questo supporta già adeguatamente la programmazione parallela (multicore/thread) trarrà automaticamente beneficio della moltitudine di core / thread hardware a disposizione (con 72 core fisici ci sono 288 thread hardware).

Questo, però, non consente di sfruttare pienamente la potenza di calcolo che Knights Landing mette a disposizione (in particolare il set d'istruzioni AVX512). Per fare, però, è sufficiente una ricompilazione con un compilatore che generi codice apposito per questa ISA.
nella prima versione di queste schede erano i core del chip erano i vecchi core del Pentium originale modificati, questa nuova versione sara basata su un massimo di 72 core Silvermont ( gli attuali Atom Bay trail ) modificati per gestire 4 thread per core

Sì, e quindi dovrebbe esserci un notevole aumento prestazionale, similmente a quello ottenuto passando dalla vecchia architettura Atom in-order a quella out-of-order. Anzi, considerato che Xeon Phi utilizzava la vecchia architettura Pentium (adattata), e quindi non erano presenti i diversi miglioramenti presenti in quella Atom in-order, il guadagno a livello prestazionale dovrebbe essere decisamente maggiore.

Comunque aspettiamo i primi benchmark per avere qualche dato concreto.
AceGranger24 Giugno 2014, 23:40 #8
Originariamente inviato da: cdimauro
Questo è tutto, se il discorso che facevi sulla memoria integrata in Xeon Phi riguardava la condivisione di dati fra CPU e Xeon Phi. Altrimenti dovresti chiarire meglio lo scenario di cui parlavi.



premesso che non sono un programmatore e ce l'ho fatta a seguirti solo fino a un certo punto e poi il resto tutto arabo ....

quello che ho scritto prima faceva riferimento a quello che mi è capitato l'anno scorso:
ad un evento di grafica dove era presente il creatore di Vray che stava presentando in anteprima Vray 3.0, durante la pausa, ho avuto modo di fargli direttamente 2 domande:

1 - Vray supportera gli Xeon PHI ?
2 - gli Xeon PHI hanno lo stesso problema delle GPU che sono limitate dal quantitativo di ram visto devono caricare tutta la scena 3D in ram ?

le sue risposte sono state.

1 - c'è gia un team di sviluppo che sta testanto gli Xeon PHI, ma abbiamo il problema che quando renderizzano al 100% vanno il protezione termica
2 - si attualmente si

ora non so se quello che hai scritto tu cozza con quello che mi ha detto lui o se potrebbe anche esserci l'eventualita di avergli posto male la domanda con conseguente risposta intesa male da me ( ...non è stata una conversazione in italiano... )
cdimauro25 Giugno 2014, 06:42 #9
Originariamente inviato da: AceGranger
premesso che non sono un programmatore e ce l'ho fatta a seguirti solo fino a un certo punto e poi il resto tutto arabo ....

OK. Ma se c'è qualcosa di che t'interessa e non è chiaro posso cercare di spiegarlo diversamente.

Comunque ieri sera ero a pezzi e ho commesso qualche errore nello scrivere. Chiedo venia.
quello che ho scritto prima faceva riferimento a quello che mi è capitato l'anno scorso:
ad un evento di grafica dove era presente il creatore di Vray che stava presentando in anteprima Vray 3.0, durante la pausa, ho avuto modo di fargli direttamente 2 domande:

1 - Vray supportera gli Xeon PHI ?
2 - gli Xeon PHI hanno lo stesso problema delle GPU che sono limitate dal quantitativo di ram visto devono caricare tutta la scena 3D in ram ?

le sue risposte sono state.

1 - c'è gia un team di sviluppo che sta testanto gli Xeon PHI, ma abbiamo il problema che quando renderizzano al 100% vanno il protezione termica

Supportarlo, come dicevo, è davvero molto facile. Ovviamente i risultati migliori li ottieni se ottimizzando il codice tenendo conto delle peculiarità di Xeon Phi, ma in generale è decisamente semplice farlo.

Per quanto riguarda il fatto che vadano in protezione termica, è strano, perché non m'è mai capitato. Bisognerebbe vedere che tipo di Xeon Phi hanno (è disponibile in alcune versioni che variano per numero di core e clock).

Comunque potrebbero selettivamente scegliere quanti core utilizzare, in modo da trovare il giusto bilanciamento che eviti di far andare in protezione termina la scheda. Se utilizzano MPI per distribuire il carico di lavoro sui core & thread è molto semplice specificare quanti core usare, e in generale come distribuire l'esecuzione nei vari core e thread.
2 - si attualmente si

Credo di aver capito. Xeon Phi ovviamente lavora esclusivamente con sua memoria locale, per cui tutto ciò che gli serve (codice, dati) deve risiedere o nella GDDR5 o nella cache L2 o nella cache L1; non si scappa. Ovviamente può anche prelevare dati dalla memoria centrale, ma usando il protocollo PCI-Express, con tutti i limiti del caso (banda e latenza).

Knights Landing non fa eccezione, anche se non credo non ci siano problemi in tal senso, visto che integra moltissima memoria di per sé.

Con le architetture precedenti, però, il problema si pone, perché 8GB di RAM possono essere troppo pochi se c'è da manipolare grosse quantità di dati. In questo caso le applicazioni devono essere sviluppate in modo da cercare di massimizzare l'uso della memoria locale della GPU, suddividendo l'elaborazione in parti che girino interamente in Xeon Phi.

Credo che sia stato questo il problema che hanno avuto con Vray.
ora non so se quello che hai scritto tu cozza con quello che mi ha detto lui o se potrebbe anche esserci l'eventualita di avergli posto male la domanda con conseguente risposta intesa male da me ( ...non è stata una conversazione in italiano... )

Ti sei spiegato perfettamente, e sono abbastanza confidente che la problematica sia quella che ho descritto sopra.

Per cui con Knights Landing chi utilizza VRay può dormire sonni tranquilli.
pierpox25 Giugno 2014, 08:15 #10
Trovo molto interessanti i due ultimi interventi,dunque chi si avvale di strumenti come Intel Cluster Studio può creare il proprio codice e compilarlo ottimizzandolo per l'eventuale Phi presente nella sua workstation?Cioè in sostanza, lo sviluppatore si trova davanti uno scenario simile a quello con Parallel Nsight e CUDA(lato Nvidia) se lavora con ICS e librerie tipo IPP o MKL (lato INTEL)?Mi piacerebbe trovare anche qualche fonte autorevole (i links sono bene accetti) in cui viene approfondito quale tipo di algoritmi possono trarre massimo giovamento da una architettura come quella dello Xeon Phi rispetto a quella a Shader Unificati della controparte Nvidia o AMD essendo profondamente diverse.Mi interessa questo perchè proprio un paio di giorni fa leggevo,su documentazione ufficiale Intel,come far sfruttare a un notissimo software di calcolo (MATLAB) appunto una scheda PHI,dal momento che anche nella sua ultima versione uscita a Marzo MatWorks supporta ufficialmente solo CUDA.L'articolo era molto interessante faceva vedere come spostare il calcolo di due matrici (10000x10000 di double) dai processori (un paio di Xeon E5 a 8 cores ciascuno) alla scheda Phi utilizzando una phi della serie 7000.Lo sbattimento non era alla fine eccessivo si doveva forzare Matlab ad utilizzare l'ultima versione delle MKL e il risultato che faceva vedere l'articolo era sorprendende,le due CPU Xeon impiegavano circa 5s per il calcolo mentre la scheda PHI 1,89 secondi(sempre secondo PDF INTEL).Ho provato per curiosità ad eseguire lo stesso calcolo sulla Titan che ho sul mio pc,ma il risultato è stato di 0,002113 s!Da questa differenza elevata scaturisce la mia curiosità di approfondire il confronto tra le due differenti architetture,non credo dipenda dal codice estremamente ottimizzato delle librerie nvidia....

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.
 
^