[Thread Ufficiale] Aspettando ZEN

[tuttodigitale]

Originariamente inviato da george_p

Guardiamo i fatti, se BD fosse stato all'altezza anche con un silicio poco performante avrebbe detto la sua in diverse occasioni.
invece AMD ha perso quote di mercato e non hanno tirato a dadi per tornare su un approccio diverso dal CMT implementando finalmente l'SMT.
Questo va riconosciuto.

sarebbe stato davvero strano NON passare da QUATTRO implementazioni parziali del SMT, ad una cpu con SMT anche lato integer (anche se come fatto notare da Cesare anche la parte integer, beneficia dal CMT con carico scarsamente parallelizzabile).

Semmai non era logico passare al SMT2, ma direttamente ad un più esotico SMT2+CMT (4thread sulla fpu) o addirittura SMT4...anche li avranno ragionato..e non è detto che ZEN non debba svilupparsi in tal senso se le AVX-256, prenderanno piede (ma perchè dubitarne?)

Non lo so, pare che le cpu con SMT2, ma anche 8-vie debbano avere un ipc relativamente alto, dimenticandosi per strada che il P4 era con il SMT e conroe no..
sul fatto che BD, non sembrerebbe affatto un progetto troppo spinto lato frequenza sui 32nm SOI ce l'ha fatto notare CESARE, facendo l'esempio di IBM che ha migliorato le prestazioni per watt di brutto con una cpu da oltre 5GHz....
quel silicio, a livello di leakage rassomiglia più i finfet che non i bulk planari....

[tuttodigitale]

Originariamente inviato da capitan_crasy

Ni..
La L3 del K10 65nm aveva anche una latenza apocalittica, tanto che i propus a parità di clock e senza L3 andava mediamente di più

la differenza tra propus e agena pare insignificante
http://www.anandtech.com/bench/product/106?vs=21

Originariamente inviato da capitan_crasy

Con i 45nm AMD ha aggiunto una altra cosa; le frequenze.

direi soprattutto
2,6GHz@140W ->3,7GHz@125W

Originariamente inviato da capitan_crasy

Ci sono pochi dubbi che i 65nm SOI siano stati i peggiori nella storia produttiva AMD...

con la stessa frequenza del phenom 9950 (2,6GHz), su 45nm AMD proponeva Opteron a 8 core con TDP da 115W...credo che non ci sia bisogno di commentare.



@george_p
se BD/PD fosse stata una pessima architettura, quale è il motivo che ha spinto AMD a cancellare un'architettura che sembrava in grado di lottare praticamente sullo stesso piano di quella INTEL nel mercato data-center, come k10, che non avrà chissà quale ipc, ma consumava niente nei confronti di Nehalem a parità di clock con i 45nm...
il fatto che per quanto una architettura possa essere buona con un silicio che ti soffoca le prestazioni sul nascere, c'è poco da fare...Credo che in INTEL non siano dei sprovveduti se hanno investito (investono?) quanto TSMC, GLOFO, SAMSUNG e ST messi assieme....

i 32nm per certi versi rassomigliano e molto i 65nm SOI..

[cdimauro]

Non lo sono sicuramente, visto che continuano a investirci. E... si stanno muovendo... ma non posso dire altro.

Originariamente inviato da bjt2

Beh si, è chiaro che si risparmia solo con le microcodificate... Per le altre non serve...
Ricordavo di questa statistica. Ma ci sono le istruzioni di context switch, bound check, stack frame management e altre per virtualizzazione che sono sicuramente microcodificate. Non credo che siano poi così rare...

Invece sono molto rare.

Quelle di bound check e di stack manipulation, poi, non le usa praticamente nessuno, perché sono troppo lente.
Infatti il prologue delle funzioni utilizza delle normale istruzioni di PUSH/MOV/SUB, mentre l'epilogue usa la LEAVE, che però non è microdificata.
Mentre per il bound check Intel ha tirato fuori un'estensione completamente nuova: MPX. Proprio perché nessuna usava la BOUND, che così com'era non era tanto utile.

Riguardo a context switch e virtualizzazione, devi contestualizzare: in un secondo = 3-4 miliardi di cicli di clock, QUANTE volte vengono utilizzate? Pochissime volte. E ogni volta COME vengono utilizzate? One shot: una volta eseguite, non servono più, perché non vengono eseguite in un ciclo, e dunque "cacharle" (brutto termine. ) non serve assolutamente.

E poi le DIV e sqrt sono sicuramente microcodificate visto la latenza e se vedi anche in blender non è che siano così rare... Sospetto che questo sia anche uno dei motivi per cui performa bene...

Se, come penso, una istruzione microcodificata non blocca più il decoder, questo è un grosso vantaggio. Penso sempre a blender: se hai una (F)DIV in un ciclo, quando non c'era la uop cache, tu avevi che a ogni ciclo la DIV (microcodificata) ti bloccava i decoder (e non penso che bastassero 4 uops).

E invece no: FDIV/FSQRT per la vecchia FPU e (V)DIV*/ (V)SQRT* non sono affatto microcodificate (su Steamroller; penso che per Zen sarà la stessa cosa).

