Ryzen 3000 e Zen2: vediamo cosa si nasconde sotto il cofano

[lucusta]

Fottemberg, scrivi testualmente:
" In altre parole, le CPU Intel sono più veloci di quanto non dovrebbero (Qui un test di Puget System su quanto le piattaforme Intel perdono nei software professionali una volta installate queste patch)."

non è proprio vero.
con gli aggiornamenti da bios dei microcode Intel ha letteralmente overclockato alcuni suoi processori (quelli non della serie K) per sopperire alle perdite prestazionali delle patch.
è che non si vede nei benchmark perchè non vengono mai benchati...

rimane aperta la questione di un'ammissione ufficiale che l'X570 è l'I/O HUB (anche se ormai si è capito che è così), e la possibilità di rendere associative le unità vettoriali AVX2 per fare una AVX512.

se hai news...

[ermanno]

sugli Epyc hanno messo.. quanto? un 256 MB di L3 sull'IO?

Mi sembra che la cache L3 sia ancora nel CCX/CCD:

converrebbe farla a parte?
non se sono 256 MB... quando diverranno GB allora si.

Più che un problema di "quantità", la mia curiosità era per la superficie. Grandi superfici sono soggette a errori in fase di produzione, con conseguente scarto dei chip fallati. Visto l'aumentare della superficie dedicata alla cache L3, prima o poi potrebbe diventare conveniente la suddivisione dei core veri e propri dalla cache L3. È solo un'ipotesi, sia chiaro.
Ma, presumibilmente, finché la controparte proporrà chip monolitici non avrà senso raschiare il fondo del barile con una suddivisione così spinta. IMO

[lucusta]

il discorso che fai è in piena logica, ma effettivamente un CCD ryzen fa 74mm^2, oggi a 7nm, con 8 core.
è una dimensione che consente già di avere rese eccezionali.
questo è Matisse
in cui la L3 prende 1/5 del die (14.8 mm^2) per 32GB, la L2 praticamente la stessa quantità di spazio...
(e si, hai ragione, non hanno sfruttato l'hub I/O per una L4, ma ci sono 4GB di L3 a core)...
la previsione che si può fare è che usino una L4 centralizzata proprio su l'HUB I/O, diminuendo la L3 su singolo core.
questo però comporterebbe un aggiornamento del bus IF, che dev'essere adeguatamente rafforzato in banda e latenze.

facendo una proiezione su come sarebbe più opportuno costruire un chip per server, tra breve dovremmo vedere la possibilità di core a 4 vie (oggi sono a 2 vie); se i miglioramenti di +7nm non saranno incentrati sulla densità, ma solo sul miglioramento dell'attenuazione delle interferenze e delle correnti di leakage, per fare un chip a 4 vie rimanendo con una dimensione opportuna dovranno sacrificare un bel pò di caches sul die dei core e la migliore possibilità è quella di porlo su l'HUB I/O, passando dai 12nm di oggi ai 7nm, raddoppio dalla L2 e mantenimento di L3.
con un raddoppio delle line IF, quindi del controller, otterresti un chip sui 92-96mm^2, che è sempre e comunque una dimensione da rese ottimali (finchè rimani sotto i 100mm^2 riesci a ottenere ottimi risultati statistici sulla resa).
passeresti però a 256 thread, e quindi dovrai adeguatamente foraggiare tale enormità di possibile lavoro.

riducendo i nm dell'HBB recupereresti tanto spazio da poter raddoppiare sia il controller PCIe (ma è quasi inutile, in quanto hai già la ratifica del PCIe 5.0 ed il raddoppio della banda e già oggi i sistemi epyc sono altamente espandibili), sia il raddoppio delle linee IF, dell'intercominicazione tra 2 chip che spazio sufficiente per 1GB di L4.

stiamo prefigurando però un processore che potremmo vedere in Zen 4, che userà i 6 se non 5nm...

si, la logica porta a pensare che aumenteranno la gerarchia della caches integrandola nell'HUB chip (più vicino al controller RAM), ma per il fattore dimensionale, lo faranno esclusivamente per l'aumento dei core per chip e l'aumentata capacità di calcolo e non è conveniente separare la caches in un chip a se stante.

anzi... guardando l'epyc viene da chiedersi quale sia la resa dell'Hub chip I/O.
è un chip da oltre 400mm^2, ed anche se "gira" piano, farlo a 7nm così grande, integrando L4, non ha senso...
conviene dividerlo in 2 diversi chip intercomunicanti, in modo da sfruttare lo stesso chip modulare anche per i prodotti mainstream e per i chipset delle mobo...
il bello della tecnologia chiplets è essenzialmente questo: a scapito di un piccolo aumento dei singolo die per l'uso di un altro controller di comunicazione hai la possibilità di dimezzare, in pratica, la superficie del die e di rendere i chip facili da fare, oltre che utilizzabili in diversi ambiti come singoli moduli.

quindi vedo più propensa l'ipotesi di un accorpamento della caches nell'hub e nella ulteriore separazione in moduli di questo;
questa disposizione ha molti più aspetti vantaggiosi che la separazione della caches (che necessiterebbe di un ulteriore doppio controller e aumenti di latenza da e per RAM e da e per core... almeno elimini un "da e per").

[Fottemberg]

Fottemberg, scrivi testualmente:
" In altre parole, le CPU Intel sono più veloci di quanto non dovrebbero (Qui un test di Puget System su quanto le piattaforme Intel perdono nei software professionali una volta installate queste patch)."

non è proprio vero.
con gli aggiornamenti da bios dei microcode Intel ha letteralmente overclockato alcuni suoi processori (quelli non della serie K) per sopperire alle perdite prestazionali delle patch.
è che non si vede nei benchmark perchè non vengono mai benchati...

rimane aperta la questione di un'ammissione ufficiale che l'X570 è l'I/O HUB (anche se ormai si è capito che è così), e la possibilità di rendere associative le unità vettoriali AVX2 per fare una AVX512.

se hai news...

Hai perfettamente ragione, infatti prossimamente testerò il Ryzen con il 9600k per vedere quanto Intel abbia osato.