Link alla notizia: https://www.hwupgrade.it/news/cpu/nuvia-vuole-scuotere-il-mercato-delle-cpu-server-e-mostra-numeri-da-paura_91360.html

In un post sul proprio blog la startup NUVIA, creata da ex ingegneri di Apple e Google, presenta alcune proiezioni comparative tra il proprio core Phoenix, ancora in via di sviluppo, e i core di altre realtà, tra cui AMD e Intel. NUVIA mostra prestazioni e consumi senza precedenti, ma è tutto troppo bello per essere vero?

Click sul link per visualizzare la notizia.

Vabbè ma questi non sono niente, se vi mostro i numeri della mia CPU immaginaria sono da andar fuori di testa, ho fatto anche dei benchmark nella mia testa e hanno dato +60% di prestazioni rispetto al più potente xeon.

Vabbè ma questi non sono niente, se vi mostro i numeri della mia CPU immaginaria sono da andar fuori di testa, ho fatto anche dei benchmark nella mia testa e hanno dato +60% di prestazioni rispetto al più potente xeon.

Pivello, ho delle slide della mia CPU turboemotional che in single core doppia il Frecciarossa Roma-Milano e ti fa il resto in bitcoin

Da questo grafico si direbbe che A13 Lighting vada piu di sunny cove

Da questo grafico si direbbe che A13 Lighting vada piu di sunny cove

Secondo geekbench in single core quelle due cpu hanno prestazioni simili, sul sito sono indicati anche i punteggi nei vari sottotest, anche quelli abbastanza simili tra loro, non sembrano esserci elementi che falsano il test tipo gonfiare i risultati dell'A13 testando feature accelerate in hardware, mentre arranca nel resto

geekbench = spazzatura.

Avrebbero potuto usare SPECint e SPECfp, che sono standard industriali nonché il punto di riferimento.

geekbench = spazzatura.

Avrebbero potuto usare SPECint e SPECfp, che sono standard industriali nonché il punto di riferimento.

Magari hanno provato e i risultati non erano altrettanto "da paura". :D

LOL :asd:

Magari hanno provato e i risultati non erano altrettanto "da paura". :D

Già, ma considerando quello che dicono nel loro blog E i test fatti da Anantech usando proprio specInt e specFP (in cui confrontano Graviton 2, EPYC e Xeon ) viene da pensare che un 128 core con armv8.1 ed SVE2 dovrebbe viaggiare circa al doppio delle prestazioni degli x86-64 attuali a parità di TDP.
Insomma, le sparano grosse, ma mi sa che i chip che realizzeranno saranno decisamente interessanti.

Stai parlando di prestazioni in multicore, però, e di prodotti diversi da questi di NUVIA, che finora non hanno mostrato niente.
Inoltre bisogna vedere quali incrementi effetti porteranno le SVE2 (le ARMv8.1, invece, sono già state introdotte da tempo).

Stai parlando di prestazioni in multicore, però, e di prodotti diversi da questi di NUVIA, che finora non hanno mostrato niente.
Inoltre bisogna vedere quali incrementi effetti porteranno le SVE2 (le ARMv8.1, invece, sono già state introdotte da tempo).
Le aggiunte al set d'istruzioni serve a dare più opzioni implementative a chi realizza la microarchitettura.
Ho parlato di ARMv8.1 perché é il "livello base" per realizzare sistemi con un elevato numero di core con primitive di sincronizzazione efficienti.
Inoltre si è già visto che SVE va molto bene per il calcolo matriciale/vettoriale, SVE2 è la versione migliorats e permette di dimensionare le ALU vettoriali in modo più flessibile visto che lo stesso codice sviluppato per una implementazione con ALU vettoriali a 256bit riesce a sfruttare al massimo (senza ricompilare) anche un implementazione con ALU a 128bit come pure una a 512bit o più.

Dei tizi di NUVIA si sa che conoscono bene il loro mestiere e si sa cosa hanno contribuito a realizzare.

Infine ho tirato in ballo le prestazioni multicore perché inevitabilmente saranno proposti in configurazioni multicore e Graviton2 è un implementazione già disponibile di cui si possono vedere le prestazioni reali.

Sì, ma quanti server utilizzano le istruzioni SIMD? Purtroppo ben pochi, visto che per lo più si affidano a codice intero/scalare, ed eventualmente in virgola mobile.
I processori di NUVIA non sono destinati a HPC (dove le SIMD sono molto usate), ma a server, e quindi mi aspetto benchmark con questo tipo di applicazioni.

Ovviamente nei server sono importanti anche le prestazioni multicore, ma sarebbe interessante analizzare sistemi a parità di core.

Sì, ma quanti server utilizzano le istruzioni SIMD? Purtroppo ben pochi, visto che per lo più si affidano a codice intero/scalare, ed eventualmente in virgola mobile.
I processori di NUVIA non sono destinati a HPC (dove le SIMD sono molto usate), ma a server, e quindi mi aspetto benchmark con questo tipo di applicazioni.