Non confondere latenza (quella è elevata, senz'altro) con numero di uop necessarie per eseguire l'istruzione.

Se ti scorri il manuale delle ottimizzazioni di Agner, vedrai tu stesso che la microcodifica c'è in tante istruzioni, ma sono veramente rare... SE vengono usate nel codice. Perché dubito che i compilatori le usino tutte; secondo me alcune nemmeno vengono mai emesse.

Con la uop cache ma senza questo trucco, il decoder ti viene bloccato solo la prima volta, ma consumi molto spazio nella uop cache per le uop della divisione.

Per la divisione, come già detto. Per quelle realmente microcodificate, è corretto.

Con questo meccanismo occupi un solo slot (dovrebbe bastare, non credo che la rom sia così grande da richiedere un puntatore enorme) ed hai una unità separata dal decoder che ti spara le uop: questo è maggiore pipelining e sospetto che contribuisca ulteriormente ad abbassare il FO4, perchè hai sgravato lo stadio di decoding dal compito di sparare le uop, risparmiando anche un muxer a valle dei decoder per muxare tra le uop dai decoder e quelle dalla microcode rom...

Questo succede anche con le (micro)architetture Intel: le uop delle istruzioni microcodificate non vengono generate dal decoder, ma da un'apposita sezione che si ricongiunge poi alla micro-op cache. Il design di Zen è molto simile a quello Intel (praticamente identico a prima vista).

Ma non so se Intel usa il trucchetto del puntatore alla uop. Questa potrebbe essere l'unica differenza sostanziale (ad alto livello, ovviamente).

Zen ha il partizionamento statico in SMT per la(le?) retire queue. Se sono separate come sembra, 2+2 per thread mi sembra un po' poco, sopratutto per gestire un picco. Lui ha esplicitamente detto a voce che sono così grandi per gestire il picco. 4+4 per thread mi sembra ragionevole. E poi così le voci di uno Zen+ con SMT4 acquistano ancora più consistenza. Se vedi in quel video, all'inizio c'è la presentazione di skylake, poi il power9 e poi Zen. Il power9 per SMT 4 non è che abbia poi tutte ste pipe in più anche dello zen attuale. Anzi forse meno. E da bench che girano in rete, solo in SMT 8 il guadagno è irrisorio. Ma da SMT2 a SMT4 c'è ancora un po' di succo da spremere. E se non mi sbaglio il power9 può ritirare 8 uop/ciclo...

Che non sono 16.

Come già detto, 8+8 sono veramente troppe, a fronte del throughput del backend. E questo anche tenendo conto di eventuali limiti di partizionamento dovuti all'esecuzione di due thread.

Originariamente inviato da Piedone1113

Esatto, ma quell'architettura con quei path non sfrutterebbe le possibilità offerte dal nuovo pp, ma consentirebbe una riduzione di area / consumo relativa alla sola derivazione fisica del processo.
Mi spiego meglio:
l'architettura core è stata studiata per i 45nm ed ottimizzata per essa.
il passaggio a 32 nm ha avuto una revisione ed un adattamento che ne ha aumentato l'ipc e la frequenza (quest'ultima relativa) ed un leggero abbassamento del consumo medio a parità di frequenza.
Stessa cosa per i pp successivi fino al 16+ che ha portato un aumento del consumo limitato a fronte di un aumento delle frequenze leggermente maggiore (ed ipc pressochè immutato rispetto al 16 liscio).
Quello che dico non è che l'architettura core è diventata ineffeciente con il passaggio a pp inferiori, ma che un'architettura ex novo avrebbe permesso sicuramente di sfruttare meglio il pp (come nel 45-32 nm) e permesso di ottenere una cpu più efficiente.
Insomma un 6950 10 core gflop X a 140w avrebbe potuto essere un 7950 10 core gflop X in 110w ( insomma sfruttare meglio il pp con un'architettura fatta su misura per esso).

Un poco come ha fatto ibm con Power ed i tanto discussi 32 nm, oppure Amd con zen (e credo che siamo d'accordo nel definire il 16 intel migliore del 14 gf ) che in soli 95w dovrebbe (il condizionale è d'obbligo) offrire prestazioni per watt migliori del 6900x

Cerco di capirti, ma onestamente non capisco perché per sfruttare i benefici di un nuovo processo produttivo si dovrebbe sviluppare un'architettura ex-novo.

Non penso che con Zen AMD abbia buttato tutto quello fatto finora, e ricominciato da zero, reinventandosi la ruota per ogni cosa. Sono convinto che utilizzi molto dei vecchi processori, con alcune parti riprogettate, ovviamente.

Per essere chiari, se devo implementare una certa funzionalità, e ho già a disposizione un circuito che la implementa ottimamente, perché dovrei riprogettarlo da capo?

Con le (micro)architetture è così: si cambia se se ne ravvisa la necessità. Se prendi Skylake, ad esempio, tante cose sono cambiate rispetto ai predecessori, pur mantenendo un design di massima che è abbastanza consolidato.

Intel potrebbe anche progettare una (micro)architettura completamente nuova, certamente, ma questo lo potrebbe fare a prescindere dal processo produttivo.

IBM con POWER e i 32nm non ha assolutamente cambiato la microarchitettura. Tutt'altro. Ha aumentato moltissimo la cache L3 e ritoccato la virtualizzazione, ma tutto il resto è rimasto esattamente così com'è. Diciamo che passando da Haswell a Broadwell (22nm -> 14nm), Intel ha fatto di gran lunga più cambiamenti.

PS hai portato i cleanex dietro?

Beh, in certe occasioni mi stavano proprio scappando qualche lacrima, ma ho cercato di contenermi. Per me rimane un duro colpo.

In bocca al lupo ed i migliori auguri per un futuro pieno di soddisfazioni (e magari tra 2 anni ti ritrovi a lavorare per AMD )

Grazie. Speriamo bene, perché non so come sarà il nuovo lavoro.

Sì, non è certo escluso che possa anche lavorare per AMD in futuro. Se costruisse una sede qui a Ulm. Oppure se accettasse il lavoro da remoto, con alcuni viaggetti alla sede centrale ogni tanto. Perché Intel l'ho lasciata per non dovermi spostare a Monaco (i bambini sono troppo piccoli: non voglio altri traumi, dopo quello mostruoso dello spostamento dall'Italia a qui).

