Niente più Knights Hill nelle roadmap Intel per i supercomputer

Niente più Knights Hill nelle roadmap Intel per i supercomputer

Intel rimuove la futura generazione di acceleratori della famiglia Xeon Phi, in attesa di nuove microarchitettura e piattaforma associate

di Paolo Corsini pubblicata il , alle 10:41 nel canale Server e Workstation
IntelXeon Phi
 
19 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
lucusta14 Novembre 2017, 21:36 #11
Originariamente inviato da: CrapaDiLegno
Il tutto con consumo di picco di 180W e 130W di media (che la rende la scheda acceleratrice più efficiente finora costruita, persino migliore delle soluzioni nvidia che le stanno poco dietro). Quanti TFLOPS fa una Knight Landing e in quanti W?


picco?
media?
quando usi un processore del genere sei sempre al limite dell'ultima istruzione utile, sempre se la riesci a sfruttare (perchè un processore non è solo pipeline di calcolo).
comunque 180W su 16TeraFlops, se fossero 25 sarebbero 280W, con una Mi25 che ha 25TF per 300W.
20W in piu' di consumo a scapito di una massificazione di calcolo del 50% in piu', ossia usi meno schede, e piu' economiche, per ottenere la stessa potenza finale.
come in tante altre cose, non devi guardare esclusivamente il consumo del singolo componente, ma come questo consumi insieme a tutto il resto per operare ad un certo livello di prestazioni.
se devo metterci il 50% in piu' di ingegnerizzazione attorno, che dici, quei 20W sono ancora così fondamentali?

Intel, acquisendo le IP AMD, puo' costruire blade che spaziano efficacemente ed efficientemente da INT8 a FP512 massimizzando sia l'efficienza che la potenza di calcolo assoluta.
non c'e' alternativa, se non farsi un asic dedicato allo scopo, se non ti è chiaro il concetto.

ed il tutto senza riesumare il cubotto fatto con le Vega di AMD, in cui si unisce potenza di calcolo a capacità comunicative insuperabili...

giocare con quegli aggeggi è quasi meglio che giocare con i lego.

e, di contorno, ROCm 1.7 oggi supporta pienamente Tensor Flow, oltre al fatto che con OpenCL Port il 99.6% del codice cuda per Caffè è automaticamente convertito in OpenCL.

se nvidia non comincia a spacciare ile sue mattonelle a prezzi più concorrenziali, la vedo ben cupa.
Bellaz8914 Novembre 2017, 22:30 #12
Domanda a chi ne sa di piu' sugli attuali Xeon Phi:

E' possibile per questi processori fare letture della memoria in coalescenza (accessi alla memoria sincroni da parte di tutti i core) come accade per le gpu (AMD/NVIDIA)?

