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

[paolo.oliva2]

Io faccio un discorso più "largo".

Zen3 è un aumento prestazionale consistente e nel contempo non esoso, perchè chi ha un AM4 almeno da X470, può semplicemente upgradare il procio.

Quanto l'ha lungo Zen3, non lo so, ma non credo certamente che ci sia la necessità di upgradare il sistema l'anno prossimo.

Se Zen3 AM5 fosse lo stesso dell'AM4, si avrebbe un guadagno solamente nell'utilizzo DDR5 vs DDR4... che si quantificherebbe in quanto? 5%?
Il +5% era lo stesso guadagno circa del passaggio dal 1800X al 2700X, e in sto TH dicevano che 350€ di procio erano troppi per 5% di guadagno.
Figurati se si dovesse aggiungere 500€ tra mobo AM5 e DDR5.

Potrebbe essere un "giochino" commerciale... studiato vs Intel.
Da quello che si sa, pure Intel passerà alle DDR5 l'anno prox, ed un replace di Zen3 DDR5 (costo R&D pressochè nullo) permetterebbe ad AMD di prezzare Zen3+ basso, ben più basso di quello che potrebbe fare Intel sul monolitico.

La mia PERSONALISSIMA idea, è che AMD aspetti solamente di arrivare al target di mercato prefissato, per poi allineare i prezzi ad Intel.
Se prestazionalmente Zen3/Zen3+ avranno ancora margine su Intel, perchè sparare la cartuccia Zen4 che potrebbe essere utilizzata dopo? Un refresh a costo zero di Zen3 AM5, una limata ai listini del 20%, più guadagno di un Zen3+R&D, più competitività condita da immagine Babbo Natale , per poi sparare la cartuccia Zen4/5nm sperando nei prb Intel sul silicio (max comunque 10nm).

P.S. Edit.
Faccio notare che VIRTUALMENTE, AMD sta già facendo cartello.
Per la tempistica TSMC, un salto nodo ogni 2 anni, AMD potrebbe TRANQUILLAMENTE tirare fuori ZenX e ZenX+ nell'arco di 2 anni, passando al nodo successivo ogni 2 anni.

Se Intel non avesse prb sul silicio, Zen4/5nm sarebbe il successore di Zen3, altro che Zen3+.

Purtroppo credo che AMD stia facendo fin troppo bene i suoi conti, e le sta andando veramente grassa. Ora come ora basta 1 nodo di vantaggio e un'architettura con IPC bilanciato per il nodo di vantaggio, per essere più appetibile vs Intel.
A seconda di quale nodo offrirà Intel, AMD offrirà 1 nodo di vantaggio di conseguenza.
Nel cassetto ha già 5nm pronto, 6nm in produzione a rischio, 3nm pressochè finito per produzione a rischio e TSMC che inizierà nel 2021 la stesura del 2nm.

Tutto ovvio, anche AMD è una società commerciale... come Intel.

[WarSide]

Originariamente inviato da Totix92

Domanda, perché i nuovi Ryzen con architettura Zen 3 saranno numerati 5000 e non 4000?

Penso vogliano allineare le numerazioni tra CPU/APU.

In questo modo le APU serie 5000 avranno core Zen3 come le controparti senza GPU.

[Mparlav]

E' probabile che quel 5800x fosse un ES, quindi se "stock", è un punteggio per difetto di 100-200MHz (senza contare eventuali limitazioni sulla cache).
Ma vengono pubblicati anche risultati con ES overcloccati, quindi anche questo sarebbe falsato.
Non conosco l'incidenza della ram su AoS, ma potrebbero essere 2x16GB a clock basso (2400-2666, come accade con molti ES), oppure 3600 o più in overclock.

Visti i prezzi e le prestazioni dei 3800X/XT e 10700K/KF, secondo me il prezzo di lancio del 5800X sarà di 399$.

[Angelonero87]

https://twitter.com/1usmus/status/1310526652758274051

[leoneazzurro]

Originariamente inviato da Max(IT)

aspetta, dove hai visto il 60% più veloce di 3800X ???

Nel link che hai messo tu si parla del 27% più veloce...

https://twitter.com/CapFrameX/status...846658/photo/1

Avevo trovato un risultato per il 3800X a 1080p e dava sugli 88FPS come risultato più alto:

https://www.ashesofthesingularity.co...6-55f203a9f387

ed in effetti è piuttosto bassino, mentre a 4K ho trovato questo

https://www.ashesofthesingularity.co...9-08bce834cf81

che va sui 105 FPS. (Ram differente? Overclock?). Difficile dirlo...

Non so da dove Kopite7kimi abbia preso i valori del 3800X (che poi non sono del CPU framerate) ma sono abbastanza vicini a quelli del database per il 4K.
Considerando il 105FPS come base, abbiamo il 26.6% di incremento, a quel punto con un 10-15% in più di frequenza avremmo un 16-11% di IPC in più,il che sembrerebbe più "regolare".

[Max(IT)]

Originariamente inviato da leoneazzurro

Avevo trovato un risultato per il 3800X a 1080p e dava sugli 88FPS come risultato più alto:

https://www.ashesofthesingularity.co...6-55f203a9f387

ed in effetti è piuttosto bassino, mentre a 4K ho trovato questo

https://www.ashesofthesingularity.co...9-08bce834cf81