Ormai sui server gira di tutto, mica solo i classici gestionali, inoltre SVE permette di fare codice ottimizzato che passa da SIMD a scalare in automatico e può essere utilizzato anche per roba "banale".
Considerando quanto siano diffuse le architetture con estensioni SIMD anche su x86, non mi stupirei se anche software "scalare" non si avvantaggi di esse per avere dei registri in più visibili al programmatore e per certi tipi di elaborazioni che si prestano bene ad essere ottimizzate, ad esempio:
- Confronto di stringhe usando SSE4.2 (https://www.strchr.com/strcmp_and_strlen_using_sse_4.2)
- Ricerca di sottostringhe (http://0x80.pl/articles/simd-strfind.html)
- Quicksort con AVX512 (https://arxiv.org/pdf/1704.08579.pdf)
- Conversione da intero a rappresentazione decimale in ascii (https://github.com/miloyip/itoa-benchmark) (in questo caso solo branchlut (https://github.com/miloyip/itoa-benchmark/blob/master/src/branchlut2.cpp) riesce a competere ... fino ad un certo punto)
- Codifica base64 (http://0x80.pl/notesen/2016-04-03-avx512-base64.html) (usata ad es. per codificare file binari nelle email)


Ovviamente nei server sono importanti anche le prestazioni multicore, ma sarebbe interessante analizzare sistemi a parità di core.

Il problema è che se a parità di tecnologia, costo e budget energetico puoi realizzare una cpu A con 64 core ed una cpu B con 8 core, il confronto non sarebbe proprio uguale se lo si fa a parità di core.

Ormai sui server gira di tutto, mica solo i classici gestionali, inoltre SVE permette di fare codice ottimizzato che passa da SIMD a scalare in automatico e può essere utilizzato anche per roba "banale".
Per "scalare in automatico" mi auguro che tu intenda soltanto che l'ampiezza dei dati manipolati varii in base all'implementazione delle unità SIMD (registri vettoriali a lunghezza variabile), ma che con quel codice NON si voglia coprire anche il codice intero/scalare. Se è così siamo d'accordo.
Considerando quanto siano diffuse le architetture con estensioni SIMD anche su x86, non mi stupirei se anche software "scalare" non si avvantaggi di esse per avere dei registri in più visibili al programmatore e per certi tipi di elaborazioni che si prestano bene ad essere ottimizzate, ad esempio:
- Confronto di stringhe usando SSE4.2 (https://www.strchr.com/strcmp_and_strlen_using_sse_4.2)
- Ricerca di sottostringhe (http://0x80.pl/articles/simd-strfind.html)
- Quicksort con AVX512 (https://arxiv.org/pdf/1704.08579.pdf)
- Conversione da intero a rappresentazione decimale in ascii (https://github.com/miloyip/itoa-benchmark) (in questo caso solo branchlut (https://github.com/miloyip/itoa-benchmark/blob/master/src/branchlut2.cpp) riesce a competere ... fino ad un certo punto)
- Codifica base64 (http://0x80.pl/notesen/2016-04-03-avx512-base64.html) (usata ad es. per codificare file binari nelle email)
Quasi tutti questi casi sono ormai normali e ben noti, tranne quello per la conversione da intero a stringa che mi ha sorpreso non poco: devo dire che è abbastanza originale come trovata, anche se il codice è basato per lo più sulla migliore versione scalare (dal quale si distanzia poco). Unico appunto: c'è troppo codice, per un algoritmo che "in forma tradizionale" occupa una manciata di righe.

Comunque, e come dicevo, quelli elencati sono casi "da manuale". Purtroppo il codice SIMD non è così diffuso. La situazione migliorerà sicuramente in futuro, ma è un lento progresso.
Il problema è che se a parità di tecnologia, costo e budget energetico puoi realizzare una cpu A con 64 core ed una cpu B con 8 core, il confronto non sarebbe proprio uguale se lo si fa a parità di core.
Certamente, ma a me piacerebbe avere ANCHE il dato confrontando sistemi con gli stessi core, per vedere come si comporti la micro-architettura.

Per "scalare in automatico" mi auguro che tu intenda soltanto che l'ampiezza dei dati manipolati varii in base all'implementazione delle unità SIMD (registri vettoriali a lunghezza variabile), ma che con quel codice NON si voglia coprire anche il codice intero/scalare. Se è così siamo d'accordo.
Si, come hai detto.
Uno dei vantaggi è che questo elimina alla radice il problema del dover modificare i sorgenti e/o ricompilare per sfruttare le "nuove istruzioni" (codice SIMD per SSE che poi va riscritto/aggiornato per SSE2, AVX, AVX-512, ecc.). E da molta più liberta nella realizzazione di soluzioni big-LITTLE non come l'accrocchio che ha fatto Intel con core "big" con AVX-512 e core "little" con AVX2.


Quasi tutti questi casi sono ormai normali e ben noti, tranne quello per la conversione da intero a stringa che mi ha sorpreso non poco: devo dire che è abbastanza originale come trovata, anche se il codice è basato per lo più sulla migliore versione scalare (dal quale si distanzia poco). Unico appunto: c'è troppo codice, per un algoritmo che "in forma tradizionale" occupa una manciata di righe.

Comprendo, roba troppo ingombrante rischia di trashare la cache, ma se implementata nelle funzioni di libreria o al limite rendendola inline solo in loop critici "che stanno in cache" quelle routine fanno una bella differenza in un sacco di applicazioni "classiche".


Comunque, e come dicevo, quelli elencati sono casi "da manuale". Purtroppo il codice SIMD non è così diffuso. La situazione migliorerà sicuramente in futuro, ma è un lento progresso.

Già. :( E questo nonostante che su x86-64 il set d'istruzioni "garantito" include le SSE2, su aarch64 le NEON, e che GCC ed altri compilatori supportano l'auto-vettorizzazione del codice (riescono a "parallelizzare" i pattern di codice più semplici, per quelli più complessi non so).

Si, come hai detto.
Uno dei vantaggi è che questo elimina alla radice il problema del dover modificare i sorgenti e/o ricompilare per sfruttare le "nuove istruzioni" (codice SIMD per SSE che poi va riscritto/aggiornato per SSE2, AVX, AVX-512, ecc.).
Sì, questo vantaggio è evidente. Ma ne parlo meglio alla fine.
E da molta più liberta nella realizzazione di soluzioni big-LITTLE non come l'accrocchio che ha fatto Intel con core "big" con AVX-512 e core "little" con AVX2.
Questo non è molto diverso dal fornire core ARM "big" con SVE, e little col classico NEON.
Comprendo, roba troppo ingombrante rischia di trashare la cache, ma se implementata nelle funzioni di libreria o al limite rendendola inline solo in loop critici "che stanno in cache" quelle routine fanno una bella differenza in un sacco di applicazioni "classiche".
Dovrebbero abilitarle impostando un flag di compilazione -ox (extreme) :D
Già. :( E questo nonostante che su x86-64 il set d'istruzioni "garantito" include le SSE2, su aarch64 le NEON, e che GCC ed altri compilatori supportano l'auto-vettorizzazione del codice (riescono a "parallelizzare" i pattern di codice più semplici, per quelli più complessi non so).
Perché, per l'appunto, non è facile vettorizzare il codice, a prescindere se parliamo di SIMD tradizionale o del paradigma "vector" (o "dynamic vectoring" AKA registri vettoriali a dimensione variabile) che è tornato di moda.

Ma ciò che i promotori di quest'ultimo non dicono è che non è sempre possibile trattare lo stream di dati in maniera omogenea, cioè come una sequenza di dimensione variabile. Infatti ci sono tipologie di codice dove è necessario manipolare vettori a dimensione fissa.

Ti passo un link a un articolo dell'evangelizzatore di RISC-V e del paradigma "vector", David Patterson, il cui titolo è già tutto un programma: SIMD Instructions Considered Harmful (https://www.sigarch.org/simd-instructions-considered-harmful/). :rolleyes:
Ma la parte più interessanti sono i commenti, dove alcuni intervengono contestando il pezzo per alcune cose, fra cui qualcuno facendo esempi che ricadono in quello che ho detto sopra, e come puoi vedere "stranamente" il prof. Patterson non interviene. :stordita:
Peraltro sempre il suddetto prof. i confronti con x86 li ha vergognosamente fatti soltanto col codice a 32 bit, "ignorando" quello a 64 bit che consente di ridurre il numero di istruzioni eseguite, come gli hanno fatto notare nei commenti.
Dulcis in fundo, non ha nemmeno messo un esempio con AVX-512 che, pur necessitando di codice di "fringing", risolve il problema in maniera di gran lunga più elegante (rispetto a tutte le altre estensioni SIMD classiche) nonché efficiente.
E poi, vabbé, non ha nemmeno citato le SVE di ARM, che sono anch'esse estensioni "vettoriali", e dunque dirette concorrenti del suo amato RISC-V...

Quindi, sì, il paradigma vector è certamente molto utile in tanti casi, anche molto comuni, ma non rappresenta affatto la soluzione finale al problema del massiccio processamento dei dati usando unità di calcolo parallele.

Infatti nella mia architettura ho previsto l'esecuzione contemporanea/mista di codice SIMD tradizionale (SSE, AVX-/2, AVX-512, e una futura AVX-1024) con codice "vettoriale" (rimuovendo il supporto alle MMX e rimpiazzandolo con quello "vector"), quindi dando massima libertà agli sviluppatori e ai compilatori di decidere come meglio organizzare il codice. Il tutto usando esattamente le stesse istruzioni (la mia ISA è totalmente ortogonale: la stessa istruzione può lavorare indifferentemente con una delle citate estensioni).
E aggiungo anche i vantaggi di usare pure tutte le caratteristiche addizionali previste dalla mia ISA per qualunque istruzione. In particolare, nello specifico:
- modalità d'indirizzamento di pre-post/inc-decremento --> rimozione delle istruzioni di "aggiustamento" dei puntatori;
- caricamento & broadcasting di valori immediati come seconda/terza "sorgente" --> rimozione delle apposite istruzioni di load & broadcast;
- possibilità di evitare di inquinare le cache con alcuni dati --> rimozione delle apposite istruzioni che "marcano" delle zone di memoria come "non-cachable/evict";
e... tanto altro ancora.