Niente più Knights Hill nelle roadmap Intel per i supercomputer

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

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.

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.

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.

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]

Su questo t'ha risposto lucusta.

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

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.

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

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.

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.


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


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


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.


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.


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.


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.


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.

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.

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

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.

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.

Questo, come dicevo sopra, vale molto di più con soluzioni custom come queste.

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.

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.

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.

Questo su quale base lo affermi? Dati? Link?

E' stato già fatto, infatti: si chiamano AVX-512. Che sono di gran lunga diverse dalle AVX, e orientate al massiccio calcolo.

Di cui non v'è nulla nella notizia. Nemmeno la minima traccia.

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.

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.

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.

I due approcci sono TOTALMENTE DIVERSI. Xeon Phi versione scheda acceleratrice era simile a SC2, ma quello "singolo chip" è tutta un'altra cosa.

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.