CPU EPYC a 64 core e schede Radeon Instinct a 7nm: il futuro di AMD passa dal datacenter

AMD affila le armi contro Intel per guadagnare spazio nel settore dei datacenter, grazie ad una roadmap molto ambiziosa e a prodotti basati su tecnologia produttiva a 7 nanometri che debutteranno tra fine 2018 e 2019. Con i processori EPYC della famiglia Zen 2 AMD passa a 64 core per socket, affiancando schede Radeon Instinct di nuova generazione pensate per il datacenter
di Paolo Corsini pubblicato il 07 Novembre 2018 nel canale Server e WorkstationAMDVegaRadeon InstinctEPYCRyzenZen
45 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infoA questo punto si aspetta il ces, Navi imho sarà qualcosa di rivisto, altrimenti questa mi60 non l'avrebbero chiamata vega.
Non so se hai notato che c'è anche una mi50 con 60 cu e non 56 come era logico aspettarsi
Navi dovrebbe accentuare le caratteristiche di versatilità che oggi abbiamo visto da vega 10 a vega 20 senza però pagare pegno per la complessità.
c'era un brevetto AMD di un paio di anni fa che parlava proprio del modo di organizzare gli SP per i calcoli eterogenei.
da quanto si capiva era basato sulla diversificazione della clusterizzazione;
per spiegarmi meglio, oggi son passati da vega 10 che poteva dividere i suoi cluster e associarli in un certo grado di possibilità, ad una, con vega 20, che offre ampliate possibilità, ma per tutti i cluster in maniera uguale.
Navi, o meglio quel brevetto, invece incentrava il discorso della varietà di clusterizzazione.
da cluster da 4 SP con aggregazione a 16 sp senza passaggio store/set/load, a clusterizzazioni da 1, 2, 4 fino a 32 SP in modo da minimizzare l'uso proprio d'istruzioni load/set/store a seconda del compito da lavorare.
è questo oggi lo svantaggio dell'architettura AMD, ossia le troppe operazioni di load/set/store per operare su compiti che richiedono cluster con elevato numero di SP.
queste operazioni portano via cicli operativi utili (quindi il rendimento massimo) e richiedono un sacco di logica e strumenti HW in più, quindi più consumo.
logicamente anche sul metodo precedente posso aggregare i cluster da 1 per arrivare a 64 utili, ma perderei un sacco di tempo a fare operazioni d'interscambio dati.. sarebbero però sommati ai cluster più corposi che lo fanno in meno tempo, ottenendo un rendimento di calcolo decisamente maggiore.
ottengo quindi versatilità pagando però in massima utilizzazione dell'HW...
per spiegarmi meglio oggi usi 100 per ottenere 75 consumando 100, domani userai preferibilmente 75 sui 100 per ottenere 75 e consumare 75, con la possibilità di usare comunque tutti e 100 ma ottenendo 93.75 a causa dei 25 in più che hanno rendimento solo del 75% a causa dei continui load/set/store, e consumando quindi sempre 100.
passo perciò da 75 a 93.75 consumando comunque 100.
allo stesso modo, cambiando il calcolo con esigenze inferiori di aggregazioni, oggi uso 100 ed ottendo 90 consumando 100, mentre domani solo 25 dei 100 mi danno 22.5 (rendimento 90%) consumando 25, gli altri 75 sono costretti ad andare con rendimento 50% consumando comunque 75, quindi in totale ho
60 con consumo 100 invece che ottenere 90 consumando 100...
è comunque il bilanciamento delle "quote" di clusterizzazione che caratterizzeranno l'HW per un compito invece che per un'altro e tutto dipende dalla tipoogia di codice che devono processare per ambiti diversi.
sono solo numeri per indicare come una diversa architettura logica possa comunque rendere meglio.
quindi oggi vega 20 si giova unicamente della riduzione di PP a 7nm, mentre la stessa architettura con la stessa identica versatilità avrebbe consumato a 14nm ben più dei 300W di target, con lo stesso valore prestazionale in quello che era in grado di fare vega 10, e l'aggiunta di una maggiore flessibilità...
è facile capire che vega 20 poteva nascere solo a 7nm...
ribaltando la situazione un Vega 10 a 7nm, quindi non avendo le peculiarità della 20 per il mondo datacenter (FP64 2:1, Int8 e Int4 a rateo x4 e x8 su fp32, QNN, etc), ma rimanendo "adatta anche per il gaming" a pari prestazioni di vega 10 a 14nm non avrebbe consumato solo il 50% in meno (rispetto alla 14nm da 300), ma oltre il 66%, passando da 300 a 100... ed una vega 64 che ti consuma 100-120W reali non sarebbe male... ma, ad oggi, sarebbe quasi inutile sul mercato (soprattutto se ti costa il 25-30% in più di oggi per via dell'uso del PP più avanzato)...
quindi, al limite, meglio una vega 20 portata nel mondo consumer, che arrivi a 200W reali con un pò più di prestazioni, ma che abbatta i costi di quelle per datacenter e aspettare di fare l'architettura che ti permette di ottenere il doppio di quelle prestazioni per lo stesso consumo.
ma si parlerebbe sempre di comprare una Vega 20 per gaming sui 650/700 euro per un 20-25% di prestazioni in più per comunque i 250-300W di target.
finche non scende sotto i 500 (ossia i costi del PP siano debitamente abbattuti) non ha nulla di così affascinante.
e quindi di riflesso si prospettava per i ryzen 3700/X nuovi traguardi fino a 16 core
ma il nuovo epyc e' si un mostro a 64 core ma con un progetto totalmente differente,usando tanti piccoli die da 8 core ciascuno
ma adesso cosa ci dovremmo aspettare dal prossimo 3700x?
ok grazie a zen2 a 7nm possiamo ipotizzare prestazioni da i9-9900k a meta' prezzo e consumi inferiori,non e' poco ma...e' gia' finita la rincorsa ai core?
o forse e' possibile che anche per ryzen usino un progetto multidie
forse per un ipotetico 3800x a 12/16 core ma ci credo poco
ma che te ne fai in ambito domestico, anche pro, di 16c/32t?
Grazie ad amd siamo giunti ad avere octa core a prezzi di saldo, direi che sia più che sufficiente. Già adesso i software in grado di sfruttarli a pieno si contano su una mano..
EDIT, fra l'altro con threadripper potresti già farlo a prezzi tutto sommato contenuti: 1950x a 650 euro, mb a 300 euro, 32gb di ram a 250 euro, con 1200 hai già pronto il sistema.
ed avrebbe anche senso, visto che controller DDR e I/O vari sono stati spostati.
per ora, ad occhio, sembra che sia un SKU totalmente differente dai precedenti e che senza I/O die non possa funzionare a dovere, quindi per il prossimo ryzen 3000 o usano uno i due di questi con un'altro I/O die, magari più piccolo (questo dovrebbe aggiungere una L4 da 512MB, tanto per dire), o fanno un'altro SKU.
per le ben poche informazioni che si hanno (ad esempio non si capisce se questi hanno un CCX da 8 o 2 da 4), per ora è tirare ad indovinare per il resto della linea...
c'è però un dettaglio non di poco conto:
AMD ha necessità di entrare bene in rapporto con gli OEM per produrre portatili, che sono la maggioranza del mercato (sono il 60% e praticamente li vende solo Intel, tolti quella decina di prodotti con le APU AMD).
se fossero stati semi SOC capaci di operare tranquillamente anche senza I/O die sarebbe stato poco sensato non sfruttare questo prodotto nel mercato come possibile processore per portatili, in quanto realmente sarebbe un prodotto difficilmente replicabile per la concorrenza, almeno ad oggi...
avresti avuto la possibilità di selezionare i die per la linea server con quelli per i portatili, come fanno oggi, per una sinergia di produzione...
ma non c'è notizia, quindi mi sembra poco probabile che questi siano die che possano essere sfruttati per il mercato consumer.
il die è realmente piccolo a mio parere.
c'era un brevetto AMD di un paio di anni fa che parlava proprio del modo di organizzare gli SP per i calcoli eterogenei.
da quanto si capiva era basato sulla diversificazione della clusterizzazione;
per spiegarmi meglio, oggi son passati da vega 10 che poteva dividere i suoi cluster e associarli in un certo grado di possibilità, ad una, con vega 20, che offre ampliate possibilità, ma per tutti i cluster in maniera uguale.
Navi, o meglio quel brevetto, invece incentrava il discorso della varietà di clusterizzazione.
da cluster da 4 SP con aggregazione a 16 sp senza passaggio store/set/load, a clusterizzazioni da 1, 2, 4 fino a 32 SP in modo da minimizzare l'uso proprio d'istruzioni load/set/store a seconda del compito da lavorare.
è questo oggi lo svantaggio dell'architettura AMD, ossia le troppe operazioni di load/set/store per operare su compiti che richiedono cluster con elevato numero di SP.
queste operazioni portano via cicli operativi utili (quindi il rendimento massimo) e richiedono un sacco di logica e strumenti HW in più, quindi più consumo.
logicamente anche sul metodo precedente posso aggregare i cluster da 1 per arrivare a 64 utili, ma perderei un sacco di tempo a fare operazioni d'interscambio dati.. sarebbero però sommati ai cluster più corposi che lo fanno in meno tempo, ottenendo un rendimento di calcolo decisamente maggiore.
ottengo quindi versatilità pagando però in massima utilizzazione dell'HW...
per spiegarmi meglio oggi usi 100 per ottenere 75 consumando 100, domani userai preferibilmente 75 sui 100 per ottenere 75 e consumare 75, con la possibilità di usare comunque tutti e 100 ma ottenendo 93.75 a causa dei 25 in più che hanno rendimento solo del 75% a causa dei continui load/set/store, e consumando quindi sempre 100.
passo perciò da 75 a 93.75 consumando comunque 100.
allo stesso modo, cambiando il calcolo con esigenze inferiori di aggregazioni, oggi uso 100 ed ottendo 90 consumando 100, mentre domani solo 25 dei 100 mi danno 22.5 (rendimento 90%) consumando 25, gli altri 75 sono costretti ad andare con rendimento 50% consumando comunque 75, quindi in totale ho
60 con consumo 100 invece che ottenere 90 consumando 100...
è comunque il bilanciamento delle "quote" di clusterizzazione che caratterizzeranno l'HW per un compito invece che per un'altro e tutto dipende dalla tipoogia di codice che devono processare per ambiti diversi.
sono solo numeri per indicare come una diversa architettura logica possa comunque rendere meglio.
quindi oggi vega 20 si giova unicamente della riduzione di PP a 7nm, mentre la stessa architettura con la stessa identica versatilità avrebbe consumato a 14nm ben più dei 300W di target, con lo stesso valore prestazionale in quello che era in grado di fare vega 10, e l'aggiunta di una maggiore flessibilità...
è facile capire che vega 20 poteva nascere solo a 7nm...
ribaltando la situazione un Vega 10 a 7nm, quindi non avendo le peculiarità della 20 per il mondo datacenter (FP64 2:1, Int8 e Int4 a rateo x4 e x8 su fp32, QNN, etc), ma rimanendo "adatta anche per il gaming" a pari prestazioni di vega 10 a 14nm non avrebbe consumato solo il 50% in meno (rispetto alla 14nm da 300), ma oltre il 66%, passando da 300 a 100... ed una vega 64 che ti consuma 100-120W reali non sarebbe male... ma, ad oggi, sarebbe quasi inutile sul mercato (soprattutto se ti costa il 25-30% in più di oggi per via dell'uso del PP più avanzato)...
quindi, al limite, meglio una vega 20 portata nel mondo consumer, che arrivi a 200W reali con un pò più di prestazioni, ma che abbatta i costi di quelle per datacenter e aspettare di fare l'architettura che ti permette di ottenere il doppio di quelle prestazioni per lo stesso consumo.
ma si parlerebbe sempre di comprare una Vega 20 per gaming sui 650/700 euro per un 20-25% di prestazioni in più per comunque i 250-300W di target.
finche non scende sotto i 500 (ossia i costi del PP siano debitamente abbattuti) non ha nulla di così affascinante.
Grazie della risposta esauriente
Evidentemente hanno pensato pure loro che vega a 7 nm consumer non era conveniente e hanno cocentrato gli sforzi su navi
Avevo visto una slide dove venivano mostrati i cambiamenti sulle ncu di vega 20
Fate come me e non pensateci più: che cuocia nel suo brodo
Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".