Knights Landing è la futura GPU Intel per il calcolo parallelo

da quello che ho visto, 16:10 non esistono.... o meglio, esiste questo Canon, ma credo che costi come una BMW e non modello base
http://www.fotografidigitali.it/new...casa_49594.html

non so se ne uscira qualcuno con quella risoluzione, fino ad ora quelli che ho visto che devono uscire avranno tutti la solita risoluzione

credo che il miglio rapporto prezzo prestazioni lo si abbia con il Dell IGZO 32", anche perchè il dotch pitch dei 27" 4K non lo trovo molto confortevole...

40k dollari, LOL mi faccio prendere altre 3 ws in leasing.
Ovviamente per il 4k si punta al 32" o anche più
Il problema è convincere l'amministrazione che mi serva veramente

Molto ma molto interessante questa soluzione! Aspettiamo qualche bench!

Capisco, ma se hanno problemi di protezione termica, vuol dire che comunque non riescono a sfruttare al massimo la scheda. Allora tanto vale trovare il perfetto bilanciamento, senza per questo dover ritornare a usare la CPU.

Per fare un esempio pratico, se su 61 core a disposizione ne disabilitano soltanto 6 per non andare in protezione termica, col 10% in meno di core hai all'incirca il 10% in meno di prestazioni, ma in ogni caso molto più di quello che potrebbe fornirti una CPU.

Comunque potrebbero contattare Intel e chiedere spiegazioni, perché è una situazione che non dovrebbe verificarsi.

Beh, ma è come con le GPU: puoi utilizzare la loro memoria locale, ma l'operazione di trasferimento dei dati da CPU a GPU, e viceversa, rimane onerosa.

Non penso che ti lamenti del fatto di non poter utilizzare liberamente la memoria della GPU. Con Knights Corner (KC) al momento è così, perché la scheda si trova collegata al PC tramite lo stesso PCI-Express.

Con Knights Landing (KL) sarà diverso, ma ne parlo meglio dopo.

Scusami, ma non ho capito se ti riferisci all'attuale situazione con KC o con KL.

Per tagliare la testa al toro espongo le casistiche per entrambi.

Presupponendo una workstation con due socket dotati ognuno di un "normale" processore Xeon, 32+32 = 64 GB totali di RAM (di sistema), e una scheda Xeon Phi basata su KC con 8GB di memoria (VRAM), gli scenari possibili sono i seguenti:
1) offloading. I 64GB di memoria contengono tutto, e man mano spostano dei dati su e dalla VRAM (sempre tramite il PCI-Express), scaricando buona parte del lavoro su KC. Parlo di buona parte, perché una parte la possono elaborare le due CPU Xeon; infatti è possibile sfruttare qualunque dispositivo, siano esse le CPU o siano le schede Xeon Phi, per portare a termine il carico di lavoro. Si occupa il codice (generato dal compilatore e/o sfruttando OpenMP o MPI) di distribuire i job a tutti questi elementi. La memoria non è unificata, ma i due tipi di memoria sono separati, e il codice generato si occupa di copiare i dati avanti e indietro a seconda di come servono per quel pezzo particolare di codice che dev'essere eseguito.
2) MYO. Si tratta sempre di offloading, ma in questo caso la memoria che dev'essere condivisa fra le due CPU e Xeon Phi viene vista come se fosse unificata, con lo stesso spazio d'indirizzamento (leggi: gli indirizzi dei dati sono identici. Quindi se un vettore è condiviso fra le due CPU e Xeon Phi, avrà esattamente lo stesso indirizzo per tutti e tre i processori, e vi potranno accedere esattamente allo stesso modo). Si occupa il runtime di MYO di sincronizzare opportunamente le letture e scritture che occorrono per tutti e 3 i processori, in modo da mantenere coerenti i dati condivisi. Quindi c'è sempre una copia dei dati usando il PCI-Express, ma è totalmente trasparente all'applicazione.
3) nativo. Si può eseguire nativamente un'applicazione in Xeon Phi, senza interazione con il sistema centrale (le due CPU). Prima di ciò, però, è necessario copiare codice (nativo: l'applicazione viene compilata per girare soltanto su Xeon Phi, e non sulla CPU) e dati sulla scheda (che alla fine è un PC basato su Linux). Questo si realizza tramite un'apposita utility in dotazione del software di supporto di Xeon Phi (si chiama MPSS). Una volta caricato tutto sul filesystem della scheda, tramite una shell SSH si può lanciare l'eseguibile, e da lì in poi il codice andrà avanti da solo, in maniera indipendente da quello che fanno le due CPU. Ovviamente il limite di questa soluzione è rappresentato dallo spazio disponibile su disco, ma soprattutto dagli 8GB di memoria (VRAM) a disposizione. E' chiaro che, girando da solo, il codice non potrà contare sull'applicazione che gira sulle due CPU, e che può fornirgli sempre nuovi dati, recuperando quelli già elaborati. Per questo motivo si tratta di uno scenario poco utilizzato, ma ci sono aziende che lo adoperano, perché ha i suoi vantaggi (non c'è bisogno di alcun protocollo di comunicazione fra CPU e Xeon Phi, e non serve alcuna sincronizzazione fra di loro: Xeon Phi procede al massimo della velocità macinando i dati che si ritrova interamente in locale).

Arriviamo finalmente a KL. Essendo il successore di KC, presumibilmente dovrebbe poter gestire tutti e 3 gli scenari. Sicuramente supporterà il terzo, l'esecuzione nativa, ma questo, a differenza di KC, sarà proprio il suo punto di forza. Il motivo è presto detto: KL non ha bisogno di essere infilato in una scheda di un computer per poter funzionare, ma è in grado da solo di fungere da computer. Si tratta a tutti gli effetti di una normale CPU Intel64 da questo punto di vista, esattamente come tutte le altre (Atom, i3, i5, i7), per cui è possibile costruire computer che hanno soltanto questo processore all'interno. In questo caso non serve l'offloading, perché il computer con KL ha già tutto quello che gli serve. Anzi, ha pure molto di più, visto che la memoria a disposizione non è limitata a 8GB, ma arriva fino a 384GB. Questo significa che cadono di colpo tutti i limiti di cui sopra: hai tanta memoria, e... tutta "unificata" (c'è solo quella!). Quindi non devi sincronizzare proprio nulla, e non ci sono copie avanti e indietro: l'applicazione, all'avvio, carica tutti i dati sui quali deve lavorare, e poi procede spedita a macinarli. In più ha pure fino a 16GB di cache (L4?) a disposizione.