Sono un professionista e non metto dei paletti a prescindere. Ad esempio lavoro spesso con Windows, ma alla BMW dovrò mettere le mani per lo più su Linux. Non per questo ho deciso di non accettare la posizione lavorativa. Andrò avanti lo stesso, e mi farò un nuovo background / bagaglio culturale.

Certo, lavorare per un'azienda che produce o progetta processori è stato un sogno che ho realizzato, e che non mi dispiacerebbe riprendere. Sono 5 anni che lavoro a una mia architettura, che potrebbe fare molto comodo in diversi ambiti. In realtà, a parte l'embedded economico (chip da pochi centinaia di migliaia di transistor), si presta bene per qualunque cosa. Dunque si potrebbe anche usare per le future console, per cominciare in un settore dove il legacy non è indispensabile. HPC... server... pure.

E' tutta roba dove il legacy non serve, o si può comunque aggirare, e dove le prestazioni (nonché la densità di codice) della mia architettura potrebbe fare la differenza rispetto a Intel, ARM, e POWER.

Per cui... vedremo. Anche perché mi spuntano ogni tanto idee che si potrebbero tradurre in brevetti, e mi servirà qualche azienda a cui appoggiarmi per farlo. Però stavo pensando di rifare un salto all'STM, quando sono giù, in Sicilia, a rivedere un po' di colleghi e amici che ci lavorano. Francamente preferirei che a sfruttare certe idee fosse un'azienda nostrana anziché la solita multinazionale americana.

Certamente non ho intenzione di lasciare tutta quella roba nel mio cassetto. Ho diverse cosucce interessanti, e voglio sfruttarle. Per cui mi muoverò in tal senso fra un po' di mesi, dopo che mi sarò ambientato qui alla BMW.

Originariamente inviato da digieffe

quando prenderai servizio nel nuovo posto?

2 Gennaio.

Originariamente inviato da fabius21

coi proci intel non è possibile ciò , ma non sappiamo come andranno tutte quelle funzionalità annunciate da amd. magari sfruttando "un modulo" o soli 4 core , potrebbe far meglio dei 7700k , per via della maggiore superfice di contatto.

Al momento sembra che abbia soltanto un design da 8 core. Quando però ricordo di aver letto, in passato, di un design nativo da 4 core. Boh.

Sempre e solo se questa situazione fosse veritiera , le conviene far una guerra sui prezzi ,perchè azzerebbe la richiesta dei proci 4core intel, altrimenti come hai ben detto tu nel lungo periodo non riuscirebbe a reggere. Perchè le parole di lisa su parlavano di rivoluzione del mercato pc , che ormai è stagnato , altrimenti che rivoluzione sarebbe? nessuna se non nell'ambito economico, visto solo come un abbassamento dei prezzi.
Le mie molto probabilmente saranno sogni/deliri o come li vogliam chiamare però una minima possibilità c'è . Poi io coi pc son un pò avanti col pensiero , nel senso che già dai pentium-2 i miei pc gestiscono 2 thread come così nel 2000 volevo passare la scheda grafica alle macchine virtuali , ero in anticipo solo di 10 anni tecnologicamente XD e possiam dire 13 se calcoliamo il software

Non è delirio. Personalmente lo trovo più un wishful thinking.

Come ha scritto digieffe negli commenti, e con cui sono d'accordo, parliamo pur sempre di aziende votate al massimo profitto.

Non ha senso realizzare un buon prodotto e venderlo a prezzi stracciati, quando il valore di mercato (che è ciò che conta) è un altro.

Poi, che dire: aspettiamo e vediamo. Ma io la penso così.

Ti auguro una buona chiusura del rapporto lavorativo e un buon inizio nel nuovo lavoro

Grazie!

Originariamente inviato da paolo.oliva2

P.S.
Il termine Onlus è comparso da molto prima delle persone attuali nel TH... quindi non faccio polemica specifica verso una persona.

Tranquillo, Paolo: richiamare Onlus in quel contesto è un comunissimo modo di dire.

Originariamente inviato da bjt2

