Torna indietro   Hardware Upgrade Forum > Hardware Upgrade > News

POCO X3 NFC: tanto a poco prezzo. Un altro best buy? La recensione
POCO X3 NFC: tanto a poco prezzo. Un altro best buy? La recensione
POCO è tornata con forza e dopo aver immesso sul mercato il nuovo POCO F2 Pro dalle specifiche tecniche esagerate per il prezzo di vendita ecco che propone per la prima volta un device di fascia media che sembra voler divenire un nuovo best buy. Ma sarà davvero così? Ecco la nostra recensione.
BenQ SW321C: il monitor per chi stampa fotografie
BenQ SW321C: il monitor per chi stampa fotografie
Grandi dimensioni, elevata fedeltà e una chicca non da poco per tutti coloro i quali, fotografi professionisti o appassionati esigenti, si trovano a gestire la catena scatto-sviluppo-stampa: BenQ SW321C è la soluzione ideale
ASUS VivoBook S15 M533IA: tutto al meglio, tranne lo schermo
ASUS VivoBook S15 M533IA: tutto al meglio, tranne lo schermo
Grazie al processore AMD Ryzen 7 4700U il notebook ASUS VivoBook S15 M533IA mette a disposizione un ideale bilanciamento tra la potenza di calcolo e silenziosità di funzionamento, permettendo molte ore di lavoro e svago lontano dalla presa di corrente ad un prezzo interessante. Purtroppo la qualità dello schermo ne sconsiglia l'acquisto, anche qualora fosse proposto ad un listino più contenuto
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 14-08-2020, 12:01   #1
Redazione di Hardware Upg
www.hwupgrade.it
 
Iscritto dal: Jul 2001
Messaggi: 75179
Link alla notizia: https://www.hwupgrade.it/news/cpu/nu...ura_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.
Redazione di Hardware Upg è offline   Rispondi citando il messaggio o parte di esso
Old 14-08-2020, 14:24   #2
Bradiper
Senior Member
 
Iscritto dal: Jul 2013
Messaggi: 837
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.
Bradiper è offline   Rispondi citando il messaggio o parte di esso
Old 14-08-2020, 14:32   #3
the_joe
Senior Member
 
L'Avatar di the_joe
 
Iscritto dal: May 2003
Città: Lucca
Messaggi: 10252
Quote:
Originariamente inviato da Bradiper Guarda i messaggi
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
the_joe è offline   Rispondi citando il messaggio o parte di esso
Old 14-08-2020, 14:34   #4
Tedturb0
Senior Member
 
Iscritto dal: Mar 2000
Città: BO[h]
Messaggi: 3978
Da questo grafico si direbbe che A13 Lighting vada piu di sunny cove
Tedturb0 è offline   Rispondi citando il messaggio o parte di esso
Old 14-08-2020, 15:08   #5
pengfei
Member
 
Iscritto dal: Aug 2017
Messaggi: 75
Quote:
Originariamente inviato da Tedturb0 Guarda i messaggi
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
pengfei è offline   Rispondi citando il messaggio o parte di esso
Old 15-08-2020, 05:57   #6
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 24775
geekbench = spazzatura.

Avrebbero potuto usare SPECint e SPECfp, che sono standard industriali nonché il punto di riferimento.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 15-08-2020, 08:51   #7
GTKM
Senior Member
 
L'Avatar di GTKM
 
Iscritto dal: Jan 2014
Messaggi: 3823
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
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".
GTKM è offline   Rispondi citando il messaggio o parte di esso
Old 15-08-2020, 09:10   #8
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 24775
LOL
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 16-08-2020, 00:19   #9
LMCH
Senior Member
 
Iscritto dal: Jan 2007
Messaggi: 3993
Quote:
Originariamente inviato da GTKM Guarda i messaggi
Magari hanno provato e i risultati non erano altrettanto "da paura".
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.
LMCH è offline   Rispondi citando il messaggio o parte di esso
Old 16-08-2020, 05:21   #10
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 24775
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).
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 17-08-2020, 04:46   #11
LMCH
Senior Member
 
