[Thread Ufficiale] CPU Zen 14/12/7nm: AMD Ryzen!

[leoneazzurro]

Se AMD fosse indietro nel prefetching, nel branch predictor e nelle latenze della cache, come farebbe Zen2 ad avere l'IPC che ha? Si, ha delle belle unità di esecuzione, ma se non le alimenti non c'è storia...
Giusto per essere precisi: le latenze delle cache L1, L2 ed L3 di Zen 2 sono paragonabili a Comet Lake (L1 Zen2: 4-5 cicli. L1 Comet Lake 4-5 cicli L2 Zen2 circa 12, Comet Lake 12, L3 Zen2 40 cicli, L3 Comet Lake 42 cicli). L'associatività della cache L2 di Zen 2 è maggiore e la sua dimensione è doppia (512Kb invece di 256). Se non erro poi la banda per ciclo dalla L3 alla L2 è pure essa doppia. Per prefetching e branch prediction non c'è un'unità di misura, si può vedere l'efficacia solo testandoli in applicazioni reali.

[leoneazzurro]

Originariamente inviato da Gigibian

ah ok, davo per scontato la GPU fosse identica, entrambe 2080. Perchè hanno usato gpu diverse? bah.

Da quel che ho visto paragonando i risultati in quel database ai dati delle review, le GPU sono tutte pesantemente overcloccate, e probabilmente anche le CPU

[Randa71]

Originariamente inviato da paolo.oliva2

CUT
-------
Per i deboli di cuore consiglio di saltare

Aggiungo una mia considerazione, che come al solito mi impegno a 1000 nel spiegare, ma con certezza che risulterà incomprensibile
Se carico Zen2 con un numero +50% di TH esosi, il procio tende a rallentare (16TH + 50% = 24TH). Se disabilito l'SMT e carico sempre i 24TH, il procio non rallenta.
Ho pensato che ciò sia dovuto al fatto che con SMT disabilitato, le chiamate siano comunque sequenziali mentre con SMT ON alcune si sovrappongono.
Ora... se AMD avesse creato una L3 per reggere un SMT4 (che peraltro potrebbe essere stata progettata per un futuro SMT4), implementandola su Zen3 SMT2, non potrebbe creare un guadagno come il mio sopra?

Tende a rallentare cosa intendi? Che la macchina è meno reattiva? Il motivo non lo so. Occhio che potrebbe esserci lo zampino di windows. Dovresti provare con linux giusto per vedere se i rallentamenti sono i medesimi. Avendo SMT abilitato immagino che la gestione dello scheduler di windows sia diversa rispetto al SMT disabilitato...

[Max(IT)]

Originariamente inviato da paolo.oliva2

-------
Per i deboli di cuore consiglio di saltare

Aggiungo una mia considerazione, che come al solito mi impegno a 1000 nel spiegare, ma con certezza che risulterà incomprensibile
Se carico Zen2 con un numero +50% di TH esosi, il procio tende a rallentare (16TH + 50% = 24TH). Se disabilito l'SMT e carico sempre i 24TH, il procio non rallenta.
Ho pensato che ciò sia dovuto al fatto che con SMT disabilitato, le chiamate siano comunque sequenziali mentre con SMT ON alcune si sovrappongono.
Ora... se AMD avesse creato una L3 per reggere un SMT4 (che peraltro potrebbe essere stata progettata per un futuro SMT4), implementandola su Zen3 SMT2, non potrebbe creare un guadagno come il mio sopra?

discorso interessante.... ma non l'ho capito

parliamone. Cosa intendi con "numero +50% di thread esosi" ?
che tu carichi 24 threads sul 3700X e con SMT va più lento che senza ?

[paolo.oliva2]

Originariamente inviato da Randa71

Tende a rallentare cosa intendi? Che la macchina è meno reattiva? Il motivo non lo so. Occhio che potrebbe esserci lo zampino di windows. Dovresti provare con linux giusto per vedere se i rallentamenti sono i medesimi. Avendo SMT abilitato immagino che la gestione dello scheduler di windows sia diversa rispetto al SMT disabilitato...

