Benchmark ed STM sui Ryzen.

[lucusta]

Anche in questo periodo l'insonnia si fa sentire e dopo una serata tra amici non riuscivo comunque a prendere sonno.
ho cominciato quindi a pensare a questo argomento.
I ryzen stanno andando forte, ma saranno giustamente supportati, anche oggi, dall'OS e dai giochi? ma soprattutto, saranno ben testati?
la particolare architettura di Zen e l'implementazione sui processori comporta una complicazione leggermente maggiore nel valutarli, nell'usarli e nell'essere sfruttati.
Purtroppo, per ora, l'unico esemplare di ryzen che ho in mio possesso è un 3400G (due, in verità... uno sul portatile).
La domanda che mi sono posto è se la concorrenzialità su alcune caratteristiche della CPU possa compromettere le prestazioni.
i Ryzen sono suddivisi a più stadi: una CPU è divisa in CCX, ogniuno di questi CCX è formato da 4 core, la L3 associata direttamente a questi quattro core e indirettamente anche alla L3 degli altri CCX; questi CCX sono suddivisi, a loro volta, in 2 moduli da 2 core "fisici", con la L2 abbinata al singolo core, sul quale ha accesso anche l'altro core del modulo in maniera indiretta e ancora con più passaggi un core di un'altro modulo.
a questo si aggiunge l'SMT, ossia quella che è descritta come la funzione che permette di sfruttare le risorse non sfruttate di un core con altri thread operati in simultanea; descrizione molto semplicistica, visto che "le risorse" non sfruttate di questi core sono intere pipeline di calcolo fatte e finite.
Tutte queste organizzazioni sono collegate da bus ed è qui che avviene la "concorrenzialità" delle risorse, ossia proprio sullo sfruttamento dei bus di comunicazione.

nella pratica mi sono chiesto quanta differenza c'è nell'usare 2 threads contemporaneamente sul singolo core fisico (ossia sui 2 core logici di un core fisico) e invece su 2 core fisici differenti.
se i 2 threads usanolo stesso core useranno anche gli stessi bus dati e quindi subiranno parte di questa convivenza?
da questa domanda sono partite diverse altre.
windows è realmente pronto a gestire i flussi a seconda del tipo, qualità e quantità di threads che deve eseguire, o li alloca a "come capita capita"?
e se pur avendo una gestione oculata delle risosre, tanto da poter sistemare i threads sulla migliore risorsa disponibile in quel momento, quando questi (threads ad elevata richiesta di risorse) superano il conteggio dei core fisici, come fa a decidere quali usare ed è sempre giusto quello che fa?

oggi ho fatto alcuni test.
per prima cosa ho usato un benchmark che potesse saturare il computo di uno o più core, quello integrato in CPU-Z;
ho usato più di un'istanza in concomitanza e mi sono avvalso del settaggio dell'affinita con i core da gestione risorse.
Come nota posso dire che Ryzen master mi indica il quarto core come "prediletto".

3400G, settaggio a default, senza PBO abilitato;
benchmark CPU-Z usato con l'esecuzione di 8 threads;
affinità di CPUZ.exe solo sul core0;
il risultato del benchmark ha dato 465-470 punti a 3.95-4.00Ghz massimo.
per essere sicuro ho testato tutti i core logici nella stessa modalità, aspettando che le temperature si riportassero a valori normali.
core0; 3.95Ghz; 465 punti
core1; 4.00Ghz; 470 punti
core2; 3.80Ghz; 455 punti
core3; 3.80Ghz; 455 punti
core4; 3.80Ghz; 460 punti
core5; 3.80Ghz; 455 punti
core6; 3.80Ghz; 455 punti
core7; 3.80Ghz; 460 punti
già qui vediamo che il bios nomina core0/core1 il 4° core fisico della CPU, quindi che non c'è relazione di nomenclatura dei core tra ryzen master e la gestione dei core di windows.