Sono risalito al PDF, e quello che descrivono è come abilitare Matlab a usare la libreria MKL. Non ci sono, quindi, particolari "cure": è all'incirca quello che si farebbe con altre applicazioni che utilizzano le funzioni BLAS e LAPACK. Semplicemente lo si è fatto per Matlab, che è un software noto e rinomato.

Le prestazioni sono deludenti, come già detto prima, ma dalla sola lettura del documento non sono in grado di formulare un'ipotesi.

Vedremo in futuro cosa arriverà.

A mio avviso sì, perché è una piattaforma più facile da programmare per scalare, e non richiede skill elevate.

Considera, ad esempio, che soluzioni massicciamente parallele sono utilizzate da scienziati che non nascono programmatori, ma che sono costretti a scrivere codice per i propri lavori. In questo caso offrire uno strumento di facile utilizzo, accompagnato a buone prestazioni, può fare la differenza.

Indubbiamente la sezione di decodifica di un core x86 è ben più complessa di quella di un RISC, e richiede sia transistor sia consumi più elevati. Ma dall'altra parte un'architettura CISC come quella offre anche vantassi in termini di maggior densità del codice e a livello prestazionale.

Puoi vederla in due modi diversi, a seconda della prospettiva: quelli che sono limiti da un lato diventano pregi dall'altro.

Concordo, ma Xeon Phi viene già utilizzato anche in alcuni supercomputer della TOP 500: se non avesse prestazioni reali interessanti, non ci sarebbe potuto arrivare.

Al momento mi pare difficile, perché è ben radicata. Bisognerà vedere quanto Intel riuscirà a spingere le sue soluzioni in quest'ambito.

Esattamente, anche se per ottenere il meglio bisogna quanto meno ricompilare il codice per sfruttare la nuova unità SIMD (con AVX512), e magari ritoccarlo in alcuni punti critici (ad esempio riutilizzando opportunamente la memoria già trasferita in Xeon Phi, evitando inutili copie avanti e indietro). Non serve molto per tutto ciò, ma sono ottimizzazioni che possono fare la differenza.

Certo, non è un'architettura che va bene per tutto.

Lato Intel con Knights Landing si prospetta un futuro in cui ci saranno soltanto CPU Xeon Phi, e nessuno Xeon classico, proprio perché KL è perfettamente in grado di fungere da CPU e, dunque, è possibile costruire interi computer che li contengono (senza ricorrere al PCI-Express). Vedi sopra per maggiori dettagli.