Mi sono sempre chiesto se l'avere N cpu X86 indipendenti non portasse a dei bottleneck sulle letture/scritture della memoria. Probabilmente il fatto di avere cache piu' elevate aiuta, ma mi chiedo se nelle applicazioni memory intensive questo basti (Anche se -ovviamente- l'utilizzatore finale si orienta su un prodotto piuttosto che altro in base alle applicazioni che deve far girare)
lucusta15 Novembre 2017, 00:39 #13
è un mesh, quindi ha hub dedicati alla memoria e diversi vie sui nodi per arrivarci;
ogni singolo processore ha sufficiente cache per mantenere dati in locale.
il 7290 ha 32MB di L2 ed è comunque un esachannel 2400mhz (115GB/s) per 384GB di ram a CPU, oltre al fatto di essere NUMA e quindi di poter allocare la memoria fisicamente sulla dimm che serve, quindi sull'IMC piu' vicino e idoneo, di poter replicare il dataset su ogni canale etc, etc...

certo, dipende comunque sempre dall'applicazione, ma di solito ci esegui calcoli assai differenti da come, ad esempio, lo sono quelli per le criptovalute a blockchain ricorsivo, quindi con elevato numero di letture in memoria.

ecco, un bel set di HBM2 e si risolverebbero molte cose (soprattutto il consumo) ma, ad oggi, saresti limitato a 48GB (6 chip per 8GB l'uno, e nuovi IMC)...
chissà se vogliono sfruttare la sinergia con AMD in tal senso.
cdimauro15 Novembre 2017, 06:50 #14
Originariamente inviato da: CrapaDiLegno
Si certo, più sforzi ad utilizzare un compilatore piuttosto che un altro. Dal punto di vista di chi scrive il codice non cambia una mazza, sopratutto perché le routine utilizzate sono scritte in ASM e si chiamano quelle, dato che nessun compilatore può astrarre in maniera automatica lo scopo di un calcolo complesso come quello da fare su una SIMD.

Hai idea di quanto siano complicati i calcoli realizzati da applicazioni HPC et similia? Mi pare proprio di no.

Le parti in assembly, se ci sono, sono relative a funzioni di libreria che vengono utilizzate per "comporre"/calcolare ciò che, alla fine, serve realmente.

Tali funzioni di libreria sono scritte per lo più in Fortran (sì, hai letto bene) e soltanto negli ultimi anni ne sono state scritte alcune versioni in C++, oppure vengono utilizzati dei wrapper per poter utilizzare direttamente quelle scritte in Fortran.

Per poter sfruttare meglio che si può le capacità di calcolo di soluzioni HPC come queste vengono sfruttate le funzioni intrinsic, che servono a "segnalare" al compilatore il contesto d'esecuzione (in che modo vengono utilizzati i dati) o direttamente la tipologia di istruzioni da impiegare.

Ovviamente ci sono anche parti in assembly dove serve / è stato fatto, ma impiegare direttamente l'assembly è estremamente costoso.
Quindi al massimo puoi parlare di soluzioni che hanno un diverso supporto, ma non certo che usare un determinato HW piuttosto che un altro diventa complicato per il programmatore.

Parli così perché non hai la minima idea di come funzionino queste cose.

Prendi un algoritmo che si presta per calcoli di questo tipo, riporta il normale codice C/C++/Fortran, e poi quello CUDA (visto che nVidia va forte in questo mercato) e quello Xeon Phi.
A quest'ultimo posso provvedere io, visto che è veramente e te lo posso realizzare in TRE versioni: con #pragma per il compilatore C/C++/Fortran, con le estensioni CILK+, o con MYO. Sì, Intel offre ben TRE (DIVERSI!) modelli/paradigmi per poter sfruttare il suo hardware, e non ho citato nemmeno le OpenCL perché queste sono più generali (tutti i produttori di CPU/GPU possono sfruttarle).

Se prendi i codici finali, noterai delle "LEGGERISSIME" differenze. Eppure il calcolo eseguito, alla fine, è esattamente lo stesso.
Inoltre la suddetta architettura non ha molto di "esoterico", certamente è meno fantasiosa nell'avere un inutile core x86 per pilotare 2 FPU che sono quelle addette a lavorare per davvero.

Ma di quali FPU parli? Come ha detto giustamente lucusta, qui parliamo di unità SIMD. L'FPU x86, da quando è stato introdotta x64 è DEPRECATA.

E a parte questo, continui a non avere la minima idea di come funzionino non sole unità SIMD x86, ma la recentissima AVX-512 (che poi è quella utilizzata in queste soluzioni HPC).

Giusto per essere chiari: c'è PIENA SINERGIA fra l'unità di calcolo "intera" x64 e l'unità SIMD. D'altra parte basta prendere un qualunque pezzo di codice, disassemblarlo, e vedere il mix delle suddette istruzioni che ne viene fuori.
Eh? Scusa ma che specifiche hai letto? Quelle della prima versione vecchia di 2 anni? Per la corrente in produzione e vendita e installate sugli ultimi super computer leggo 8TFLOPS in FP32 e 4TFLOPS in FP64 e 16TFLOPS in FP16.

Dal tuo link:

[I][INDENT]"Operating at 1 GHz, the PEZY-SC2 has a peak performance of 8.192 TFLOPS (single-precision) and 4.1 TFLOPS (double-precision) while consuming around 180 Watts.
[...]
At 1 GHz, the SC2 can peak at 16.4 TFLOPS for half precision."[/INDENT][/I]
Il tutto con consumo di picco di 180W e 130W di media (che la rende la scheda acceleratrice più efficiente finora costruita, persino migliore delle soluzioni nvidia che le stanno poco dietro). Quanti TFLOPS fa una Knight Landing e in quanti W?

Su questo t'ha risposto lucusta.
Ci sarà un motivo per cui la presenza di queste schede acceleratrici siano aumentate nel tempo nella classifica. E infatti stanno prendendo piede proprio nei server HPC, IA e DeepLearning (non so se hai capito che ogni scheda a 16FLOPS in FP16, tutt'altro che "poco" per il DeepLearning).

Tu che dici, ci sarà un motivo anche per l'adozione in crescita di Xeon Phi?
Per quanto riguarda la MICRO-Architettura, è molto ma molto probabile che sarà pensata per fare un die con il core e "incollarlo" (usando la sintassi di Intel) ad un bel die separato creato dal Koduri che eseguirà i calcoli veri. L'MCM di Intel è promettente sotto questo punto di vista, e credo proprio che potrebbe salvargli la vita permettendogli di integrare roba non x86 per progredire.

Per com'è stata scritta la notizia, NON si parla di una nuova ARCHITETTURA, ma di una MICRO-architettura, come avevo già evidenziato. Ergo: Xeon Phi è ancora lì.

Poi POTREBBERO anche aggiungere uncore diversi, ma non è emerso dalla notizia/press release.
cdimauro15 Novembre 2017, 06:55 #15
Originariamente inviato da: Bellaz89
Domanda a chi ne sa di piu' sugli attuali Xeon Phi:

E' possibile per questi processori fare letture della memoria in coalescenza (accessi alla memoria sincroni da parte di tutti i core) come accade per le gpu (AMD/NVIDIA)?

Mi sono sempre chiesto se l'avere N cpu X86 indipendenti non portasse a dei bottleneck sulle letture/scritture della memoria. Probabilmente il fatto di avere cache piu' elevate aiuta, ma mi chiedo se nelle applicazioni memory intensive questo basti (Anche se -ovviamente- l'utilizzatore finale si orienta su un prodotto piuttosto che altro in base alle applicazioni che deve far girare)

Velocemente, perché devo correre a lavoro. Sì, questa funzionalità i core x86 la mettono a disposizione da quando sono nati.

Sono, al contrario, soluzioni come le GPU, che ne erano del tutto sprovviste, che negli ultimi anni hanno integrato funzionalità/istruzioni per gestire questi casi.

Comunque anche a fronte di funzionalità simili, un certo algoritmo andrà meglio o peggio in un'architettura anziché su un'altra. Bisogna provare, e vedere.

Aggiungo che per gestire casi di conflitti & sincronizzazioni per l'accesso alla memoria, Intel ha pure introdotto le transazioni, che mi pare siano ancora non offerte dalle GPU. Dunque i programmatori, sempre a seconda del tipo di calcolo, hanno anche questa possibilità.
cdimauro15 Novembre 2017, 07:14 #16
Ho un minuto, e aggiungo una cosa al volo, importantissima, che m'è venuta in mente sotto la doccia.

I core pezy-sc2 hanno bisogno di core MIPS (prima avevano ARM) per coordinare il lavoro delle "tile" SC2. Questo significa che i programmatori sono costretti a scrivere DUE codici: quello che gira nelle tile SC2, e quello che gira nei MIPS che coordinano tutto il lavoro, e decidono se/come/quando spedire e recuperare poi il lavoro delle SC2.

Quindi, come dicevo prima, c'è molto più lavoro per i programmatori. Similmente a quanto avviene con nVidia / CUDA.

E' roba che si faceva con Xeon Phi (ma MOLTO più semplicemente) con le schede discrete, che però con Knights Landing sono state ormai dismesse. Quest'ultimo consente banalmente di far girare qualunque binario x86/x64 e con AVX-512.
CrapaDiLegno15 Novembre 2017, 13:29 #17
Originariamente inviato da: cdimauro
Hai idea di quanto siano complicati i calcoli realizzati da applicazioni HPC et similia? Mi pare proprio di no.

Le parti in assembly, se ci sono, sono relative a funzioni di libreria che vengono utilizzate per "comporre"/calcolare ciò che, alla fine, serve realmente.

Tali funzioni di libreria sono scritte per lo più in Fortran (sì, hai letto bene) e soltanto negli ultimi anni ne sono state scritte alcune versioni in C++, oppure vengono utilizzati dei wrapper per poter utilizzare direttamente quelle scritte in Fortran.

Per poter sfruttare meglio che si può le capacità di calcolo di soluzioni HPC come queste vengono sfruttate le funzioni intrinsic, che servono a "segnalare" al compilatore il contesto d'esecuzione (in che modo vengono utilizzati i dati) o direttamente la tipologia di istruzioni da impiegare.

Ovviamente ci sono anche parti in assembly dove serve / è stato fatto, ma impiegare direttamente l'assembly è estremamente costoso.

Parli così perché non hai la minima idea di come funzionino queste cose.

Tu che lo sai hai detto esattamente quello che ho detto io, infatti.
Per lo sfruttamento delle unità di elaborazione serve che le funzioni base siano scritte in librerie che vengono poi chiamate.
Ergo, per un programmatore se tali librerie siano per l'architettura A o B non cambia nulla. Non c'è difficoltà aggiunta a non usare x86.

Originariamente inviato da: cdimauro
Prendi un algoritmo che si presta per calcoli di questo tipo, riporta il normale codice C/C++/Fortran, e poi quello CUDA (visto che nVidia va forte in questo mercato) e quello Xeon Phi.
A quest'ultimo posso provvedere io, visto che è veramente e te lo posso realizzare in TRE versioni: con #pragma per il compilatore C/C++/Fortran, con le estensioni CILK+, o con MYO. Sì, Intel offre ben TRE (DIVERSI!) modelli/paradigmi per poter sfruttare il suo hardware, e non ho citato nemmeno le OpenCL perché queste sono più generali (tutti i produttori di CPU/GPU possono sfruttarle).

Se prendi i codici finali, noterai delle "LEGGERISSIME" differenze. Eppure il calcolo eseguito, alla fine, è esattamente lo stesso.

Quote quindi, come detto sopra, lo sforzo di supportare l'architettura A piuttosto che B sta nel suggerire al compilatore e usare le librerie già fatte.
Sforzo aggiunto pari a quello di capire dove l'architettura ha problemi ed evitare di pestare continuamente quel punto.

Originariamente inviato da: cdimauro
Ma di quali FPU parli? Come ha detto giustamente lucusta, qui parliamo di unità SIMD. L'FPU x86, da quando è stato introdotta x64 è DEPRECATA.

Scusa, non so cosa tu e lucusta intendiatre per FPU, per me sta per Floating Point Unit. Le AVX lavorano forse con gli interi?

Originariamente inviato da: cdimauro
E a parte questo, continui a non avere la minima idea di come funzionino non sole unità SIMD x86, ma la recentissima AVX-512 (che poi è quella utilizzata in queste soluzioni HPC).

Giusto per essere chiari: c'è PIENA SINERGIA fra l'unità di calcolo "intera" x64 e l'unità SIMD. D'altra parte basta prendere un qualunque pezzo di codice, disassemblarlo, e vedere il mix delle suddette istruzioni che ne viene fuori.

La sinergia ce l'hai con l'architettura x86 che la NECESSITA, altre architetture non necessitano sinergie con core esterni per fare i conti (tipo GPU).
Ah, e per evitare ulteriori derive all'argomento, intendo nella parte attiva dei conti. Ovvio che anche le GPU necessitano di un componente esterno che organizzi il lavoro e faccia da interfaccia al resto (come lo necessitano anche le Phi con gli Xeon a corredo).

Originariamente inviato da: cdimauro
Dal tuo link:

[I][INDENT]"Operating at 1 GHz, the PEZY-SC2 has a peak performance of 8.192 TFLOPS (single-precision) and 4.1 TFLOPS (double-precision) while consuming around 180 Watts.
[...]
At 1 GHz, the SC2 can peak at 16.4 TFLOPS for half precision."[/INDENT][/I]

Dal mio link.. si vede che quando non hai nulla da dire ti piace confondere la gente.. dal mio link , è quello che ti ho scritto IO!
Per te 16TFLOPS in FP16 sono pochi? E 4TFLOPS in FP64?
Probabilmente hai letto le specifiche della vecchia versione (o quelli della scheda Intel) e ora ti stai arrampicando sugli specchi, perché dire che fa grandi numeri in FP32 e pochi in FP64 e FP16, quindi non adatta a HPC e DeepLearning, quando questi valori sono in perfetto scaling con le prestazioni FP32 vuol dire aver preso una enorme cantonata.

Originariamente inviato da: cdimauro
Su questo t'ha risposto lucusta.

Che non ha per nulla ragione, dato che i consumi non sono solo dovuti al fatto che la scheda va a palla ma anche a tutto il resto (tipo quanti dati scambi sui canali di memoria e che tipo di conti fai).
La potenza teoria non la raggiungi sempre (anzi praticamente mai), quindi non sei mai a potenza massima se non per pochissimo tempo.
Inoltre forse non avete letto bene che tipo di memoria secondaria può usare.

Originariamente inviato da: cdimauro
Tu che dici, ci sarà un motivo anche per l'adozione in crescita di Xeon Phi?

Secondo le dichiarazioni di Intel, sono in crescita le versioni standalone, non le acceleratrici discrete. Ci sarà un motivo perché le prime non sono per HPC mentre le seconde sono state cancellate da Intel.

Originariamente inviato da: cdimauro
Per com'è stata scritta la notizia, NON si parla di una nuova ARCHITETTURA, ma di una MICRO-architettura, come avevo già evidenziato. Ergo: Xeon Phi è ancora lì.

Poi POTREBBERO anche aggiungere uncore diversi, ma non è emerso dalla notizia/press release.

Le Xeon Phi sono lì perché coprono un mercato più piccolo rispetto alle schede acceleratrici discrete che non sono autonome.
Il vantaggio quindi è altro rispetto alla vera capacità computazionale in cui sono state scalzate da altre architetture, e in prestazioni assolute e in efficienza (nonostante il PP migliore che Intel dice avere, figuriamoci a uguale PP che figura avrebbero fatto). Per riuscire a colmare il gap è necessario che le AVX così come sono messe oggi siano riviste e molto probabilmente saranno usate come cluster in die separati e "incollati" tra di loro.

Originariamente inviato da: cdimauro
Ho un minuto, e aggiungo una cosa al volo, importantissima, che m'è venuta in mente sotto la doccia.

I core pezy-sc2 hanno bisogno di core MIPS (prima avevano ARM) per coordinare il lavoro delle "tile" SC2. Questo significa che i programmatori sono costretti a scrivere DUE codici: quello che gira nelle tile SC2, e quello che gira nei MIPS che coordinano tutto il lavoro, e decidono se/come/quando spedire e recuperare poi il lavoro delle SC2.

Quindi, come dicevo prima, c'è molto più lavoro per i programmatori. Similmente a quanto avviene con nVidia / CUDA.

E' roba che si faceva con Xeon Phi (ma MOLTO più semplicemente) con le schede discrete, che però con Knights Landing sono state ormai dismesse. Quest'ultimo consente banalmente di far girare qualunque binario x86/x64 e con AVX-512.

Cioè, l'uso dei core MIPS per sfruttare 2048 unità MIMD è un problema mentre usare Xeon e core x86 per indirizzare i calcoli alle unità AVX (non chiamiamole più FPU perché qualcuno magari pensa che FPU è una parolaccia) o dover usare CUDA/OpenCL per sfruttare una GPU?

Sarà che forse hai uno strano modo di vedere tutto ciò che non è Intel o x86 based, ma ti faccio notare che anche altri sanno fare compilatori, framework, driver e librerie per astrarre quello che è il lavoro sotto il cofano necessario per fare le operazioni complesse.
E le PEZY-SC2 possono essere usate come unità indipendenti esattamente come le Xeon Phi, dato che su quei MIPS ci può benissimo girare un OS.

Tornando al primo punto della discussione, puoi parlare di un diverso (migliore o peggiore) supporto alla scheda, non che di principio usarne una piuttosto che un'altra sia più complicato.
Antonio2315 Novembre 2017, 13:39 #18
Originariamente inviato da: CrapaDiLegno
Tu che lo sai hai detto esattamente quello che ho detto io, infatti.
Per lo sfruttamento delle unità di elaborazione serve che le funzioni base siano scritte in librerie che vengono poi chiamate.
Ergo, per un programmatore se tali librerie siano per l'architettura A o B non cambia nulla. Non c'è difficoltà aggiunta a non usare x86.


Quote quindi, come detto sopra, lo sforzo di supportare l'architettura A piuttosto che B sta nel suggerire al compilatore e usare le librerie già fatte.
Sforzo aggiunto pari a quello di capire dove l'architettura ha problemi ed evitare di pestare continuamente quel punto.


non e' cosi', le intrinsics sono specifiche per una certa architettura. Cambiare architettura vuol dire usare intrinsics diverse,lo sforzo e' diverso. e te lo dico perche' ho portato decine di algoritmi tra diverse architetture DSP nel corso degli anni e l'uso di intrinsics e' la seconda causa principale (dopo il codice assembly) che rende il codice non portabile.
cdimauro15 Novembre 2017, 21:31 #19
Originariamente inviato da: CrapaDiLegno
Tu che lo sai hai detto esattamente quello che ho detto io, infatti.
Per lo sfruttamento delle unità di elaborazione serve che le funzioni base siano scritte in librerie che vengono poi chiamate.
Ergo, per un programmatore se tali librerie siano per l'architettura A o B non cambia nulla. Non c'è difficoltà aggiunta a non usare x86.

Quote quindi, come detto sopra, lo sforzo di supportare l'architettura A piuttosto che B sta nel suggerire al compilatore e usare le librerie già fatte.
Sforzo aggiunto pari a quello di capire dove l'architettura ha problemi ed evitare di pestare continuamente quel punto.

Su questo t'ha già risposto Antonio, ma aggiungo una cosa.

Non hai capito ed è evidente che non sai come funzioni e venga scritto codice HPC.

Le funzioni di libreria sono come i mattoncini Lego: sono strumenti che ti AIUTANO a risolvere i tuoi problemi, che però richiedono codice ad hoc, perché ovviamente i problemi di chi lavora in settori HPC non sono assolutamente tutti uguali. Tutt'altro.

Ma oltre al codice delle librerie, va "ovviamente" ottimizzato anche il codice che ne fa uso. In TUTTI E DUE i casi, se vuoi sfruttare al meglio l'architettura su cui gira il tuo codice (ed E' quello che vuoi fare, altrimenti non l'avresti comprata), ti serve adattare/modificare/riscrivere il tuo codice (per quello di libreria c'ha già pensato il produttore della libreria e/o della CPU. In mancanza, devi ottimizzartela tu la funzione/i che ti serve).

L'ottimizzazione va dall'usare codice codice assembly (molto raro: è troppo costoso da scrivere e testare. Ecco perché in genere, se c'è, si trova nelle funzioni di libreria), agli intrinsic di cui parlavo prima, ad apposite #pragma, opzioni di compilazioni, etc.. In ogni caso ti leghi mani e piedi (specialmente nel caso di assembly e intrinsic) alla specifica architettura.

Dunque è l'esatto contrario di quello che sostieni.
Scusa, non so cosa tu e lucusta intendiatre per FPU, per me sta per Floating Point Unit. Le AVX lavorano forse con gli interi?

Lavorano con gli interi e coi numeri in virgola mobile. Esattamente come le FPU, visto che supportano entrambi i tipi di dati, a dispetto del nome.

Il punto, però, era ed è che FPU e AVX sono completamente diverse, visto che sono unità diverse (e le micro-architetture possono anche avere porte/unità d'esecuzione del tutto disgiunte).

Ma sono tutte cose che sono ovvie a chi sa cosa siano queste unità d'esecuzione, come funzionano, e come vengono usate in ambito HPC (dov'è lapalissiano che un'FPU non ha diritto di cittadinanza, visto che un'unità SIMD fa di gran lunga meglio il suo lavoro. A meno che non sia assolutamente necessaria una maggior precisione, e qui l'unica architettura che la offre è x86 con l'FPU x87, oppure soluzioni dedicate).
La sinergia ce l'hai con l'architettura x86 che la NECESSITA, altre architetture non necessitano sinergie con core esterni per fare i conti (tipo GPU).
Ah, e per evitare ulteriori derive all'argomento, intendo nella parte attiva dei conti. Ovvio che anche le GPU necessitano di un componente esterno che organizzi il lavoro e faccia da interfaccia al resto (come lo necessitano anche le Phi con gli Xeon a corredo).

Ancora una volta dimostri di non avere la benché minima idea degli argomenti in cui ti sei infilato. E d'altra parte uno che scrive "nella parte attiva dei conti" difetta completamente della conoscenza basilare nonché della nomenclatura utilizzata nella letteratura.

Ancora una volta, assolutamente no: la sinergia di cui parli in quello specifico contesto ce l'ha x86, gli stream processor delle GPU di nVidia, i core PEZY-SC2, e così via. Perché per effettuare i calcoli veri e propri ti servono le unità vettoriali E (congiunzione) anche altre unità di calcolo "scalari/intere" (nonché di load/store) per eseguire altri calcoli senza i quali le unità vettoriali starebbero a girarsi i pollici.

La differenza fra Xeon Phi (Knights Landing in versione chip, e non scheda discreta) e nVidia/SC2/etc. (in genere tutte le soluzioni hardware che lavorano come coprocessori. Incluse Xeon Phi su scheda, ovviamente) è che non serve nessun core aggiuntivo per smistare il lavoro e i dati ai core dei coprocessori: dati e codice sono già immediatamente disponibili (nella memoria principale, che è condivisa da tutti i core), e serve soltanto lanciare i processi per avviare l'elaborazione (cosa molto più semplice e veloce: è parte del s.o.).

Si tratta, per chiarire, dello stesso motivo per cui le CPU moderne continuano ad avere unità SIMD, che sono via via sempre più potenziate, nonostante ci siano GPU in grado di processare molti più dati IN LINEA TEORICA. Ma a livello pratico il costo dell'operazione di offloading uccide le prestazioni e rende conveniente continuare a usare le unità SIMD.
Dal mio link.. si vede che quando non hai nulla da dire ti piace confondere la gente.. dal mio link , è quello che ti ho scritto IO!
Per te 16TFLOPS in FP16 sono pochi? E 4TFLOPS in FP64?
Probabilmente hai letto le specifiche della vecchia versione (o quelli della scheda Intel) e ora ti stai arrampicando sugli specchi, perché dire che fa grandi numeri in FP32 e pochi in FP64 e FP16, quindi non adatta a HPC e DeepLearning, quando questi valori sono in perfetto scaling con le prestazioni FP32 vuol dire aver preso una enorme cantonata.

I dati, come peraltro avevo già scritto, li ho presi direttamente dalla paginetta di cui hai fornito il link, come avresti potuto facilmente e banalmente verificare, invece di tergiversare.

Da quella pagina è evidente, se ancora non ti fosse chiaro, che PEZY-SC2 nasce per operazioni in virgola mobile a precisione singola, visto che parliamo di un paio di ordini di grandezza di differenza.

Sulla carta avrebbe prestazioni elevate anche in FP64 e FP16, ma sistemi custom come questo hanno soltanto sulla carta prestazioni elevate, ma con codice reale è molto, molto difficile riuscire ad avvicinarsi ai dati di targa. Peggio ancora con tipi di dati per cui non sono nati. Dunque dubito fortemente che siano papabili anche per l'HPC o l'IA.
Che non ha per nulla ragione, dato che i consumi non sono solo dovuti al fatto che la scheda va a palla ma anche a tutto il resto (tipo quanti dati scambi sui canali di memoria e che tipo di conti fai).
La potenza teoria non la raggiungi sempre (anzi praticamente mai), quindi non sei mai a potenza massima se non per pochissimo tempo.

Questo, come dicevo sopra, vale molto di più con soluzioni custom come queste.
Inoltre forse non avete letto bene che tipo di memoria secondaria può usare.

Sì, e d'altra parte ha talmente poca cache integrata, che ha bisogno di compensare questa enorme lacuna.

Solo che la DRAM ha di gran lunga latenze più elevate rispetto alle cache. Ed ecco che ritorna il discorso di cui sopra, sulle possibilità di avvicinarsi ai numeri teorici.
Secondo le dichiarazioni di Intel, sono in crescita le versioni standalone, non le acceleratrici discrete. Ci sarà un motivo perché le prime non sono per HPC mentre le seconde sono state cancellate da Intel.

Ovvio. Ed è una cosa che avevo scritto parecchio tempo fa, anche quando arrivò la notizia della dismissione degli Xeon Phi su scheda.

Le motivazioni le ho espresso sopra. D'altra parte con Knights Landing non ha proprio più senso sprecare soldi e risorse per utilizzare un coprocessore, quando con un chip "tradizionale" puoi lavorare di gran lunga meglio.
Le Xeon Phi sono lì perché coprono un mercato più piccolo rispetto alle schede acceleratrici discrete che non sono autonome.

Assolutamente no. Sono lì perché le schede acceleratrici discrete non hanno più senso, visto che Xeon Phi "versione chip" è di gran lunga più conveniente sotto tutti i punti di vista.
Il vantaggio quindi è altro rispetto alla vera capacità computazionale in cui sono state scalzate da altre architetture, e in prestazioni assolute e in efficienza (nonostante il PP migliore che Intel dice avere, figuriamoci a uguale PP che figura avrebbero fatto).

Questo su quale base lo affermi? Dati? Link?
Per riuscire a colmare il gap è necessario che le AVX così come sono messe oggi siano riviste

E' stato già fatto, infatti: si chiamano AVX-512. Che sono di gran lunga diverse dalle AVX, e orientate al massiccio calcolo.
e molto probabilmente saranno usate come cluster in die separati e "incollati" tra di loro.

Di cui non v'è nulla nella notizia. Nemmeno la minima traccia.
Cioè, l'uso dei core MIPS per sfruttare 2048 unità MIMD è un problema mentre usare Xeon e core x86 per indirizzare i calcoli alle unità AVX (non chiamiamole più FPU perché qualcuno magari pensa che FPU è una parolaccia) o dover usare CUDA/OpenCL per sfruttare una GPU?

Lo è, certamente. E di questo ne è ben cosciente chi sa come funzionano sia gli Xeon Phi sia le soluzioni come coprocessori. Vedi sopra quando ho discusso di entrambe le tipologie.
Sarà che forse hai uno strano modo di vedere tutto ciò che non è Intel o x86 based,

Diciamo che avendo lavorato per 3 anni e mezzo in ambito HPC, so vedere molto bene le differenze fra i vari approcci.

Tu, invece, che esperienza puoi vantare SUL CAMPO? Da quel che hai scritto non hai la minima idea di come funzioni queste soluzioni, e di come si scriva codice per il mercato HPC.
ma ti faccio notare che anche altri sanno fare compilatori, framework, driver e librerie per astrarre quello che è il lavoro sotto il cofano necessario per fare le operazioni complesse.

Mai detto nulla del genere. Ma Intel ha un'enorme esperienza sul campo, e i suoi compilatori sono famosi per generare codice particolarmente ottimizzato e autovettorizzante.
E le PEZY-SC2 possono essere usate come unità indipendenti esattamente come le Xeon Phi, dato che su quei MIPS ci può benissimo girare un OS.

I due approcci sono TOTALMENTE DIVERSI. Xeon Phi versione scheda acceleratrice era simile a SC2, ma quello "singolo chip" è tutta un'altra cosa.
Tornando al primo punto della discussione, puoi parlare di un diverso (migliore o peggiore) supporto alla scheda, non che di principio usarne una piuttosto che un'altra sia più complicato.

E invece ne posso proprio parlare perché so benissimo come funzionano entrambe le piattaforme.

Tu, invece, non hai ancora capito nemmeno come funzionino in linea di principio: figuriamoci come si scrive il codice per sfruttarle.

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