Knights Landing è la futura GPU Intel per il calcolo parallelo

[Redazione di Hardware Upg]

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

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

Click sul link per visualizzare la notizia.

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

[AceGranger]

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 :/

[massimo79m]

ram su cpu? paura!

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

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

[AceGranger]

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/1...supercomputing

[devil_mcry]

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.

[cdimauro]

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.

[AceGranger]

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

[cdimauro]

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.

[pierpox]

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

[cdimauro]

Il risultato di Xeon Phi è decisamente scadente. Evidentemente c'è qualcosa che non consente di sfruttare la potenza di calcolo a disposizione, che specialmente in doppia precisione è molto elevata.
Bisognerebbe analizzare il test e profilare l'applicazione per rilevare i colli di bottiglia, anche perché il calcolo matriciale si presta bene per quest'archutettura.
Comunque non userei Intel Cluster Studio, visto che non c'è un cluster. Intel Conposer XE è lo strumento più adatto allo scenario esposto, che è pure quello più comune.
Al momento non posso aggiungere altro perché sono con lo smartphone e sto andando a lavoro.

[AceGranger]

Originariamente inviato da cdimauro

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.

non è sceso piu di tanto nei particolari ma credo che il loro scopo fosse/sia quello di farla lavorare al 100%, ora non so quanto sia efficiente o meno rispetto alle CPU in questi ambiti, ma visto il costo elevato se vogliono renderla un'opzione percorribile credo che debbano trovare il modo di sfruttarla al 100%, seno tanto vale rimanere su CPU.

Originariamente inviato da cdimauro

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.

mmm e no allora parziali brutte notizie :/ perchè es. io attualmente lavoro con 32 Gb di ram, non le uso per tutti i render, pero il fatto di avere un qualcosa che non posso usare sempre non mi piace molto...

pero secondo te, immaginando questo sistema, quale situazione si verifichera:

scheda madre bi-socket, socket 1 Xeon con 32 Gb di ram, socket 2 con Xeon PHI con 16 Gb on-board e 32 Gb di ram come banchi