La battaglia, a mio avviso, sarà anche su un altro piano. Mentre una soluzione basata su core ARM + GPU prevede che il primo scarichi il lavoro sul secondo, usando un particolare protocollo di comunicazione / sincronizzazione fra i due (molto) diversi elementi, con Xeon Phi (anche KC) tutto ciò non serve più, perché ogni singolo lo possiamo vedere come la fusione di un "core" (in realtà sarebbe un'unità di calcolo) scalare e uno vettoriale, le cui istruzioni da eseguire vengono pescate direttamente dall'unico, nonché condiviso, flusso letto dalla memoria. In buona sostanza, in Xeon Phi non c'è nessun protocollo: ci sono le istruzioni che vengono date in pasto al thread hardware, che vengono smistate all'unità scalare e/o vettoriale ed eseguite immediatamente. Per cui praticamente non c'è alcun overhead, come invece capita coi core eterogenei di una soluzione con due processori completamente separati nonché diversi.

Il prossimo anno farei festa, al posto tuo.

Bene. Potresti fornire qualche dettaglio? Cos'hai notato? Come ti trovi? Sono curioso di leggere il parere di un customer.

La Math Kernel Library è quella deputata a velocizzare appunto calcoli,così come le librerire utilizzate dalle gpu nvidia all'interno del toolkit di CUDA,ora,una differenza di ben due ordini di grandezza ci suggerisce solo una cattiva ottimizzazione del codice oppure una differeza architetturale tra un intel core e un cuda core nel maneggiare determinate tipologie di calcoli?Cioè mi interessava capire se queste due architetture così diverse sarenno capaci di gestire più efficentemente determinate operazione piuttosto che altre.

Un altra perplessità poi, nel futuro,KL integrerà una CPU e si infilerà in un socket,vedrà tutta la memoria e la utilizzerà per approvviggionarsi di dati da eseguire sui suoi 70 e oltre core,ho capito bene?.Se così, la memoria di sistema che andrà ad utilizzare non avrà prestazioni come quella impiegata direttamente su una scheda per slot PCI-E e dedicata alla GPU,cioè allora mi chiedo, nella visione unificata della memoria non ci saranno passaggi di dati avanti e indietro tra GPU, CPU e memoria centrale ok,ma non perderemo troppi benefici che possono scaturire da un elevato trasferimento di dati tra appunto la GPU e la sua memoria?

In che senso scusa?


Diciamo che per compiere determinati lavori il tempo è passato da 10 a 4, ovviamente il merito non è solo di phi ma anche dei due 2880 che hanno sostituito i 2670 che c'erano nella r930, ovviamente non tutti i so che utilizzo permettono quel grado di parallelizzazione, a volte per avere un alto rendimento lavorativo sono "costretto" a lanciare anche due sessioni contemporaneamente, in ufficio abbiamo anche due ws con su delle tesla (non so dirti quale modello) però l'ing (credo fosse un informatico) che ci lavorava su è andato altrove e ora tra meccanici ed aereospaziali non sappiamo come metterci mano. , però ricordo che con ansys, nastran e patran ci si faceva bella roba.

e no, il problema sta proprio li; nel caso delle GPU il trasferimento dei dati puo avvenire solo all'inizio, prima della partenza del render; se la scena+texture+xref, tutto insomma, supera la quantita di memoria on-board non puoi caricarla successivamente, deve stare tutto all'interno.

da quello che diceva il creatore di Vray l'attuale KC ha lo stesso limite, quindi o carichi tutto subito in ram video o ti attacchi.

quello che chiedevo su KL era se era cambiata o meno questa cosa e come veniva vista la memoria, visto il fatto che ora è possibile montarlo su socket normale e mettergli le DDR4;

nel senso, le GPU future avranno al memoria condivisa in hardware, quindi teoricamente non dovrebbe esserci piu questo problema e il render partira indipendentemente dalla quantita di vram.

almeno Vray, e iRay con le GPU funzionano cosi.






se fosse la prima o la terza sarebbe ottimo

eh non so quale modello di preciso, è stata una conversazione veloce ; non è sceso in particolari, quindi non so se andava sempre in protezione o solo in particolari situazioni. Comunque l'evento c'è stato a Ottobre 2013, quindi credo uno dei modelli in commercio in versione carentata con ventola perche dovrebbe finire nelle workstation.

adottera lo stesso socket degli Xeon, quindi come mobo usera quelle.

Non avendo altre informazioni, come dicevo, mi è difficile capire dove possa essere il problema.

Escludo che sia un problema architetturale, e per due semplici ragioni.
La prima è logica/pratica, ed è che proprio il calcolo matriciale è alla base della tipologia di calcoli eseguita in sistemi HPC. Se Xeon Phi non avesse prestazioni adeguate non se la sarebbe calcolata nessuno; invece si trova addirittura fra i primi 10 supercomputer.
La seconda riguarda l'analisi tecnica dell'architettura. Proprio per questo tipo di calcoli si possono sfruttare con facilità sia le istruzioni vettoriali (incluse quelle di tipo FMAC, che consentono di eseguire contemporaneamente una moltiplicazione e una somma) per processare un gruppo di elementi sia i numerosi core suddividendo il carico di lavoro. Peraltro sono presenti delle istruzioni di gather/scatter per gestire con scioltezza anche il caso di elementi sparsi in memoria, a cui aggiungo i registri "di maschera(mento)" per le condizioni ai bordi (quando ci sono meno elementi rispetto a quelli necessari per riempire interamente un registro vettoriale).

Per cui, tornando a prima, penso che ci sia qualche problema che impedisce di trarre pieno vantaggio da quest'architettura.

E' normale che una particolare architettura sia più portata per certi tipi di calcoli piuttosto che per altri. Lo vedi anche con le normali CPU: fra Intel e AMD a parità di FLOPS erogabili ci sono delle differenze prestazionali.

Esattamente.

Veramente la memoria utilizzata è proprio quella tipicamente in uso nelle GPU, e dunque con una banda elevata. Con KC la banda è già di per sé molto elevata, ma con KL la situazione dovrebbe essere ancora migliore grazie all'adozione della DDR4.

Quindi c'è sicuramente di che star tranquilli: niente trasferimenti inutili, e banda estremamente elevata.

Perché con KL l'incremento prestazionale è ancora più marcato, per cui hai tutto da guadagnarci aggiornando a KL.

Ma intanto ti godi KC...

Senz'altro.

Perché queste architetture si prestaziono bene per le problematiche di cui hai parlato.

Non è così: dipende tutto dalla modalità in cui lo utilizzi. Come dicevo prima, sfruttando MYO puoi mappare tutta la memoria condivisa fra CPU e Xeon Phi in uno spazio d'indirizzamento comune e in maniera trasparente all'applicazione. La sincronizzazione dei dati è automatica, e quindi se Xeon Phi non trova un dato nella sua memoria locale, internamente si attiva il meccanismo di caricamento di quel dato, che al completamento del quale consente a Xeon Phi di riprendere l'esecuzione esattamente da dov'era stato interrotto.

Il problema, però, è che ci sono dei costi da pagare: quello del page fault (che fa andare la CPU in kernel space; e poi deve ovviamente ritornare) e quello della lettura dei dati dalla memoria principale tramite PCI-Express.

Per questo motivo MYO è sconsigliabile nei casi in cui si accede in maniera troppo poco sequenziale / locale alla memoria, mentre va bene quando si possa sfruttare la località dei dati (e, dunque, minimizzare page fault & sincronizzazioni).

E' come ho già detto prima: è un solo tipo di memoria, che quindi è, per forza di cose, "condivisa". Dunque non avrai più alcun problema di sincronizzazione dei dati, perché KL può essere usato, ed è a tutti gli effetti, come un computer "normale".

La terza è il dominio d'elezione di KL. La prima modalità (offload "classico" è, invece, quello per KC.

E' strano, perché ho appena controllato: c'è un link e si apre.

Esiste solo MYO. MYC non è un modello di utilizzo di Xeon Phi.

In tutta onestà non ne sono a conoscenza, e comunque, anche se lo fossi, mi spiace, ma non ne potrei parlare.

Knights Ferry è il predecessore di KC, ma che io sappia (da utente comune: non ho altre informazioni in merito, perché quando sono arrivato c'era già da tempo KC, e io ho lavorato soltanto a questo) è stato distribuito soltanto a poche aziende che lavorano nell'ambito dell'HPC.



Come una workstation e/o rack server, immagino.

Non ne ho idea. Ma non penso che serva una scheda video, visto l'ambito di utilizzo. Al più se ne potrebbe integrare qualcuna (nella scheda madre, nel southbridge, oppure all'interno della CPU) soltanto per il controllo / monitoraggio del mostriciattolo, ma è soltanto la mia opinione "da utente qualunque" che sto esprimendo in questo momento.

Boh. Non è il mio campo e non mi sono informato.

Supporta sicuramente una particolare versione di Linux, visto che XC la usa già.

Non so se supporti Windows. In linea teorica dovrebbe funzionare tranquillamente con qualunque s.o. esistente per IA-32 e Intel64/x64.

Non lo so, mi spiace, ma non vedo alcun limite a ciò, essendo praticamente un computer.

Su questo non ho letto notizie.