E' una mia visione contorta... (il post di leoneazzurro mi ha in qualche modo spiegato che ciò che penso è sbagliato), comunque volevo dire:

Prendiamo 2 cose che possono avere una latenza simile ed un rendimento diverso.
RS232, dati sequenziali, parallela centronics, dati paralleli.
Ora.. se ho una latenza 50ns su una RS232 ed io non posso scendere oltre 60ns (MCM vs monolitico), la soluzione (potrebbe essere) spedire una percentuale di dati superiore almeno tanto quanto la % di latenza superiore.
Ovvero, tradotto, se potenzio la L3 perchè possa fornire più dati, diminuirei gli accessi alla DDR, quindi nella media è come se diminuissi la latenza.

L'esempio che riportavo di SMT ON/OFF (a franco di prb S.O.) era per dimostrare che a parità di L3 e a parità di TH (oltre che a parità di prefetch e predizione), potevo elaborare senza rallentamenti con SMT OFF, mentre no con SMT ON. Ho pensato che fosse dovuto alla L3.

Su questa deduzione, sono arrivato all'ipotesi che se si progettasse una L3 per soddisfare un SMT4 (cioè 8 core * 4TH = 32TH) le risorse sarebbero ben superiori ad una L3 "normale" per SMT2. Ma se questo fosse utile a diminuire gli accessi alla DDR, è ovvio che il risultato sarebbe una diminuzione della latenza compplessiva.

[leoneazzurro]

Molto probabilmente quello che vedi con la situazione dei 24 threads è lo scheduler di Windows che fa thread switching tra core "reali" e "virtuali" facendo il casino che vedi, anche perchè devi allocare 24 threads su 16 core (non multiplo intero). Ovviamente disabilitando SMT tutti le risorse sono allocate ad un core "reale" per cui non c'è il medesimo thread switching, anche perché stavolta il multiplo è intero (3 a 1).

[Max(IT)]

Originariamente inviato da paolo.oliva2

L'esempio che riportavo di SMT ON/OFF (a franco di prb S.O.) era per dimostrare che a parità di L3 e a parità di TH (oltre che a parità di prefetch e predizione), potevo elaborare senza rallentamenti con SMT OFF, mentre no con SMT ON. Ho pensato che fosse dovuto alla L3.

l'esempio che hai riportato, se l'ho interpretato correttamente, non c'entra una fava con l' L3 ma ha a che fare con quel cancro dello scheduler Windows

Ottimo con i dual core Intel di 5 anni fa... oggi non adeguato alla propensione al MT che tutta l'industria sta avendo. Ma prima di smuovere un pachiderma come Microsoft ed il suo codazzo legacy serve tempo...

[Max(IT)]

Originariamente inviato da leoneazzurro

Molto probabilmente quello che vedi con la situazione dei 24 threads è lo scheduler di Windows che fa thread switching tra core "reali" e "virtuali" facendo il casino che vedi. Ovviamente disabilitando SMT tutti le risorse sono allocate ad un core "reale" per cui non c'è il medesimo thread switching.

scritto insieme

[paolo.oliva2]

Originariamente inviato da Max(IT)

discorso interessante.... ma non l'ho capito

parliamone. Cosa intendi con "numero +50% di thread esosi" ?
che tu carichi 24 threads sul 3700X e con SMT va più lento che senza ?

Faccio un preambolo.

L'SMT è lo "stratagemma" per aumentare l'efficienza del core, perchè il 2° TH core sfrutta i tempi morti in cui il core non lavora che sono variabili da software a software. Mi sembra che su Intel si parlasse da un massimo del +25% ad un minimo di zero%. Se estrapolassimo una media dell 15%, ciò vuol dire che un core SMT elaborerebbe (complessivamente) +15% di dati rispetto ad un core no SMT con uguale IPC.