Iscritto dal: Jan 2007
Messaggi: 3993
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
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.
LMCH è offline   Rispondi citando il messaggio o parte di esso
Old 17-08-2020, 06:15   #12
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 24775
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.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 19-08-2020, 18:12   #13
LMCH
Senior Member
 
Iscritto dal: Jan 2007
Messaggi: 3993
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
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
- Ricerca di sottostringhe
- Quicksort con AVX512
- Conversione da intero a rappresentazione decimale in ascii (in questo caso solo branchlut riesce a competere ... fino ad un certo punto)
- Codifica base64 (usata ad es. per codificare file binari nelle email)

Quote:
Originariamente inviato da cdimauro Guarda i messaggi
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.
LMCH è offline   Rispondi citando il messaggio o parte di esso
Old 20-08-2020, 05:46   #14
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 24775
Quote:
Originariamente inviato da LMCH Guarda i messaggi
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.
Quote:
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
- Ricerca di sottostringhe
- Quicksort con AVX512
- Conversione da intero a rappresentazione decimale in ascii (in questo caso solo branchlut riesce a competere ... fino ad un certo punto)
- Codifica base64 (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.
Quote:
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 iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 25-08-2020, 18:52   #15
LMCH
Senior Member
 
Iscritto dal: Jan 2007
Messaggi: 3993
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
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.

Quote:
Originariamente inviato da cdimauro Guarda i messaggi
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".

Quote:
Originariamente inviato da cdimauro Guarda i messaggi
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).
LMCH è offline   Rispondi citando il messaggio o parte di esso
Old 27-08-2020, 07:30   #16
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 24775
Quote:
Originariamente inviato da LMCH Guarda i messaggi
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.
Quote:
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.
Quote:
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)
Quote:
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.
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.
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.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


POCO X3 NFC: tanto a poco prezzo. Un altro best buy? La recensione POCO X3 NFC: tanto a poco prezzo. Un altro best ...
BenQ SW321C: il monitor per chi stampa fotografie BenQ SW321C: il monitor per chi stampa fotografi...
ASUS VivoBook S15 M533IA: tutto al meglio, tranne lo schermo ASUS VivoBook S15 M533IA: tutto al meglio, trann...
Xbox Series S: tutto quello che c'è da sapere Xbox Series S: tutto quello che c'è da sa...
MSI RTX 3080 GAMING X TRIO 10G, Nvidia Ampere in formato maxi MSI RTX 3080 GAMING X TRIO 10G, Nvidia Ampere in...
Xbox One X scambiata per Series X: recor...
Samsung Galaxy Buds Live: gli auricolari...
Royole Flexpai 2 annunciato ufficialment...
Samsung presenta il nuovo Galaxy S20 FE:...
Rembrandt, le APU Ryzen 6000 prodotte a ...
Migliori offerte Gearbest: smartphone Xi...
Intel lancia i processori Atom e Core de...
Intel, processori Tiger Lake in arrivo a...
Sienna Cichlid, Navy Flounder e Dimgrey ...
Facebook: volete tornare alla vecchia in...
Greg LeMond, campione del Tour de France...
Nuovo proiettore portatile XGIMI MoGo Pr...
Adobe Photoshop: in arrivo lo strumento ...
Ora che Bethesda è di Microsoft, ...
Stangata alla pirateria in Italia: 58 si...
Driver Booster
3DMark
K-Lite Codec Pack Update
K-Lite Mega Codec Pack
K-Lite Codec Pack Full
Iperius Backup
NTLite
Firefox Portable
Dropbox
Firefox 81
Google Chrome Portable
MSI Afterburner
Chromium
PowerDVD
OCCT
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 04:01.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Served by www2v
1