Hardware Upgrade Forum

Hardware Upgrade Forum (https://www.hwupgrade.it/forum/index.php)
-   News (https://www.hwupgrade.it/forum/forumdisplay.php?f=51)
-   -   Niente più Knights Hill nelle roadmap Intel per i supercomputer (https://www.hwupgrade.it/forum/showthread.php?t=2834585)


Redazione di Hardware Upg 14-11-2017 10:41

Link alla notizia: http://pro.hwupgrade.it/news/server-...ter_72328.html

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

Click sul link per visualizzare la notizia.

AceGranger 14-11-2017 11:47

Quote:

Originariamente inviato da Veradun (Messaggio 45172933)
Ed ecco che il progetto Larrabee muore definitivamente dopo essere fallito miseramente come GPU ed essere stato riciclato per altro.

in campo HPC, come schede acceleratrici, nVidia ha fatto terra bruciata.


Intel negli ultimi anni sembra arrivare sempre un passo dopo gli altri, e ultimamente poi si sta facendo fregare da nVidia in tutti i nuovi mercati.

coschizza 14-11-2017 12:04

Quote:

Originariamente inviato da AceGranger (Messaggio 45173127)
in campo HPC, come schede acceleratrici, nVidia ha fatto terra bruciata.


Intel negli ultimi anni sembra arrivare sempre un passo dopo gli altri, e ultimamente poi si sta facendo fregare da nVidia in tutti i nuovi mercati.

guardando le clessifiche di vendita dei computer HPC non si direbbe proprio visto che le schede intel sono largamente usate e sono anche nella top 10 su piu sistemi

AceGranger 14-11-2017 12:19

Quote:

Originariamente inviato da coschizza (Messaggio 45173191)
guardando le clessifiche di vendita dei computer HPC non si direbbe proprio visto che le schede intel sono largamente usate e sono anche nella top 10 su piu sistemi

ho dimenticato di segnare anceh workstation e calcolo intesivo :D

i PHI li stanno dismettendo perchè non riescono a tenere il passo con le GPU nVidia e non si è creato quell'ecosistema che Intel sperava si creasse.

le Tesla le vendono anche in workstation e trovano una miriade di applicazioni con software di terze parti gia pronti, le PHI, tolti gli accordi che fa Intel, non se le compra quasi nessuno e le prendono solo realta che poi si sviluppano anche il software.

CrapaDiLegno 14-11-2017 13:09

Pilotare decine di FPU con decine di core x86 era una idea sciocca che non poteva portare a risultati diversi. Ma era Intel e c'è voluto un po' perché gli investimenti scadessero e la concorrenza con duro lavoro lo dimostrasse (aiutata anche da i nuovi PP, vedesi miei antichi commenti sul fatto che i nuovi PP della concorrenza sarebbero stati una spina nel fianco per Intel non solo per quanto riguardava il mercato mobile).

Il prossimo passo di Koduri credo infatti che sarà mettere le enormi unità AVX in una architettura mesh (ala GPU) senza core x86 in mezzo a rubare spazio e a succhiare inutili W.
D'altronde credo che anche Intel sia arrivata alla conclusione che l'architettura x86 non ha più il vantaggio che aveva prima (che era poi la quantità di transistor che poteva mettere in campo vs la concorrenza allo stesso prezzo e consumi) e nemmeno "l'avanzatissimo" PP che Intel proclama avere la aiuta più a coprire il gap che ha e da qualche anno sta cercando alternative, prima con le FPGA e ora con nuove architetture simil-GPU , ovviamente sempre collegate a x86, ma che sta prendendo un ruolo sempre più marginale rispetto a prima.
Anche Intel ha smesso di voler spingere x86 ovunque anche là dove non è adatta allo scopo.

In più altri contendenti sembrano interessati, come questi: https://en.wikichip.org/wiki/pezy/pezy-scx/pezy-sc2
Che già dimostrano come una architettura qualsiasi non necessariamente x86 può fare molto e anche meglio.

csavoi 14-11-2017 15:10

INTEL deve finalmente cedere un po' del suo orgoglio e ricominciare a lavorare.

Colpire in qualche modo NVIDIA, lo ha fatto con l'accordo di partnership con AMD per processori modulari INTEL con grafica VEGA.

Adesso, grazie all'acquisizione di Raja Koduri, non sarebbe improbabile pensare che AMD e INTEL convergano in un HW per Supercomputing condiviso (o per lo meno compatibile) in modo da non fare la fine di Labarree e creare i presupposti per un supporto software decente.

In Fondo se NVIDIA "ha sfondato" è anche per il supporto software che ha dato alle sue schede video.

cdimauro 14-11-2017 19:53

Non ci si dovrebbe fermare soltanto al titolo, senza approfondire con la notizia e magari senza nemmeno aver visto la press release originale, prima di commentare.

Si parla chiaramente che il progetto Knights Hill, e solo questo, è stato cancellato perché l'azienda sta lavorando a una nuova MICRO-architettura (e nuova piattaforma. Di contorno, quindi).

Dunque NON sarà una nuova ARCHITETTURA: quella rimarrà sempre x86/x64, che è ancora viva e vegeta nonostante i proclami di gufi, hater e novelli maghi Otelma, che la vorrebbero già morta da una 30ina d'anni ormai.

Com'è anche chiaro che l'arrivo di Koduri ha influito su queste decisioni. D'altra parte è ben noto che le GPU di AMD siano ben più votate ai calcoli GPGPU, rispetto a quelle nVidia.
Koduri ha contribuito grandemente allo sviluppo di tale architettura, per cui può ben contribuire anche allo sviluppo della prossima MICRO-architettura Intel votata al GPGPU-computing -> Xeon Phi.

Infine, è bene notare che soluzioni esotiche possano ovviamente fare molto meglio di soluzioni più "generali/generiche". Ed è ovvio che sia così. Com'è, però, anche ovvio che sfruttarle richieda molti più sforzi (codice e/o compilatori ad hoc), e in ogni caso tali soluzioni sono difficilmente riutilizzabili per altri scopi.
Infatti pezy-sc2 ha prestazioni stellari soltanto in virgola mobile a singola precisione, mentre di gran lunga inferiori per quelle a doppia o mezza precisione. Ergo: si chiama fuori da HPC e IA/deep-learning.

CrapaDiLegno 14-11-2017 20:45

Quote:

". Ed è ovvio che sia così. Com'è, però, anche ovvio che sfruttarle richieda molti più sforzi (codice e/o compilatori ad hoc), e in ogni caso tali soluzioni sono difficilmente riutilizzabili per altri scopi.
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.
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.
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.

Quote:

Infatti pezy-sc2 ha prestazioni stellari soltanto in virgola mobile a singola precisione, mentre di gran lunga inferiori per quelle a doppia o mezza precisione. Ergo: si chiama fuori da HPC e IA/deep-learning.
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. 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?
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).

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.


lucusta 14-11-2017 21:20

in realtà Intel ha annunciato di aver dismesso le schede addon xeon Phi, quelle discrete.
cosa già nota tre mesi fa, in cui ha smesso la produzione e mantenuto a magazzino uno stock per clienti particolari.

le CPU xeon Phi continueranno comunque lo sviluppo. secondo la roadmap.

rammento che le schede xeon Phi non erano altro che xeon Phi messi su scheda, dai quali, volendo, si poteva avviare anche un OS (non virtuale, ma nativo).

questo fa venire in mente che già 3 mesi fa c'era piu' di qualcosa nell'aria per la costituzione della nuova divisione grafica Intel, con questi personaggi...
queste cose non piovono certo dal cielo dall'oggi al domani, e sicuramente dietro c'è una strategia molto più profonda, che pian piano andremo a scoprire.

lucusta 14-11-2017 21:23

cdimauro, glie lo spieghi tu a capadilegno cosa sono le AVX512, perchè sentirle chiamare FPU....

lucusta 14-11-2017 21:36

Quote:

Originariamente inviato da CrapaDiLegno (Messaggio 45174611)
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.

lucusta 15-11-2017 00:39

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

cdimauro 15-11-2017 06:50

Quote:

Originariamente inviato da CrapaDiLegno (Messaggio 45174611)
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.
Quote:

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

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

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:

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

Quote:

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

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?
Quote:

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.

cdimauro 15-11-2017 06:55

Quote:

Originariamente inviato da Bellaz89 (Messaggio 45174884)
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à.

cdimauro 15-11-2017 07:14

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.

CrapaDiLegno 15-11-2017 13:29

Quote:

Originariamente inviato da cdimauro (Messaggio 45175169)
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.

Quote:

Originariamente inviato da cdimauro (Messaggio 45175169)
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.

Quote:

Originariamente inviato da cdimauro (Messaggio 45175169)
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?

Quote:

Originariamente inviato da cdimauro (Messaggio 45175169)
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).

Quote:

Originariamente inviato da cdimauro (Messaggio 45175169)
Dal tuo link:

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

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.

Quote:

Originariamente inviato da cdimauro (Messaggio 45175169)
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.

Quote:

Originariamente inviato da cdimauro (Messaggio 45175169)
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.

Quote:

Originariamente inviato da cdimauro (Messaggio 45175169)
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.

Quote:

Originariamente inviato da cdimauro (Messaggio 45175176)
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.

cdimauro 15-11-2017 21:31

Quote:

Originariamente inviato da CrapaDiLegno (Messaggio 45176037)
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.
Quote:

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

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

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

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

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

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

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

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?
Quote:

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

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

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

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

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

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

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.


Tutti gli orari sono GMT +1. Ora sono le: 07:37.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Hardware Upgrade S.r.l.

1