Però il rovescio della medaglia dell'SMT, è che a quel +15% prestazionale, segue una maggiore perdita di sovra-carico.
L'esempio era che BD poteva caricare TH corposi >3 volte i TH nominali (24TH vs 8TH) mentre Zen (io la prova l'avevo fatta con il 1800X*) con 16TH nativi, rallenta già a 24TH.
E qui ho riportato che Zen con SMT OFF invece 24TH esosi li carica senza rallentamenti.

Kernel e quant'altro a pari settaggio.

* La prova veloce è con CB.
Se lanci CB def, ottieni un tempo X di elaborazione con i TH nativi.
Se aumenti passo passo i TH fino a che il tempo di elaborazione non varia, allora il core regge quel plus di carico, come aumenta il tepo di elaborazione, hai superato il limite di stra-carico TH. (a pari settaggio kernel).

[paolo.oliva2]

Originariamente inviato da leoneazzurro

Molto probabilmente quello che vedi con la situazione dei 24 threads è lo scheduler di Windows che fa thread switching tra core "reali" e "virtuali" facendo il casino che vedi, anche perchè devi allocare 24 threads su 16 core (non multiplo intero). Ovviamente disabilitando SMT tutti le risorse sono allocate ad un core "reale" per cui non c'è il medesimo thread switching, anche perché stavolta il multiplo è intero (3 a 1).

In teoria, allora, per escludere il prb di switching dello scheduler, basterebbe provare un 3700X con 32TH anzichè 24.... sarebbe 2:1
Cioè, in linea di massima, se fosse problema di scheduler, un 3700X 8/16 dovrebbe andare meglio a 32TH vs 24.

Non la posso fare la prova... sono con il 2700U, 3700X e 1920X Kaput. Se ci caccio 32 TH ad un X4+4 mobile, mi si corrompe ... troppo panico, considerando che mi si è rotto pure l'Mi8, l'ultima risorsa tecnologica che mi è rimasta è un Redmi X8 2GHz lento come la fame che mi fa sclerare.

[leoneazzurro]

Originariamente inviato da paolo.oliva2

In teoria, allora, per escludere il prb di switching dello scheduler, basterebbe provare un 3700X con 32TH anzichè 24.... sarebbe 2:1
Cioè, in linea di massima, se fosse problema di scheduler, un 3700X 8/16 dovrebbe andare meglio a 32TH vs 24.

Non la posso fare la prova... sono con il 2700U, 3700X e 1920X Kaput. Se ci caccio 32 TH ad un X4+4 mobile, mi si corrompe ... troppo panico, considerando che mi si è rotto pure l'Mi8, l'ultima risorsa tecnologica che mi è rimasta è un Redmi X8 2GHz lento come la fame che mi fa sclerare.

Questo non saprei, perchè comunque non conosco in dettaglio il comportamento dello scheduler di Windows in dettaglio, soprattutto con i core virtuali. So che quando ci sono molti thread "in giro" con SMT molta gente ama settare l'affinità dei core con le applicazioni in modo da far gestire determinati programmi dai core reali, traendone beneficio. Windows da questo punto è un gran casino.

[WarSide]

Finalmente ho avuto modo di assemblare il mio nas/homelab ieri sera con il 4750G.

Ho fatto girare un po' OCCT e fatto un paio di passate con Cinebench R20.

La prima impressione è stata di quando ho visto le temperature sotto carico. Sto usando un Noctua L12S e la CPU sotto carico mi arriva a 70-75°C.
75°C sotto carico non li avevo neanche con il 3600 raffreddato da un Noctua C14!

Confermo che il 4750G è inferiore al 3700X a def (niente PBO attivo). Sono arrivato a 4731 punti in mt con cinebench.

Ho fatto anche girare 3Dmark (anche se non mi riconosce GPU e CPU) giusto per vedere come si comporta la GPU integrata. Il punteggio totalizzato è 1588 (GPU 1390, CPU 8409).

Contate che i ryzen pro hanno una serie di feature di sicurezza che aumentano le latenze con la ram rispetto ai ryzen lisci. Inoltre io sto usando ram ECC, quindi oltre i 3200MHz non vado.

