[cdimauro]

Originariamente inviato da AceGranger

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.

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.

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

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.

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

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.

Originariamente inviato da 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!

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.

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?

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

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

Vedremo in futuro cosa arriverà.

Però grande Intel, via di sto passo probabilmente il futuro sarà in questo senso

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.

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.

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.

Troppe volte ho visto specifiche sulla carta mirabolanti e poi prestazioni deludenti in pratica.

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.

L'unica cosa che posso però dire è che vedo sempre più nvidia tagliata fuori dal settore HPC.

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

Questa soluzione elimina praticamente il bisogno di riscrivere il codice da zero,

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.

mentre in situazioni particolari potrebbe essere addirittura consigliabile l'apu AMD per abbattere i costi.

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

Originariamente inviato da pierpox

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 .

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.

Sarà interessante questa "battaglia" anche perchè con Maxwell e architetture future Nvidia sta spingendo molto anche sull'efficenza enegetica oltre che sulle prestazioni pure!

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.

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

Il prossimo anno farei festa, al posto tuo.

Però le prove di impatto ringraziano....

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