ora andiamo alle questioni interessanti, ossia usare 2 istanze di CPU-Z, settate con 8 threads, e ogniuna di queste istanze affiliate a 2 core distinti.
usando core0 + core1 i risultati sono:
core0 320 punti
core1 325 punti
frequenza indicata su task manager di 4.06Ghz (non ho voluto guardare le frequenze in dettaglio, core per core, con HWmonitor... semmai lo farò in seguito.
(nota: il PC completamente piantato, con evidenti lag del mouse).

usando invece core0 + core2:
core0 470 punti
core2 465 punti
frequenza di 4.06Ghz.
(PC piantato con evidenti lag del mouse, almeno finchè entrambe le sessioni di CPU-Z sono attive).
più tardi rifarò i test in modo più compreto, usando anche hwmonitor per vedere le frequenze di tutti i core mentre eseguo i test.

il secondo esperimento è stato di usare 4 core all'unisono con una istanza di CPU-Z attiva.
core0 1250 punti 4.00Ghz
core1
core2
core3

core0 1545 punti con la frequenza che oscillava tra 4.01 e 4.03Ghz.
core1
core2
core4

core0 1800 punti con frequenza che oscillava tra 4.03 e 4.04ghz.
core2
core4
core6

usato senza affinità dei core, ma su tutti i core il risultato è stato di 2400 punti con la CPU a 4.03Ghz.

più "simpatico" è stato testare il sistema su un benchmark di un gioco.
visto che ho una scarsissima 570 pulse, sono andato a ripescare un gioco vecchio, cercando di metterlo al minimo possibile delle richieste grafiche.
la scelta è andata sul vecchio Tomb Raider, in finestra a 1280x720, settaggi preset minimo e senza vsync attivo.
questi i risultati:

affinità core 0+1
min 128
max 246
medio 186.2

affinità core 0+2
min 172
max 304
medio 236.4

affinità core 0+1+2+3
min 264
max 436
medio 356.2

affinità core 0+2+4+6
min 326
max 496
medio 417.3

affinità core 0+1+2+3+4+5+6+7 (tutti)
min 342
max 502
medio 444.1

affinità core 0+2+3+4+5+6+7 (tutti meno il core1)
min 345
max 512
medio 448.4

l'ultimo test è il più significativo, perchè evidenzia come scaricare il core SMT associato al core fisico che regge il megathread del gioco lo libera nell'uso delle risorse, anche se questo core, con questi settaggi, non è mai andato, mai, al 100% d'uso, ma si è sempre mantenuto tra i 60 e l'80%.
come si può notare sugli altri risultati la differenza a pari numero di risorse sfruttate, ma a differente qualità di queste, è considerevole, ma in questo ultimo test abbiamo usato un'ammontare di potenza computazionale addirittura inferiore a quello dell'uso di tutti i core, eppure i risultati sono stati maggiori.
non immagino cosa possa succedere quando mettiamo in gioco anche i CCX diversi (il 3400G ne ha uno solo), o addirittura die differenti come nel 3900x e 3950x e quando prendiamo in esame le diverse tipologie di giochi, se focalizzati su pochi o tenti threads.
rifarò i test settando 800x600 o cercando qualche settaggio del gioco che mandi al 100% il megathread (abilito insomma l'AA per vedere se influisce maggiormente sulla CPU), o con qualche altro benchmark.

questo test evidenzia come l'uso di una GPU decisamente performante, ma usata a settaggi che rendono la CPU il vero collo di bottiglia, possano cambiare in modo sensibile i risultati dei test sui ryzen.

EDIT:
ho eseguito i test a 800x600, preset minimo con i seguenti risultati (solo sugli ultimi due setting)

affinità core: tutti
min 324
max 506
medio 453.1
il core0 oscillava tra 95% di massimo e 70% di minimo

affinità core: tutti meno core1
min 348
max 516
medio 457.2
il core0 questa volta ha toccato 100% per diversi secondi, oscillando tra 100 di massimo e 75% di minimo.

PS:
i valori numerici con il preset di prima possono essere differenti, perchè probabilmente è stato toccato qualche paramentro dell'overclock della scheda; purtroppo i driver hanno "sentito" che avevo istallato tomb raider e hanno creato un preset a parte, ponendolo a default e no usando quello che uso di solito che è leggermente più veloce.
comunque la rilevanza è sulla stessa sessione di test e preciso che il test con tutti i core associati è stato eseguito per primo rispetto a quello con il core1 non associato.

[lucusta]

https://www.techpowerup.com/review/amd- ... 00k/4.html
https://www.techspot.com/review/1882-ry ... on-vs-off/

in questi articoli c'è il tentativo di andare a guardare questo tipo di casistica con un 3900x.
l'errore è di aver disabilitato tutta la funzionalità dell'SMT, che in alcuni casi potrebbe essere deleteria perchè questa non è solo una tecnologia che permette di sfruttare le risorse non usate del singolo core, ma è anche sfruttata per riuscire a gestire threads "particolari" che la CPU (per i ryzen) riesce a riconoscere come "assimilabili".
in pratica vengono eseguiti 2 threads come se fosse uno soltanto, ma ad estensione di base doppia...

è lo steso processo logico che si aveva al passaggio da 16 a 32 bit e da 32 a 64 bit.
alcune istruzioni a base estesa non erano altro che 2 istruzioni concatenate di quella base, quindi il compilatore preparava questo tipo di codice, questo veniva decodificato dal decoder della CPU ed eseguito non alla base di riferimento, ma alla base inferiore, in simultanea.
questo era possibile perchè coadiuvati dal compilatore che costruiva il codice nella maniera più opportuna sfruttando queste istruzioni ben note e dichiarate.
ora che si è passati a 64 bit, ma che nei processori esistono più ALU complete, è possibile fare la stessa cosa?
sì.
ma se non è nell'ISA non è effettivamente sfruttabile.
e se questo processo non viene dichiarato nell'ISA esplicitamente, ma il compilatore lo esegue ugualmente grazie ad un flag di ottimizzazione?
verrà eseguita esclusivamente quando quel codice sarà processato sulla CPU relativa a quella ottimizzazione.

in pratica è stata questa la "forza" di Intel negli ultimi anni con i Core, ossia non aver esteso l'ISA a 128 bit, ma aver usato estendioni di ottimizzazione nel compilatore che lo facevano solo per certe CPU, sia che queste avevano HT o non avevano HT abilitato.

AMD non riesce ad accedere a questo codice espressamente compilato dall' ICC per gli Intel Core, ma ha superato questo ostacolo usando l'intelligenza artificiale dei ryzen che ricerca questo tipo d'istruzioni per poi associarle e farle eseguire sullo stesso core.
ma questa tecnica porta vantaggi limitati se non è espressamente sfruttata già in compilazione.

cio non toglie che se tu mi disabiliti l'SMT non hai nemmeno quel poco vantaggio che questa tecnologia sfruttata "on the fly" può darti, soprattutto su threads appartenenti a programmi diversi, non solo ai threads dello stesso programma.

quindi eliminare l'SMT dai ryzen non è sempre positivo, anche quando si usano programmi che hanno limitato uso di threads, perchè sarà direttamente windows a cercare di indirizzarli su core logici che non sono associati nello stesso modulo, ma windows non si preoccupa però della concomitanza di sfruttamento delle stesse risorse di un modulo, ossia dell'affollamento dei dati dovuti all'uso di 2 core sullo stesso bus dati sulla L2 e L3.

La differenza con gli Intel è proprio qui: Intel usa ring o mesh come bus, e questo e per tutti con la stessa dimensione e congeniato per non limitare la comunicazione quando più core sono in uso; quantomeno non limitare il computo a seconda del tipo di risorsa usata.
Su Zen ci sono tanti bus punto-punto, e potrebbero essere stati limitati in banda e tempistiche di accesso perchè renderli non limitanti significava farli diventare il doppio di quello che sono ora, quindi esosi di spazio; d'altronde AMD usa realmente tanti core, quindi più core significa più bus dati e se questi sono costruiti per non limitare la banda nell'uso di due (o più) core la loro somma sarebbe "impegnativa" sul die.
d'altra parte hanno cercato di limitare la concorrenza di risorse facendo gestire preferibilmente un core a modulo, e poi il secondo quando le richieste sono elevate... causerà un abbassamento generale della prestazione, ma già su un 12 core fisico sfruttato al massimo il problema potrebbe essere la banda RAM, quella sì limitante per via dei 2 soli moduli da poter utilizzare.

ciò non toglie che andare a sfruttare il core associato a quello su cui c'è il thread guida (il megathread) di un gioco , che generalmente non sfrutta tutti i core logici della CPU o comunque non li sfrutta al 100%, non è ottimale, perchè togliere tempo di esecuzione da quel thread, ad esempio dal bus dati sulla L2, significa avere minori prestazioni generali sul gioco.

ecco perchè, a mio avviso, converrebbe associare l'eseguibile del gioco a tutti i core meno quello che è associato a quello che regge il megathreads, perchè anche se questo non sarà mai sfruttato al 100%, potrà comunque contare su una ristrettezza delle sue risorse principali a causa dello sfruttamento delle stese risorse da parte dell'altro thread sull'altro core associato.

mi piacerebbe vedere il comportamento su alcuni benchmark di un 3700x, con una 2080 Ti (o con una scheda grafica che riesce a mandarlo a tavoletta, magari anche a settaggi bassi), su un gioco come Red Deat Redemption 2 o F1 2019, che fanno uso di numerevoli threads (RDR2 riesce a sfruttare tutti i core di un 3900x, a diversa percentuale d'uso, naturamente, mentre F1 2019 ne usa anche 12).
giusto per vedere come cambiano i risultati.

[lucusta]

altra serie di benchmark su tomb raider.
questa volta ho messo tutti i settaggi al massimo, estremo, con risoluzione 2560x1080, quindi con occupazione per singolo core decisamente bassa.

affinità core: tutti
min 60
max 98
medio 79

affinità core: 0+2+4+6
min 62
max 96
medio 78.7

affinità core: tutti meno core0
min 64
max 98
medio 80

SMT off (richiede il riavvio della macchina e mostra solo 4 core logici, ossia solo i core fisici).
min 60
max 92
medio 78.3

anche in questo caso il settaggio che non associa il core "affiliato" a quello che regge il megathread risulta essere complessivamente il più veloce, soprattutto per i minimi più alti e tutto questo con un'occupazione del core0 masima del 45% ed una frequenza che oscillava tra 3.2 e 3.5Ghz, quindi senza che la CPU fosse realmente stressata.

purtroppo sembra che windows non consideri proprio lo sfruttamento concorrenziale delle risorse di un Ryzen e questo incide anche quando le risorse non sono eccessivamente sfruttate.

PS:
ho usato tomb raider, quello del 2013, perchè è uno dei giochi che ho che usa almeno 8 threads ed ha una grafica sufficientemente leggera da poter sforzare il processore anche con la piccola 570.
con SMT off l'occupazione del singolo core risultava sensibilmente più alta, anche più alta dell'affinità con solo i 4 core fisici (0, 2, 4, 6).

mi piacerebbe avere qualche confronto con processori e schede grafice più performanti, per valutare effettivamente il peso di questa questione di concorrenzialità delle risorse.

[Bivvoz]

Seguo ma non posso esserti utile per un confronto, ho un 1700x e non mi sembra interessante inserire ancora un zen1.
Oggi dovrebbero ordinare in azienda un 3950x, quando arriverà vedrò se riesco a metterci mano per qualche bench.

[lucusta]

va benissimo anche il 1700x
quello che sto cercando di capire è come e quanto influisce la concorrenza delle risorse sui giochi.

le prove da fare sono semplici:
avvii il gioco normalmente;
fai il benchmark monitorando l'uso dei singoli core;
cerchi di capire quale sia il core con il megathread del gioco (di solito è semplice perchè è quello più intensamente usato; si riconosce anche perchè gli altri hanno andamenti simili e dipendenti dall'impegno grafico, mentre il megathread ha un uso più costante);
a quel punto devi capire quale sia il core associato e disabilitarlo, rifare il benchmark e vedere quanto cambia.
solitamente i core sono accoppiati a 2 a 2 (ossia i pari sono quello "fisico" ed i dispari quello SMT associato), ma in effetti non c'è una legge scritta, e quindi il core0 potrebbe esere associato al core7.
per capirlo con assoluta certezza dovresti usare due istanze di un benchmark sintetico come ho fatto io con CPU-Z.
solitamente il megathread viene messo sul core0 (che sui ryzen è anche il core più veloce, indipendentemente dal suo posizionamento sul die questo viene nominato in quel modo dal bios), ma più di una volta ho visto usare il core2 sui test che ho fatto, e mi è toccato "resettare" il gioco associandolo inizialmente esclusivamente al core0 e poi ridando le associazioni agli altri core.
in questo modo ho forzato il sistema ad usare quel core per il megathread (quantomeno ha funzionato ogni volta che l'ho fatto).

ci vorrebbero test sia con la CPU non troppo carica (quindi con settaggi spostati più verso la GPU), sia andando a vedere come si comporta quando la CPU fa da bottleneck; in questo modo abbiamo dei raffronti per capire quando sia incisiva questa questione.

che lo sia è tacito e l'ho dimostrato usando le due istanze di CPU-Z;
quanto lo sia sui vari giochi è da scoprire.
come è differentemente incisivo con una nvidia (che solitamente carica di più sui driver ed incide maggiormente sul megathread) o su AMD è anche quello da scoprire.

il caso che vedi negli articoli che ho linkato è "particolare"; quando usi la disabilitazione dell'SMT in pratica elimini il thread concorrenziale che gira sul core associato al core che regge il megathread, ma ti togli anche computazione massima e la prerogativa di utilizzare comunque l'SMT, in quanto non è lo scheduler che gestisce questo processo, ma direttamente il processore, quindi anche se non è associato un core, lui lo potrebbe benissimo usare in SMT.
quindi se hai potenza sufficiente per reggere il computo con solo la metà dei core attivi, può essere che hai lo steso risultato che disassociare il core concorrenziale, ma tanto dipende anche da come è fatto il gioco e se sfrutta certi tipi di istruzioni che potrebbero avvantaggiarsi dell'SMT.
quindi non è detto che possa migliorare, anche rispetto alla condizione di sfruttare tutti i core indifferentemente.

con i 3000 con doppio die il discorso diventa ancora più articolato, dovendo andare a vedere se le latenze del passaggio da un die all'altro possono influire negativamente o se il fatto di avere un'altro accesso indipendente alla memoria possa mitigare la concorrenzialità delle risorse; discorso ancora più articolato con i TR 2000 e 3000 che hanno anche il quad channel.

è giusto per togliersi lo sfizio di capire come funziona.

[Il nabbo di turno]

Seguo!

[lucusta]

aspettiamo volenterosi con le loro CPU, GPU e tanta voglia di perdere tempo a fare benchmark...

intanto vedo di rifare ed ampliare i test con una procedura più precisa.

ci vorrebbe l'interessamento di Vincenzo e la sua disponibilità HW.

[Masciale]

Tu mi chiami ed io compaio, quasi come il genio della lampada

Ho letto tutto d'un fiato il post (L'insonnia a volta produce cose buone come puoi vedere) e mi trovo perfettamente d'accordo con te, semplicemente Windows non sa utilizzare al meglio le CPU Ryzen e stop!

Purtroppo ho pochissimo tempo da dedicare già al sito, non credo di riuscire a supportarvi con eventuali test

Seguo comunque con interesse

P.S. più che nei test a 800*600 sarei curioso di vedere se, affinando al meglio la gestione dei core, si può ottenere un miglioramento reale a risoluzione 1080p.

[mafferri]

Avevo visto e letto questo thread ieri, ma rispondo adesso, anche io avevo notato questi piccoli difetti sul mio ryzen , tipo il lag del mouse, che non vedevo da una vita, e infatti mi ha stupito anche durante il carimento dei dati del gioco noto questi lag
Purtroppo non troverei tempo per far test, ne ho altri in mente su linux riguardo l'overclock o meglio i settaggi del procio , ma anche per installare quest'ultimo non riesco a trovare il tempo . e invece dovrei farlo

[lucusta]

ciao Vincenzo, come potevi mancare!

i test li conduco a 800x600 perchè con una 570 a 1080p gli faccio il solletico al 3400G ^_^
comunque cerco di farli per vedere come vanno.

intanto ho una serie su GRID 2, codemaster ed il suo engine che sfrutta anche i core dei PC che gli metti accanto!
premetto che il benchmark di grid 2 non è sempre la stessa sequenza; cambiano i tempi sul giro (quindi i frame totali), ma mediamente l'occupazione della CPU è molto regolare su ogni singolo core, quindi la differenza sui minimi e massimi non ci dovrebbe essere; il core più utilizzato, ossia quello che regge il thread della struttura del gioco, a me è risultato il core0.
GRID 2 800x600 settaggi preset minimi

affinità con tutti i core:
frame totali 25590
fps media 197.10
fps min 158.59
fps max 257.85
occupazione core0 da 60 a 70%

affinità con tutti i core - core1
frame totali 25831
fps media 204.81
fps min 162.90
fps max 268.28
ocupazione core 0 da 70 a 80%

affinità solo con i core 0,2,4,6
frame totali 26569
fps media 207.72
fps min 168.89
fps max 259.19
occupazione core0 da 90 a 100%

in questa serie si nota come non usare il core associato a quello fisico produca un aumento apprezzabile della media, ma c'è anche da dire che il tutto lambisce il limite massimo delle possibilità di quel core, che spesso si trova al 100% e che ne pregiudica quindi i massimi (260 circa contro i quasi 270 del test con tutti i core meno soltanto quello associato al core0 con il megathread), quindi i valori potevano essere anche superiori... dovrò monitorare anche l'occupazione della GPU, a questo punto.

nella seconda serie ho usato sempre la risoluzione 800x600 con preset leggermente più alti per riuscire a caricare la CPU con vari effetti, ma la GPU non ce la fa a prtarli avanti con alti framerate.

affinità con tutti i core:
frame totali 15079
fps media 120.48
fps min 95.51
fps max 174.15
occupazione core0 da 50 a 60%

affinità con tutti i core - core1
frame totali 15289
fps media 123.09
fps min 96.45
fps max 179.53
ocupazione core 0 da 60 a 70%

affinità solo con i core 0,2,4,6
frame totali 15932
fps media 125.6
fps min 100.34
fps max 183.67
occupazione core0 da 70 a 80%

anche in questo caso, comunque, il processore ha risposto meglio quando non aveva associati i core logici pari e, questa volta, non ha subito il limite dei tetto massimo a 100% di occupazione, quindi ha ottenuto anche i massimi più alti.
La conclusione è che a questo gioco non frega nulla dell'SMT... è anche questo del 2013 e non credo che sia ottimizzato in tal senso; il suo limite, in effetti, è solo il carico degli effetti e il framerate.
possiamo dire che un ryzen a 4 ghz si fermerebbe alla soglia dei 270fps, GPU permettendo.
devo trovare un gioco che carichi la CPU, ma non la GPU.

domani cerco di fare quelli in "puro SMT" e quelli in FHD, anche se credo non siano migliorativi rispetto a quelli con affinità 0,2,4,6.
(ora dovrei riavviare la macchina e sono le 5.06... almeno un paio d'orette le voglio dormire).


@mafferri e tutti gli altri:
inanzi tutto grazie dell'interessamento e comunque sto cercando anche consigli e critiche per aggiustare meglio il tiro di questa serie di test, quindi ogni cosa è ben accetta.
lo facciamo per capire meglio come funzionano le cose.