Ho provato ad installare ryzen master, ma per qualche oscuro motivo non parte con questa cpu

PS: terrò win10 installato fin quando asrock non mi risolve i problemi con i 2 SSD intel optane che ho montato (la mobo mi riconosce solo 2 SSD invece di riconoscerne 4 ). Se volete i risultati di qualche test specifico, ditemi pure.

[Max(IT)]

Originariamente inviato da WarSide

Finalmente ho avuto modo di assemblare il mio nas/homelab ieri sera con il 4750G.

Ho fatto girare un po' OCCT e fatto un paio di passate con Cinebench R20.

La prima impressione è stata di quando ho visto le temperature sotto carico. Sto usando un Noctua L12S e la CPU sotto carico mi arriva a 70-75°C.
75°C sotto carico non li avevo neanche con il 3600 raffreddato da un Noctua C14!

Confermo che il 4750G è inferiore al 3700X a def (niente PBO attivo). Sono arrivato a 4731 punti in mt con cinebench.

Ho fatto anche girare 3Dmark (anche se non mi riconosce GPU e CPU) giusto per vedere come si comporta la GPU integrata. Il punteggio totalizzato è 1588 (GPU 1390, CPU 8409).

Contate che i ryzen pro hanno una serie di feature di sicurezza che aumentano le latenze con la ram rispetto ai ryzen lisci. Inoltre io sto usando ram ECC, quindi oltre i 3200MHz non vado.

Ho provato ad installare ryzen master, ma per qualche oscuro motivo non parte con questa cpu

PS: terrò win10 installato fin quando asrock non mi risolve i problemi con i 2 SSD intel optane che ho montato (la mobo mi riconosce solo 2 SSD invece di riconoscerne 4 ). Se volete i risultati di qualche test specifico, ditemi pure.

Vabbè da un NAS non ci si aspettano record di Cinebench

[WarSide]

Originariamente inviato da Max(IT)

Vabbè da un NAS non ci si aspettano record di Cinebench

Contando quante VM a breve dovrà gestire, diciamo che sarà ANCHE un nas

[Max(IT)]

Originariamente inviato da leoneazzurro

Questo non saprei, perchè comunque non conosco in dettaglio il comportamento dello scheduler di Windows in dettaglio, soprattutto con i core virtuali. So che quando ci sono molti thread "in giro" con SMT molta gente ama settare l'affinità dei core con le applicazioni in modo da far gestire determinati programmi dai core reali, traendone beneficio. Windows da questo punto è un gran casino.

Per il 2024 quando l’offerta di base sarà 8C/12T ed il mainstream 16C/32T forse Microsoft si degnerà di tirare fuori un windows adatto...

Magari senza cercare la retro compatibilità con Windows 95

[BadBoy80]

https://www.guru3d.com/files-details...-download.html

Ci si cimenta?!

[Max(IT)]

Originariamente inviato da BadBoy80

https://www.guru3d.com/files-details...-download.html

Ci si cimenta?!

Appena torno a casa contaci

[Angelonero87]

share in italiano


questo il log:
Diagnostic results:
Energy efficient: 3.44
AMD Ryzen 7 3700X 8-Core Processor - Bronze sample
Recomended values for Overclocking:
Reference frequency: 4200 MHz
Reference voltage: 1275 mV
Recomended values for Undervoolt:
Reference frequency: 4000 MHz
Reference voltage: 1175 mV

[leoneazzurro]

Io a quanto pare ho un silver sample, ma ho scoperto che il Clevo control center va in conflitto con il CTR. Poco male, ho settato un "safe undervolt" a 4,2 GHZ all core a 1,275V e sembra girare ottimamente - per ora. Vedremo se è RS.

[Max(IT)]

Fatemi capire: quindi alla fine CTR suggerisce un overclock a voltaggio fisso all core da settare manualmente nel BIOS ?
Avevo capito che faceva da solo...