che va sui 105 FPS. (Ram differente? Overclock?). Difficile dirlo...

Non so da dove Kopite7kimi abbia preso i valori del 3800X (che poi non sono del CPU framerate) ma sono abbastanza vicini a quelli del database per il 4K.
Considerando il 105FPS come base, abbiamo il 26.6% di incremento, a quel punto con un 10-15% in più di frequenza avremmo un 16-11% di IPC in più,il che sembrerebbe più "regolare".

infatti già il 27% mi sembra un ottimo risultato... un 60% mi sembrerebbe miracoloso.

Quando una cosa è troppo bella per essere vera.... solitamente non è vera

[Gigibian]

Per quale motivo nel bench leaked del 5800X, il framerate totale è più basso nel ryzen? Mentre invece quello CPU è più alto.

[leoneazzurro]

Originariamente inviato da Gigibian

Per quale motivo nel bench leaked del 5800X, il framerate totale è più basso nel ryzen? Mentre invece quello CPU è più alto.

Potrebbe essere perché il frame rate reale è limitato dalla GPU a quei preset, e le GPU potrebbero essere diverse (versione custom OC contro stock)

[leoneazzurro]

Originariamente inviato da Max(IT)

infatti già il 27% mi sembra un ottimo risultato... un 60% mi sembrerebbe miracoloso.

Quando una cosa è troppo bella per essere vera.... solitamente non è vera

Vero, non so come mai i due 3800X diano risultati così differenti... e si tratta comunque dei due risultati più alti di quei preset presenti in quel database.
ES: il risultato più alto per un 3700X è 111 FPS - ma è praticamente sicuro sia OC.

Comunque ho trovato questo:

https://www.tomshardware.com/reviews...ew,6214-6.html

fatto con questo setup:

https://www.tomshardware.com/reviews...ew,6214-5.html

(quindi con una 2080 TI)

e gli FPS reali sono mooolti di meno che non quelli di questi score, segno che i sistemi del database sono spesso overcloccati sia dal punto di vista della CPU che della GPU

[paolo.oliva2]

Originariamente inviato da Totix92

Domanda, perché i nuovi Ryzen con architettura Zen 3 saranno numerati 5000 e non 4000?

Perchè AMD ha creato una gran confusione con gli APU.

Siccome gli APU seguivano di 1 anno la stessa architettura X86, per far risaltare un l'APU come prodotto nuovo, AMD ha incrementato di 1 il numero della serie.
Usendo Zen3, ci troveremmo un 4700X (successore 3700X) che sarebbe con architettura Zen3 e 7nm+, ma abbiamo gli APU il cui numero inizia con 4 ma su architettura Zen2 e 7nm.

Credo che la necessità di un riallineamento sia dovuta anche al fatto che post Zen3 sembra che AMD preveda solamente APU (Zen3+ APU?)

[paolo.oliva2]

Originariamente inviato da leoneazzurro

Gli FPS dipendono dall'IPC reale della CPU all'interno del gioco considerato, moltiplicato per la frequenza di clock. IPC che è sempre influenzata dalle latenze RAM, nei giochi dove i pattern sono più random e meno prevedibili questa influenza è maggiore. Tuttavia, occorre capire che la latenza della RAM non è la latenza effettiva "vista dalla CPU" ma contribuisce ad essa, insieme alle latenze delle cache L1, L2, L3 ed è pesantemente influenzata dagli algoritmi di prefetching e branch prediction dei dati. Per Zen3 si è sempre parlato di come sia stata unificata la cache L3 ma in realtà AMD ha parlato di vera e propria "nuova architettura" (evolutiva) per cui è facile immaginare che AMD abbia rivisto in maniera decisa anche questi algoritmi e rinforzato il branch predictor. Dopodiché, molto dipende dall'architettura in sé. Certo, è impressionante vedere non tanto la comparazione tra il 5800X e il 10900K in quel bench, quanto quella tra 5800X e 3800X, entrambi 8 core. Certo, si tratta di un solo bench. Ma con il 60% di performance in più. Tocca capire le frequenze operative. Il 5800x era overcloccato? Se si, di quanto? Boost all core? Certo che, anche considerando che un 15-20% possa venire dalle maggiori frequenze di clock, il risultato, se confermato, è sicuramente ottimo.

Capisco... grazie della spiegazione, però non comprendo.
AMD è sempre stata indietro vs Intel nel branch predictor, prefetching e latenze nelle cache... ma credo che il gap sia dovuto più alle risorse superiori Intel di mettere in produzione il progetto che come creazione progetto in quanto tale.
Però rimane sempre il punto che trovo difficile, praticamente impossibile, che AMD possa fare meglio di Intel, specie con Intel con l'obiettivo di incrementare dove possibile.

L'unico punto possibile, è che l'architettura Zen conceda di più. Non ne capisco una mazza, ma in rete si tende ad accettare il passaggio Zen >2TH semplicemente perchè si è concordi che l'architettura lo può permettere, mentre esempio sull'architettura Intel mai sentito nulla.
Penso che la soluzione madre per risolvere le latenze superiori MCM vs monolitico sia nella L3 del chiplet, con meno accessi alla DDR.

-------
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?

[Gigibian]

Originariamente inviato da leoneazzurro

Potrebbe essere perché il frame rate reale è limitato dalla GPU a quei preset, e le GPU potrebbero essere diverse (versione custom OC contro stock)

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

[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