premessa ( attualmente con le GPU e l'attuale PHI la scena di render deve essere caricata totalmente in ram texture comprese, seno non parte il render )

1- avremo 64 Gb di ram di sistema e separati 16 Gb on-board, quindi la scena di render dovra essere inferiore ai 16 Gb

2- avremo 80 GB di ram+on-board che saranno un tutt'uno quindi scena di render senza limiti

3- avremo 32 Gb di ram dello Xeon CPU classico e poi separati i 48 Gb PHI ( i suoi 16 on-board + i 32 collegati al suo socket ) quindi il limite di 32 Gb


se non ho capito male quello che hai scritto che il limite rimane ci troveremo nella situazione 1 ( brutta ) o potrebbe essere anche al situazione 3 ( bella

[pierpox]

Si,avevo citato il Cluster Studio perchè raccoglie un po tutto il necessario(librerie incluse) per scrivere diverso codice ottimizzato anche in distribuito.La cosa mi ha lasciato parecchio perplesso...anche per il fatto che è documentazione ufficiale intel,quindi presumo che abbiano fatto di tutto per esprimere il massimo!Il pc di prova è questo:

"This article was created based on MATLAB R2014a and Intel MKL for Windows* 11.1 update1 and update 2 on the system
Host machine: Intel Xeon CPU E5-2697 v2, 2 Twelve-Core CPUs (30MB LLC, 2.7GHz), 128GB of RAM; OS: Windows Server 2008 R2 Enterprise
Coprocessors: 2 Intel® Xeon Phi™ Coprocessors 7120A, each with 61 cores (30.5MB total cache, 1.2GHz), 16GB GDDR5 Memory
Software: Intel® Math Kernel Library (Intel® MKL) 11.1 update 1 and update 2, Intel Manycore Platform Software Stack (MPSS) 3.2.27270.1".

Per una configurazione così ci vuole una vagonata di euro e poi dopo le opportune mdificazioni suggerite ecco il risultato (un po deludente):

"If you start a MATLAB session after setting MKL_MIC_ENABLE, the MATLAB command window displays:
>> TestBlas
Elapsed time is 1.869576 seconds"

TestBlas crea le due matrici ma calcola il tempo solo per il prodotto delle stesse.Dunque sarà più un cattivo supporto o una deficenza dell'architettura?

[devil_mcry]

Originariamente inviato da cdimauro

Infatti non lo sono.

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.

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.


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.

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.

Davvero notevole, mi piacerebbe un casino provarne uno in futuro ma credo non sarà compatibile con le mie tasche. :P Però grande Intel, via di sto passo probabilmente il futuro sarà in questo senso

[Ares17]

Originariamente inviato da devil_mcry

Davvero notevole, mi piacerebbe un casino provarne uno in futuro ma credo non sarà compatibile con le mie tasche. :P Però grande Intel, via di sto passo probabilmente il futuro sarà in questo senso

3 TF in Db vuol dire tutto e niente.
Essendo comunque un ia32 si porterà dietro tutti i limiti x86 dietro, mitigati da accorgimenti vari certamente, ma la prova sul campo metterà in luce l'esatto valore di queste soluzioni.
Troppe volte ho visto specifiche sulla carta mirabolanti e poi prestazioni deludenti in pratica.
L'unica cosa che posso però dire è che vedo sempre più nvidia tagliata fuori dal settore HPC.
Questa soluzione elimina praticamente il bisogno di riscrivere il codice da zero, mentre in situazioni particolari potrebbe essere addirittura consigliabile l'apu AMD per abbattere i costi.

[AceGranger]

Originariamente inviato da Ares17

3 TF in Db vuol dire tutto e niente.
Essendo comunque un ia32 si porterà dietro tutti i limiti x86 dietro, mitigati da accorgimenti vari certamente, ma la prova sul campo metterà in luce l'esatto valore di queste soluzioni.
Troppe volte ho visto specifiche sulla carta mirabolanti e poi prestazioni deludenti in pratica.
L'unica cosa che posso però dire è che vedo sempre più nvidia tagliata fuori dal settore HPC.
Questa soluzione elimina praticamente il bisogno di riscrivere il codice da zero, mentre in situazioni particolari potrebbe essere addirittura consigliabile l'apu AMD per abbattere i costi.

bha a me le APU paiono senza senso, sono limitate dalla GPU entry lvl e sono malamente scalabili; con Intel o nVidia ti fai un singolo sistema da 1 a 4 CPU e da 1 a 8 GPU e passi da sistemi entry lvl a Top gamma.

al contrario nVidia si sta ritagliando tutto un suo mercato offrendo soluzioni complete fatte e finite di hardware + software.

[pierpox]

Originariamente inviato da AceGranger

bha a me le APU paiono senza senso, sono limitate dalla GPU entry lvl e sono malamente scalabili; con Intel o nVidia ti fai un singolo sistema da 1 a 4 CPU e da 1 a 8 GPU e passi da sistemi entry lvl a Top gamma.

al contrario nVidia si sta ritagliando tutto un suo mercato offrendo soluzioni complete fatte e finite di hardware + software.

Si,credo che lo scenarieo futuro sarà una piattaforma hardware solo INTEL con Xeon classici più PHI e solo NVIDIA cpu ARM e schede TESLA .Sarà interessante questa "battaglia" anche perchè con Maxwell e architetture future Nvidia sta spingendo molto anche sull'efficenza enegetica oltre che sulle prestazioni pure!

[Vash_85]

Pensare che poco meno di un mese fa mi ero fatto aggiornare la ws con due phi è due xeon 2880....
Però le prove di impatto ringraziano....

[AceGranger]

Originariamente inviato da Vash_85

Pensare che poco meno di un mese fa mi ero fatto aggiornare la ws con due phi è due xeon 2880....
Però le prove di impatto ringraziano....

bè dai queste usciranno fra un anno, hai tutto il tempo di fargliele ricomprare