Sul thread su anand gli avevano contestato che aveva provato con un dual xeon, che aveva troppi core, che era numa e blablabla.
Ora con un quadcore ottiene gli stessi risultati (per l'IPC calcolato di Zen).

Avrà anche sottostimato l'IPC di ivybridge (perchè ha molti core, è 2p ecc) ma non ha sbagliato sull'IPC di Zen perchè il suo software conta le istruzioni, da cui si possono ricavare le istruzioni totali, che sono le stesse di Zen (la versione ufficiale di blender non fa schedulazione separata a seconda della cpu)

Quindi ragionevolmente ha coperto tutto lo spettro. Comunque sta cercando di procurarsi broadwell, skylake più potenti e kabilake...

Ma infatti quel metodo l'avevo già descritto nei miei scontri con gli altri (fra cui Dresdenboy) su AnandTech.

Non è il metodo di per sé a essere sbagliato (d'altra parte, come lo calcoli l'IPC, se non così), ma la piattaforma che ha utilizzato che era sbagliata. E vedo che gli hanno fatto le stesse critiche che ti ho sollevato pure io qui.

C'è solo un appunto sul resto: lui non ha Zen, e non sa quante istruzioni siano state effettivamente eseguite. Per cui penso che abbia usato quelle eseguite sui processori Intel. Personalmente mi aspetto differenze assolutamente trascurabili fra Zen e i processori Intel, ma questo lo preciso.

Buona giornata a tutti.

[paolo.oliva2]

Originariamente inviato da george_p

Guardiamo i fatti, se BD fosse stato all'altezza anche con un silicio poco performante avrebbe detto la sua in diverse occasioni.
invece AMD ha perso quote di mercato e non hanno tirato a dadi per tornare su un approccio diverso dal CMT implementando finalmente l'SMT.
Poi non si dice che sia assolutamente scarso ma ha messo l'azienda nella condizioni di medio-sufficienza.
Questo va riconosciuto.

Io penso una cosa... che Intel ha vinto per un semplice motivo... perchè quando ha saputo che AMD vendeva le FAB, ha investito sul silicio.
Tuttodigitale riporta "Credo che in INTEL non siano dei sprovveduti se hanno investito (investono?) quanto TSMC, GLOFO, SAMSUNG e ST messi assieme....", perchè ha intuito che se hai un silicio performante, l'avversario può fare pure i miracoli architetturalmente, ma non ci caverebbe una tozza.

Io concordo che una architettura può essere più o meno efficiente rispetto ad un'altra, ma credo che l'indice prestazionale di architettura + silicio sia rappresentato dalla massima potenza a die in correlazione al TDP.

Il 65nm vedeva un Phenom I X4, il 45nm ha visto il Thuban X6 (+60% almeno), il 32nm ha visto l'8350 (+20% sul Thuban) e Zen vedrà +100% almeno sull'8350.

Io concordo al 1000000% che BD abbia contribuito a perdere nella potenza ST rispetto a qualsiasi altra architettura al suo posto, ma dobbiamo pure considerare che la massima potenza ST Intel l'ha grazie ai suoi core, indubbiamente, ma grazie al silicio ha consentito alla sua architettura di annullare le frequenze superiori di BD, e questo per certo ha contribuito ad aumentarla e far risaltare ancor più la pecca di BD.

Ma un Zen al posto di BD, sul 32nm, avrebbe concesso un X4+4 al posto di un 8350, ovvero una potenza ST superiore ma circa la stessa potenza MT. Zen non avrebbe mai concesso un 5960X sul 32nm.... la battaglia AMD l'avrebbe persa ugualmente, perchè avevqa perso la battaglia sul silicio... Un Zen X2+2 sicuramente sarebbe stato competitivo vs gli i3, ma sembra una fotocopia di BD, perchè alla fin fine, quando il silicio è sufficiente tanto da non limitare le prestazioni, pure BR (BD) non è che sia distante dagli i3.

[Phopho]

Originariamente inviato da bjt2

Sul thread su anand gli avevano contestato che aveva provato con un dual xeon, che aveva troppi core, che era numa e blablabla.
Ora con un quadcore ottiene gli stessi risultati (per l'IPC calcolato di Zen).

Avrà anche sottostimato l'IPC di ivybridge (perchè ha molti core, è 2p ecc) ma non ha sbagliato sull'IPC di Zen perchè il suo software conta le istruzioni, da cui si possono ricavare le istruzioni totali, che sono le stesse di Zen (la versione ufficiale di blender non fa schedulazione separata a seconda della cpu)

Quindi ragionevolmente ha coperto tutto lo spettro. Comunque sta cercando di procurarsi broadwell, skylake più potenti e kabilake...

grazie per la spiegazione

[bjt2]

Originariamente inviato da cdimauro

Non lo sono sicuramente, visto che continuano a investirci. E... si stanno muovendo... ma non posso dire altro.

Invece sono molto rare.

Quelle di bound check e di stack manipulation, poi, non le usa praticamente nessuno, perché sono troppo lente.
Infatti il prologue delle funzioni utilizza delle normale istruzioni di PUSH/MOV/SUB, mentre l'epilogue usa la LEAVE, che però non è microdificata.
Mentre per il bound check Intel ha tirato fuori un'estensione completamente nuova: MPX. Proprio perché nessuna usava la BOUND, che così com'era non era tanto utile.

Riguardo a context switch e virtualizzazione, devi contestualizzare: in un secondo = 3-4 miliardi di cicli di clock, QUANTE volte vengono utilizzate? Pochissime volte. E ogni volta COME vengono utilizzate? One shot: una volta eseguite, non servono più, perché non vengono eseguite in un ciclo, e dunque "cacharle" (brutto termine. ) non serve assolutamente.

In effetti il loro apporto è trascurabile...

Originariamente inviato da cdimauro

E invece no: FDIV/FSQRT per la vecchia FPU e (V)DIV*/ (V)SQRT* non sono affatto microcodificate (su Steamroller; penso che per Zen sarà la stessa cosa).

Non confondere latenza (quella è elevata, senz'altro) con numero di uop necessarie per eseguire l'istruzione.

Se ti scorri il manuale delle ottimizzazioni di Agner, vedrai tu stesso che la microcodifica c'è in tante istruzioni, ma sono veramente rare... SE vengono usate nel codice. Perché dubito che i compilatori le usino tutte; secondo me alcune nemmeno vengono mai emesse.

Per la divisione, come già detto. Per quelle realmente microcodificate, è corretto.

Buono a sapersi. Avevo pensato che fossero microcodificate sia perchè l'algoritmo è iterativo e al massimo si sentiva dire che era di tipo radix 16 (4 bit alla volta), sia perchè spesso non sono pipelined e bloccano la pipe per tutto il tempo di esecuzione... Meglio così... Si spera che prima o poi qualcuno le faccia fully pipelined (se sai qualcosa, ogni informazione è benvenuta... ).

BTW sembra che quelli di instxlat64 abbiano zen, perchè hanno fatto prove con AIDA per calcolare le latenze e dicono che sono tutte sbagliate quelle che avevano ipotizzato dalle patch di gcc... In arrivo il chart aggiornato: https://twitter.com/InstLatX64/statu...40863748685824 versione 1.5 con la colonna di Zen lasciata intenzionalmente bianca: https://twitter.com/InstLatX64/statu...00676373032966

Originariamente inviato da cdimauro

Questo succede anche con le (micro)architetture Intel: le uop delle istruzioni microcodificate non vengono generate dal decoder, ma da un'apposita sezione che si ricongiunge poi alla micro-op cache. Il design di Zen è molto simile a quello Intel (praticamente identico a prima vista).

Ma non so se Intel usa il trucchetto del puntatore alla uop. Questa potrebbe essere l'unica differenza sostanziale (ad alto livello, ovviamente).

https://youtu.be/Ln9WKPEHm4w?t=17m56s Forse è troppo ad alto livello, ma in Zen tra il mux e la uop queue c'è lo stack memfile che filtra le operazioni e la microcode rom che invece le espande. Da questo diagramma invece sembra che l'architettura intel sia piuttosto standard e la microcode rom potrebbe stare vicino o subito dopo i decoder...

Originariamente inviato da cdimauro

Che non sono 16.

Come già detto, 8+8 sono veramente troppe, a fronte del throughput del backend. E questo anche tenendo conto di eventuali limiti di partizionamento dovuti all'esecuzione di due thread.

Può anche darsi che il tizio si sia espresso male.

Originariamente inviato da cdimauro

Beh, in certe occasioni mi stavano proprio scappando qualche lacrima, ma ho cercato di contenermi. Per me rimane un duro colpo.

Grazie. Speriamo bene, perché non so come sarà il nuovo lavoro.

Sì, non è certo escluso che possa anche lavorare per AMD in futuro. Se costruisse una sede qui a Ulm. Oppure se accettasse il lavoro da remoto, con alcuni viaggetti alla sede centrale ogni tanto. Perché Intel l'ho lasciata per non dovermi spostare a Monaco (i bambini sono troppo piccoli: non voglio altri traumi, dopo quello mostruoso dello spostamento dall'Italia a qui).

In bocca al lupo per il tuo lavoro... Di cuore...

Originariamente inviato da cdimauro

Sono un professionista e non metto dei paletti a prescindere. Ad esempio lavoro spesso con Windows, ma alla BMW dovrò mettere le mani per lo più su Linux. Non per questo ho deciso di non accettare la posizione lavorativa. Andrò avanti lo stesso, e mi farò un nuovo background / bagaglio culturale.

Certo, lavorare per un'azienda che produce o progetta processori è stato un sogno che ho realizzato, e che non mi dispiacerebbe riprendere. Sono 5 anni che lavoro a una mia architettura, che potrebbe fare molto comodo in diversi ambiti. In realtà, a parte l'embedded economico (chip da pochi centinaia di migliaia di transistor), si presta bene per qualunque cosa. Dunque si potrebbe anche usare per le future console, per cominciare in un settore dove il legacy non è indispensabile. HPC... server... pure.

E' tutta roba dove il legacy non serve, o si può comunque aggirare, e dove le prestazioni (nonché la densità di codice) della mia architettura potrebbe fare la differenza rispetto a Intel, ARM, e POWER.

E' anche il mio sogno, di progettare una CPU, ci penso spesso... Ti auguro di realizzarlo...
Anche io ho parecchie idee e una in particolare AMD finalmente l'ha realizzata, anche se in "scala ridotta". Sto parlando del PTE coalescing... In Zen 8 pagine contigue possono essere memorizzate in una sola TLB entry di pagina 4k, senza intervento del SO (ovviamente in memoria la page table non cambia). Io avevo pensato a una cosa senza limiti, ma 2 registri con pagina iniziale e finale in modo che il range potesse essere illimitato... Ma già una compressione 8:1 è notevole...

Originariamente inviato da cdimauro

Per cui... vedremo. Anche perché mi spuntano ogni tanto idee che si potrebbero tradurre in brevetti, e mi servirà qualche azienda a cui appoggiarmi per farlo. Però stavo pensando di rifare un salto all'STM, quando sono giù, in Sicilia, a rivedere un po' di colleghi e amici che ci lavorano. Francamente preferirei che a sfruttare certe idee fosse un'azienda nostrana anziché la solita multinazionale americana.

Certamente non ho intenzione di lasciare tutta quella roba nel mio cassetto. Ho diverse cosucce interessanti, e voglio sfruttarle. Per cui mi muoverò in tal senso fra un po' di mesi, dopo che mi sarò ambientato qui alla BMW.

Ma STM non è stata acquisita e non è più italiana?

Originariamente inviato da cdimauro

Ma infatti quel metodo l'avevo già descritto nei miei scontri con gli altri (fra cui Dresdenboy) su AnandTech.

Non è il metodo di per sé a essere sbagliato (d'altra parte, come lo calcoli l'IPC, se non così), ma la piattaforma che ha utilizzato che era sbagliata. E vedo che gli hanno fatto le stesse critiche che ti ho sollevato pure io qui.

C'è solo un appunto sul resto: lui non ha Zen, e non sa quante istruzioni siano state effettivamente eseguite. Per cui penso che abbia usato quelle eseguite sui processori Intel. Personalmente mi aspetto differenze assolutamente trascurabili fra Zen e i processori Intel, ma questo lo preciso.

Buona giornata a tutti.

Che io sappia blender non fa schedulazione sulla CPu, quindi il codice dovrebbe essere lo stesso...

[bjt2]

Originariamente inviato da cdimauro

Invece sono molto rare.

Quelle di bound check e di stack manipulation, poi, non le usa praticamente nessuno, perché sono troppo lente.
Infatti il prologue delle funzioni utilizza delle normale istruzioni di PUSH/MOV/SUB, mentre l'epilogue usa la LEAVE, che però non è microdificata.
Mentre per il bound check Intel ha tirato fuori un'estensione completamente nuova: MPX. Proprio perché nessuna usava la BOUND, che così com'era non era tanto utile.

Riguardo a context switch e virtualizzazione, devi contestualizzare: in un secondo = 3-4 miliardi di cicli di clock, QUANTE volte vengono utilizzate? Pochissime volte. E ogni volta COME vengono utilizzate? One shot: una volta eseguite, non servono più, perché non vengono eseguite in un ciclo, e dunque "cacharle" (brutto termine. ) non serve assolutamente.

E invece no: FDIV/FSQRT per la vecchia FPU e (V)DIV*/ (V)SQRT* non sono affatto microcodificate (su Steamroller; penso che per Zen sarà la stessa cosa).

Non confondere latenza (quella è elevata, senz'altro) con numero di uop necessarie per eseguire l'istruzione.

Se ti scorri il manuale delle ottimizzazioni di Agner, vedrai tu stesso che la microcodifica c'è in tante istruzioni, ma sono veramente rare... SE vengono usate nel codice. Perché dubito che i compilatori le usino tutte; secondo me alcune nemmeno vengono mai emesse.

Per la divisione, come già detto. Per quelle realmente microcodificate, è corretto.

Sono andato a scorrere il pdf di agner fog, alla sezione AMD più nuova (Steamroller).http://www.agner.org/optimize/instruction_tables.pdf

Effettivamente quasi tutte le DIV hanno 1 o 2 MOP, tranne la 8 e 16 bit che quindi è microcodificata. Le SQRT hanno più di 2 mop quindi anche queste lo sono. Alcune routine di push e pop (per i flag) che dovrebbero essere usate in tutte le ISR sono microcodificate, ma qui, ovviamente sono usate pochissimo, perchè le interruzioni non sono poi così frequenti.

Ci siamo scordati tre classi di istruzioni che possono non essere così rare e che sono microcodificate: le istruzioni di locking (per tutti i semafori, quindi usate spesso nel SO ma anche in codice utente, se multitasking/threading), le istruzioni di crittografia, usate spesso nei software a cui serve (quindi penso a VPN, driver del file system nel caso sia criptato, browser quando si usa l'https) e le istruzioni stringa. Se supponiamo che memcpy sia implementato con REP MOVxx, allora potrebbe essere anche usata spesso. E avere in uop cache solo il placeholder alla routine potrebbe essere vantaggioso...

[george_p]

Originariamente inviato da tuttodigitale

sarebbe stato davvero strano NON passare da QUATTRO implementazioni parziali del SMT, ad una cpu con SMT anche lato integer (anche se come fatto notare da Cesare anche la parte integer, beneficia dal CMT con carico scarsamente parallelizzabile).

Semmai non era logico passare al SMT2, ma direttamente ad un più esotico SMT2+CMT (4thread sulla fpu) o addirittura SMT4...anche li avranno ragionato..e non è detto che ZEN non debba svilupparsi in tal senso se le AVX-256, prenderanno piede (ma perchè dubitarne?)

Non lo so, pare che le cpu con SMT2, ma anche 8-vie debbano avere un ipc relativamente alto, dimenticandosi per strada che il P4 era con il SMT e conroe no..
sul fatto che BD, non sembrerebbe affatto un progetto troppo spinto lato frequenza sui 32nm SOI ce l'ha fatto notare CESARE, facendo l'esempio di IBM che ha migliorato le prestazioni per watt di brutto con una cpu da oltre 5GHz....
quel silicio, a livello di leakage rassomiglia più i finfet che non i bulk planari....

Originariamente inviato da tuttodigitale

la differenza tra propus e agena pare insignificante
http://www.anandtech.com/bench/product/106?vs=21


direi soprattutto
2,6GHz@140W ->3,7GHz@125W



con la stessa frequenza del phenom 9950 (2,6GHz), su 45nm AMD proponeva Opteron a 8 core con TDP da 115W...credo che non ci sia bisogno di commentare.



@george_p
se BD/PD fosse stata una pessima architettura, quale è il motivo che ha spinto AMD a cancellare un'architettura che sembrava in grado di lottare praticamente sullo stesso piano di quella INTEL nel mercato data-center, come k10, che non avrà chissà quale ipc, ma consumava niente nei confronti di Nehalem a parità di clock con i 45nm...
il fatto che per quanto una architettura possa essere buona con un silicio che ti soffoca le prestazioni sul nascere, c'è poco da fare...Credo che in INTEL non siano dei sprovveduti se hanno investito (investono?) quanto TSMC, GLOFO, SAMSUNG e ST messi assieme....

i 32nm per certi versi rassomigliano e molto i 65nm SOI..

Nessuno se non la sola AMD ha le informazioni più corrispondenti alla verità ... Ipotizzo che amd non avesse (in effetti non li aveva) liquidi sufficienti per spingere sul miglioramento del silicio 32 soi come pare abbia fatto IBM che in fatto di liquidi "inonda" la prima.

Se hai i soldi riesci a fare tutto anche su un processo che apparentemente e inizialmente può sembrare poco buono, se i soldi non ce li hai ti appendi da qualche parte.

Penso sia un buon elemento per capire la differenza tra lo stesso silicio usato per IBM e quello usato per AMD.
CHe ne dici/dite?

BD mancava di sufficiente IPC figuriamoci di buon IPC visto che per definirlo buono doveva essere 25% sopra l'architettura precedente e non 25% sotto, per non parlare che sempre rispetto a quella precedente perdeva anche in MT un ulteriore 10% (recuperato solo con Kaveri), per cui già sappiamo che per recuperare in prestazioni aveva bisogno di frequenze elevate.
Il resto è storia per mancanza di buon silicio, vuoi che sia stata amd incapace vuoi che non abbia avuto i soldi per migliorarlo (anche se son dell'idea che spetterebbe alla fabbrica di turno investirci sopra).

Per quanto riguarda Zen e SMT1/2/4 non so che risponderti poiché non sono minimamente informato, aspetto di vedere i risultati su strada come per BD.

[bomkill]

Originariamente inviato da digieffe

ho perso il post con il quale spiegavo una possibile logica dei prezzi, sintetizzo al max, spero si capisca

SE il top dovesse andare in media più del 6900k:
Zen top 1001$ (8c, più potente del 8c intel e più costoso)
Zen 2° 600$ (8c, più potente del 6 top intel, stesso prezzo)
Zen 3° 450$ (6/8c più potente del 6 2° intel, stesso prezzo)
Zen 4° 350$ (6c, più potente in MT, vicino in ST, al 4c top intel stesso prezzo)

BD 9xxx vs i5
SR vs i3

gmail
Se cosi fosse specie Zen Amd non venderebbe una beata fava le persone non stanno aspettando Zen per spendere poco meno se devo spendere poco meno scelgo intel (anche per ripicca) Se amd vuole vendere deve esordire con un i5 a 150€ un i7 da 220 e un i7 E da 350.

[Gioz]

Originariamente inviato da bomkill

gmail
Se cosi fosse specie Zen Amd non venderebbe una beata fava le persone non stanno aspettando Zen per spendere poco meno se devo spendere poco meno scelgo intel (anche per ripicca) Se amd vuole vendere deve esordire con un i5 a 150€ un i7 da 220 e un i7 E da 350.

mi sembra veramente troppo ottimistica come aspettativa lato consumatore, è come aspettarsi che la dacia fatta un'automobile di livello lamborghini aventador e te la venda a 90mila euro. poi tutto può essere, ma per aggressività sui prezzi non mi sembra plausibile una spesa del 30% per un prodotto simile.

se poi avrai avuto ragione ne sarò sicuramente felice

[.Hellraiser.]

Originariamente inviato da bomkill

gmail
Se cosi fosse specie Zen Amd non venderebbe una beata fava le persone non stanno aspettando Zen per spendere poco meno se devo spendere poco meno scelgo intel (anche per ripicca)

non è detto, io se amd facesse un'ottima cpu la comprerei pure se costasse più di intel, se le prestazioni ci sono non capisco che problema ci sarebbe a meno di non essere proprio legati ad un marchio piuttosto che all'altro (dando per scontato che la piattaforma sia almeno equivalente come funzionalità)

[capitan_crasy]

Originariamente inviato da Veradun

Niente più che rumors/speculazioni del tutto non confermate. E il fatto che entro fine anno vogliano presentare Raven Ridge mi fa pensare che un design nativo 4c sia quello da inserire nel progetto APU, non da proporre come CPU, anche perché vorrebbe dire fare una sovrapposizione di prodotto francamente del tutto inutile.

Esistono dei codici OPN di CPU ES ZEN a 4 core; che siano di derivazione degli 8 core oppure dei quad core nativi per ora non si sa (personalmente credo che siano nativi)...
Raven Ridge dovrebbe essere pronto a 2017 inoltrato (credo verso la fine del 2017) e ad oggi esistono i primi sample funzionanti, ma siamo sono all'inizio...

[bjt2]

Originariamente inviato da bjt2

BTW sembra che quelli di instxlat64 abbiano zen, perchè hanno fatto prove con AIDA per calcolare le latenze e dicono che sono tutte sbagliate quelle che avevano ipotizzato dalle patch di gcc... In arrivo il chart aggiornato: https://twitter.com/InstLatX64/statu...40863748685824 versione 1.5 con la colonna di Zen lasciata intenzionalmente bianca: https://twitter.com/InstLatX64/statu...00676373032966

Mi quoto, perchè forse in mezzo alle risposte tecniche a cdmauro, qualcuno non l'ha notato... Non volevo fare due post, ma purtroppo a volte è necessario...

[bomkill]

Originariamente inviato da Gioz

mi sembra veramente troppo ottimistica come aspettativa lato consumatore, è come aspettarsi che la dacia fatta un'automobile di livello lamborghini aventador e te la venda a 90mila euro. poi tutto può essere, ma per aggressività sui prezzi non mi sembra plausibile una spesa del 30% per un prodotto simile.

se poi avrai avuto ragione ne sarò sicuramente felice

Sia chiaro parlo da consumatore io mi accontenterei di uno Zen 4+4 che in st pareggi gli i5 e in mt sia in zona i7 base sui 200/250 max.
Qualcuno nel forum saprà sicuramente la verità ma non potrà dirlo,vedo diversi frequentatori troppo tecnici per essere semplici appassionati.
Comunque spero che Amd dipani al più presto il mistero , e da 1 anno che ho dato via il mio pc principale in attesa di Zen( o intel se Zen non sarà all'altezza).

[Roland74Fun]

Originariamente inviato da digieffe

ho perso il post con il quale spiegavo una possibile logica dei prezzi, sintetizzo al max, spero si capisca

SE il top dovesse andare in media più del 6900k:
Zen top 1001$ (8c, più potente del 8c intel e più costoso)
Zen 2° 600$ (8c, più potente del 6 top intel, stesso prezzo)
Zen 3° 450$ (6/8c più potente del 6 2° intel, stesso prezzo)
Zen 4° 350$ (6c, più potente in MT, vicino in ST, al 4c top intel stesso prezzo)

BD 9xxx vs i5
SR vs i3

Potrebbero darli in regalo colle patatine, od allegarli eventualmete a Famiglia Cristiana a 4.90€ più il prezzo della rivista.

[Grizlod®]

Originariamente inviato da bjt2

Mi quoto, perchè forse in mezzo alle risposte tecniche a cdmauro, qualcuno non l'ha notato... Non volevo fare due post, ma purtroppo a volte è necessario...

Sembra abbiano un sample di quelli apparsi su Geekbench 4 quest'estate (quindi non ultimissima revisione).
Dal grafico (interpretazione personale) sembra sia sprovvisto di AVX 512, in quanto hanno messo un trattino (-), tanto come in µop-cache ed L3 size per Excavator e Bristol Ridge, non lasciando il campo in blanc.

[digieffe]

Originariamente inviato da paolo.oliva2

Io penso una cosa... che Intel ha vinto per un semplice motivo... perchè quando ha saputo che AMD vendeva le FAB, ha investito sul silicio.
Tuttodigitale riporta "Credo che in INTEL non siano dei sprovveduti se hanno investito (investono?) quanto TSMC, GLOFO, SAMSUNG e ST messi assieme....", perchè ha intuito che se hai un silicio performante, l'avversario può fare pure i miracoli architetturalmente, ma non ci caverebbe una tozza.

Io concordo che una architettura può essere più o meno efficiente rispetto ad un'altra, ma credo che l'indice prestazionale di architettura + silicio sia rappresentato dalla massima potenza a die in correlazione al TDP.

Il 65nm vedeva un Phenom I X4, il 45nm ha visto il Thuban X6 (+60% almeno), il 32nm ha visto l'8350 (+20% sul Thuban) e Zen vedrà +100% almeno sull'8350.

Io concordo al 1000000% che BD abbia contribuito a perdere nella potenza ST rispetto a qualsiasi altra architettura al suo posto, ma dobbiamo pure considerare che la massima potenza ST Intel l'ha grazie ai suoi core, indubbiamente, ma grazie al silicio ha consentito alla sua architettura di annullare le frequenze superiori di BD, e questo per certo ha contribuito ad aumentarla e far risaltare ancor più la pecca di BD.

Ma un Zen al posto di BD, sul 32nm, avrebbe concesso un X4+4 al posto di un 8350, ovvero una potenza ST superiore ma circa la stessa potenza MT. Zen non avrebbe mai concesso un 5960X sul 32nm.... la battaglia AMD l'avrebbe persa ugualmente, perchè avevqa perso la battaglia sul silicio... Un Zen X2+2 sicuramente sarebbe stato competitivo vs gli i3, ma sembra una fotocopia di BD, perchè alla fin fine, quando il silicio è sufficiente tanto da non limitare le prestazioni, pure BR (BD) non è che sia distante dagli i3.

secondo me ti sbagli ampiamente, un zen x8 a 3.0ghz freq base nei 140w ci sarebbe stato benissimo, potendo competere col 5960x, oppure mi stai dicendo che il 14mnm attuale consente un risparmio di consumi maggiore di 2x.

[george_p]

Originariamente inviato da bjt2

Mi quoto, perchè forse in mezzo alle risposte tecniche a cdmauro, qualcuno non l'ha notato... Non volevo fare due post, ma purtroppo a volte è necessario...

...che significa...?

Originariamente inviato da bomkill

Sia chiaro parlo da consumatore io mi accontenterei di uno Zen 4+4 che in st pareggi gli i5 e in mt sia in zona i7 base sui 200/250 max.

Ma quando si parla di un prodotto realizzato da una azienda non si può ragionare come un consumatore. O per lo meno confrontare sempre due posizioni differenti.
Perché anche a me farebbe piacere il tuo punto di vista ma se vado a vedere i costi di una azienda per fare arrivare il prodotto finale a me vedo che il prezzo del singolo bene aumenta durante il percorso dall'azienda a casa mia.

Qualcuno nel forum saprà sicuramente la verità ma non potrà dirlo,vedo diversi frequentatori troppo tecnici per essere semplici appassionati.
Comunque spero che Amd dipani al più presto il mistero , e da 1 anno che ho dato via il mio pc principale in attesa di Zen( o intel se Zen non sarà all'altezza).

Verità, questa sconosciuta.
Solo gli addetti ai lavori di Zen sanno la verità e aggiungo forse, non certo i più preparati tecnici che frequentano questo e altri forums. Perché se così fosse non esisterebbero chilometri di parole per formulare il proprio punto di vista su cosa sia Zen.

[george_p]

Originariamente inviato da paolo.oliva2

Ma un Zen al posto di BD, sul 32nm, avrebbe concesso un X4+4 al posto di un 8350, ovvero una potenza ST superiore ma circa la stessa potenza MT. Zen non avrebbe mai concesso un 5960X sul 32nm.... la battaglia AMD l'avrebbe persa ugualmente, perchè avevqa perso la battaglia sul silicio... Un Zen X2+2 sicuramente sarebbe stato competitivo vs gli i3, ma sembra una fotocopia di BD, perchè alla fin fine, quando il silicio è sufficiente tanto da non limitare le prestazioni, pure BR (BD) non è che sia distante dagli i3.

Premettendo che tanto è realtà che non vedremo mai e quindi possiamo solo ipotizzare, la penso in modo diverso.
Ok, forse sul 32nm Zen 8+8 non ci sarebbe stato ma almeno 6+6 si però, visti i minori consumi rispetto all'architettura modulare CMT. E avrebbe dato ampio respiro ad amd per competere con intel.
Ma tanto questa è pura fantasia no? In primis perché Zen nasce dalla "cattiva" condotta del ceo che ha pure progettato BD, quindi senza quell'esperienza in casa AMD non ci sarebbe stato Zen.

Ma poi, perché costruire ogni volta tutte ste storie sul Se, sul Ma e sul Però?
Ma aspettiamo sto benedetto Zen, ormai manca davvero poco.

Originariamente inviato da digieffe

secondo me ti sbagli ampiamente, un zen x8 a 3.0ghz freq base nei 140w ci sarebbe stato benissimo, potendo competere col 5960x, oppure mi stai dicendo che il 14mnm attuale consente un risparmio di consumi maggiore di 2x.

Anche questo non è da scartare infatti.

[Ren]

Originariamente inviato da digieffe

secondo me ti sbagli ampiamente, un zen x8 a 3.0ghz freq base nei 140w ci sarebbe stato benissimo, potendo competere col 5960x, oppure mi stai dicendo che il 14mnm attuale consente un risparmio di consumi maggiore di 2x.

Se c'è riuscito pure il sandy bridge (Xeon 32nm)...