[Thread Ufficiale] Aspettando ZEN

[tuttodigitale]

Originariamente inviato da Ren

Ma che news hai preso ,sembra il libro dei sogni di intel prescott...


http://image.slidesharecdn.com/20130...?cb=1365183251

Il clock con tutti i core attivi è aumenato del 20%, più gli acceleratori, la cache quasi tripla e SIMD+.

Sono valori (volutamente) indicativi. Il power7 i 3 GHz non sa neppure cosa siano: il modello a frequenza più bassa ha 3,3GHz di frequenza base
Il modello 7, più potente ha una frequenza di 3,7-4,25 , quello 7+ 3,72-4,42GHz (si quel + vicino a GHz indica un formidabile +0,4%) raggiunti spegnendo la metà dei core
Di certo ci saranno dei carichi di lavoro dove le cache faranno enormi differenze.

Visto che oggettivamente l'aumento di frequenza è miserabile...vediamo cosa offre lato IPC
dati IBM (HPC Performance Report)
Power 7+ 3,6GHz 8 core 102,4
Power 7 3,7GHz 8 core 101,6

per un pauroso aumento di IPC del 3,6%...

Se l'ufficio marketing parla di un'aumento del 15% (purtroppo non riesco a trovare il link) lato efficienza perchè attendersi di più?

Originariamente inviato da Ren

Tuttodigitale è un aficionado delle pipe lunghe...

Adesso lo sa anche bjt2. Doveva essere un segreto
Accorciarle è un conto, corte è un 'altro. Se saranno lunghe 18 stadi, keller mi farà contento .

Originariamente inviato da bjt2

Questo ci dice che le unità di Zen sono più "chiattone" da poter fare in meno cicli le operazioni...

Non deve essere né "chiatta" nè uno "Stuzzicadente", ma deve essere una "bella gn ...unità"

[bjt2]

Originariamente inviato da gridracedriver

scusa se chiedo, riusciresti a spiegarti meglio?
hanno accorciato la pipe nel caso delle moltiplicazioni intere da un minimo di 3 ad un massimo di 4 contro i 4 e 6 di BD? cioè la pipe è più corta da 1 a 2 stadi in meno?

perché alcuni stadi hanno un FO4 superiore ad altri?

Le unità più complesse come le moltiplicazioni sono pipelined, ossia vengono eseguite in più passi, perchè se fossero fatte con meno passi gli stadi della pipeline avrebbero un FO4 più elevato. Diminuire la latenza delle moltiplicazioni significa che servono meno stadi di pipeline per farla, ossia ogni stadio può fare una operazione più complicata, quindi è più complesso, ossia ha un maggiore FO4, da cui clock più basso.

Se il moltiplicatore ha un FO4 più alto vuol dire che anche gli altri stadi hanno un FO4 più alto altrimenti farebbe da tappo, quindi hanno aumentato il FO4 di tutti gli stadi. Questo vuol dire che tutti gli stadi sono più complessi e quindi ci vogliono meno stadi per fare tutto... Quindi questo ci dice che Zen ha meno stadi. E' vero che il clock massimo diminuisce, ma diminuisce anche il numero di cicli necessari per fare alcune operazioni... E sopratutto la latenza per le branch misprediction, anche se con il checkpointing dovrebbe essere ancora minore...

[tuttodigitale]

Spiegazione semplice e chiara.

Vedo che hai trovato il tempo di postare.....
A dopo

EDIT
partita finita
Vedo che la divisione ha sempre un costo di 19 cicli. Ho la sensazione, che la riduzione del costo, sia ottenuto mediante manipolazione funzionali. Ovvero piuttosto che una sola ALU completa, si sia optato ad un frazionamento del compito su più ALU, In sostanza l'ALU non ha stadi grossi, ma fa meno cose. Il risultato sarebbe si una riduzione degli stadi complessivi, ma senza compromettere il FO4.

bjt2 sei a conoscenza delle funzioni delle diverse ALU?

Ho fatto confronti, alla buona, e mi pare che non ci siano sostanziali differenze(ad una prima occhiata mi sono apparsi identici), tra il costo di manipolazione dei dati nei registri della CPU tra ZEN e Bulldozer e ciò vale anche per l'esecuzione delle istruzioni FADD, FDIV e FMUL. Questi dati possono anche non essere corretti, ovviamente.

[paolo.oliva2]

Originariamente inviato da el-mejo

Bhe riguardo ai ssd questi si fermano a 70000 iops in lettura e 55000 in scrittura, quando dovrebbero arrivare a 100000 in entrambi i valori su interfaccia sata 3. Chiaramente se l'ssd è all'altezza.
Inoltre in molti si sono lamentati dei driver Amd: personalmente ho riscontrato problemi con il driver Amd per Win 10, che per qualche oscura ragione fa freezare Crystaldiskmark sui 4k QD. Fortunatamente Win 10 ha un driver ahci generico all'altezza, senza quell'osceno overhead cpu che aveva su windows 7. E sempra non esistano ancora quelli Raid ufficiali.

Riguardo network cambia niente, mentre potrebbe migliorare il supporto all'usb 3: attualmente si usa un chip integrato interfacciato su pcie 2.0 1x, con quindi 500mb/s di banda: con un singola periferica usb3 si è già saturato il bus...

Ovviamente parlando di sb950.

Precisando, io non è che dico che non esistano differenze, però dico che ci deve essere una coerenza per quanto riguarda i giudizi.
Se si guarda il lato prestazionale massimo, nessuno può dire che Intel non sia più prestazionale, ma la cosa non equivale a dire con la stessa spesa. Quello che voglio dire, è che indubbiamente un 6700K va di più di un 8370, però con i 200€ in più di procio, a parità di spesa magari si avrebbe il sistema 6700K con un SATA 3 normale ed un sistema con l'8370 con un SD, dove il chip-set SB950 comunque offrirebbe prestazioni superiori.

Poi volevo aggiungere, se da una parte si considera che un 2 core soddisfa il 90% delle pretese della massa, non mi sembra sullo stesso metro considerare che la maggior parte degli utilizzatori abbia più di una periferica USB 3.0 (io non ne ho manco 1), come sistemi SD o CF da favola o qualsivoglia.

Non è solamente AMD ad avere problemi con Windows 10. Ho un i7 5500U (Lenovo) con chip-set Intel Broadwell-U rev 09 e SB Intel Broadwell-U PCH L-P rev 03, aggiornato da windows 8.1 a Windows 10, ho problemi sia con la rete (mi riporta che mancano dei pacchetti ed invece ci sono tutti) e la cosa rognosa, inspiegabile, è che ho 3 penne USB, e se faccio operazioni lettura/scrittura su una penna, disattivandola a fine operazioni, dopo un certo tempo (1h come 5h) il sistema si resetta . Ci ho messo 1 mese per capire... all'inizio pensavo al caldo (solo torrent attivo e CPU a 65° addirittura in turbo fisso a 3GHz), ma scaricando con torrent e avendo la rete che non mi va, l'unico modo per passare i dati è con le penne. Caso vuole che per 1 settimana non ho trasferito i dati con le penne e nessun riavvio... poi le ho usate e dopo i problemi, anche se disattivate e sembra tutto ok, passa del tempo e mi ritrovo il sistema che è ripartito.

[bjt2]

Originariamente inviato da tuttodigitale

Spiegazione semplice e chiara.

Vedo che hai trovato il tempo di postare.....
A dopo

EDIT
partita finita
Vedo che la divisione ha sempre un costo di 19 cicli. Ho la sensazione, che la riduzione del costo, sia ottenuto mediante manipolazione funzionali. Ovvero piuttosto che una sola ALU completa, si sia optato ad un frazionamento del compito su più ALU, In sostanza l'ALU non ha stadi grossi, ma fa meno cose. Il risultato sarebbe si una riduzione degli stadi complessivi, ma senza compromettere il FO4.

bjt2 sei a conoscenza delle funzioni delle diverse ALU?

Ho fatto confronti, alla buona, e mi pare che non ci siano sostanziali differenze(ad una prima occhiata mi sono apparsi identici), tra il costo di manipolazione dei dati nei registri della CPU tra ZEN e Bulldozer e ciò vale anche per l'esecuzione delle istruzioni FADD, FDIV e FMUL. Questi dati possono anche non essere corretti, ovviamente.

Per quanto riguarda la divisione, l'algoritmo più semplice è iterativo e con iterazioni fisse dove è calcolato 1 bit alla volta. L'algoritmo è lo stesso che si impara alle elementari dove però si ricava una cifra alla volta, ovviamente in binario si ricava 1 bit alla volta... Una prima ottimizzazione è non fare iterazioni fisse ma uscire prima se ci sono meno bit da calcolare. Un'altra ottimizzazione è calcolare più di un bit per ciclo. Se la latenza è 19 cicli, allora probabilmente l'unità di Zen è da 2 bit/ciclo (immagino che valga per le divisioni a 32 bit). Mi pare che INTEL sia arrivato anche a 4 bit per ciclo...

Sulle latenze delle FADD non c'è molto da fare... L'addizione è semplicissima e un ciclo basta, non c'è molto da migliorare, ma il problema con i numeri floating point è che ci sono varie operazioni da fare prima e dopo per cui una operazione FP impiega almeno 3 o 4 cicli...

Penso che anche per il moltiplicatore si sia aggiunto altro hardware e si è ridotto i cicli, calcolando più bit per stadio... Se non mi sbaglio la moltiplicazione è più semplice: addizioni e shift che non occupano spazi, perchè sono un semplice spostamento di bit,... Resta solo da vedere quanti bit calcoli in un ciclo di clock... Per passare da 6 a 4 hanno aumentato almeno di una volta e mezzo i bit calcolati, e quindi almeno di una volta e mezzo gli addizionatori in cascata e quindi il FO4... Anzi possiamo calcolare il numero di addizioni per ciclo: se 4 cicli è la 64 bit allora sono almeno 16 bit per ciclo, ecc... Anche qui l'algoritmo è lo stesso che si studia alle elementari, ovviamente con cifre binarie...

[tuttodigitale]

@bjt2
Per una volta e mezzo, intendi + 50% o +150%?

[Mister D]

Originariamente inviato da gridracedriver

grazie

ma FO4 di BD non era già alto nonostante avesse pipeline lunghe e propensione ad alti clock e quindi stadi meno complessi?

quindi che senso avrebbe diminuire la pipe se però come effetto hai che ti aumenta ulteriormente FO4? non sarebbe controproducente?

FO4 è un numero che indica fisicamente che cosa? 10 o 20, per esempio, ma cosa cosa, nanosecondi? tuttodigitale mi aveva spiegato che è il tempo quindi ritardo che impiega il segnale ad attraversare lo stadio, se non ricordo male

Ciao,
no il FO4 (ritardo normalizzato di una pipeline) è inversamente proporzionale alla lunghezza delle stessa pipeline.
Per es il Pentium IV aveva FO4 di 13 e un sacco di stadi (pipeline molto lunga) perché il progetto aspirava a frequenze elevatissime e impossibili.
BD ha FO4 di 19 mentre i vecchi phenom II sopra i 22 se la memoria non mi inganna.
Quindi:
FO4 elevato -> pipe corte -> frequenza massima poco elevata
FO4 basso -> pipe lunghe -> frequenza massima elevata.

Chiaro che poi c'entrano le latenze che sono collegate e ancora di più il silicio. Trovo giusto che abbiano pensato di alzare un po' il FO4 perché passare dal soi al bulk perdi in leakage e quindi in frequenza massima. Se poi si pensa che ultimamente tutti i pp sono più orientati al mobile o cmq ai bassi consumi e che il finfet da appunto una mano in questo piuttosto che in frequenze alte, per me sarebbe ottimo Zen con un FO4 intermedio, a metà tra BD e i vecchi phenomII, in modo da ottimizzare l'efficienza su frequenze più basse di quelle che avrebbero dovuto avere BD e le varie evoluzioni (ho scritto volutamente averebbero dovuto avere e non quelle che hanno avuto).

[bjt2]

Originariamente inviato da tuttodigitale

@bjt2
Per una volta e mezzo, intendi + 50% o +150%?

+50%

Se per calcolare 32 bit di prodotto adotto stadi che calcolano 8 bit, ci vorranno 4 cicli, se ne adotto stadi da 12 bit (+50%) ce ne vorranno circa il 50% in meno, in questo caso 3. Più un ciclo extra per un po' di margine.

Poichè abbiamo 6 e 4 cicli per BD e 4 e 3 cicli per Zen, possiamo ipotizzare che si è passati da 13 a 22 bit per ciclo, in questo caso il 70% in più. Se non ci volesse il ciclo "morto" (non sono così esperto di pipeline, quindi non lo so per certo... ) allora saremmo a 11 vs 16, circa il 50% in più...

[bjt2]

Originariamente inviato da gridracedriver

grazie

ma FO4 di BD non era già alto nonostante avesse pipeline lunghe e propensione ad alti clock e quindi stadi meno complessi?

quindi che senso avrebbe diminuire la pipe se però come effetto hai che ti aumenta ulteriormente FO4? non sarebbe controproducente?

FO4 è un numero che indica fisicamente che cosa? 10 o 20, per esempio, ma cosa cosa, nanosecondi? tuttodigitale mi aveva spiegato che è il tempo quindi ritardo che impiega il segnale ad attraversare lo stadio, se non ricordo male

In realtà il FO4 indica la complessità di uno stadio di pipeline. FO4 significa Fan Out 4, ossia il ritardo, normalizzato ad un numero di stadi con fan out 4, ossia ad esempio una porta AND, l'uscita di un addizionatore, ecc, caricato con 4 porte NOT. Quindi FO4 12 significa che lo stadio di pipeline ha un ritardo pari a una cascata di 12 porte logiche che ognuna a loro volta alimentano 4 altre porte logiche.

Quindi è un indice di complessità del circuito... Ad esempio un moltiplicatore ha FO4 proporzionale al numero di bit per ciclo che calcola. Se in uno stadio di pipeline voglio avere un moltiplicatore che calcola x bit per ciclo, avrò un ritardo dato dal FO4 del moltiplicatore, più quello della circuiteria che fa il loop e shift per calcolare in 32/x e 64/x passi il prodotto a 32 o 64 bit...
Si devono progettare gli stadi in modo da avere lo stesso FO4 massimo, perchè è quello che limiterà il clock. Se ci sono stadi con FO4 diversi, quelli con un FO4 più basso sono stati implementati con un FO4 inutilmente basso (e quindi magari ad esempio un moltiplicatore più lento) perchè da limitatore al clock farà un altro stadio con FO4 più alto.

Il fatto che il moltiplicatore ha diminuito la latenza, significa che hanno potuto aumentare x e quindi il FO4 perchè hanno aumentato il FO4 di tutti gli altri stadi e quindi anche gli altri stadi sono diventati più complessi.

Il fallimento dei design ad alto clock, oltre al limite del processo, è anche colpa di questo sistema: se io devo fare un design ad alto clock, devo ridurre il FO4, quindi ad esempio un moltiplicatore lo farò di x/2 bit anzichè x bit e ci metterò il doppio del tempo. Ma il FO4 non si dimezza perchè ho ancora più o meno la stessa circuiteria che mi deve fare il loop e shift... Mettici che dimezzando il FO4 non raddoppio il clock per i limiti e non linearità del processo ed ecco che non conviene fare processori con clock alto... Finchè le addizioni le riesci a fare in un solo ciclo, ti puoi spingere a scendere il FO4, ma oltre non conviene... Non conviene neanche fare il FO4 troppo alto, perchè magari riesci a fare le moltiplicazioni in 1-2 cicli, ma le addizioni meno di un ciclo non ci puoi mettere e per fare le MUL in 1-2 cicli dimezzi il clock... Ma le ADD sono molto più frequenti delle MUL, quindi si cerca un compromesso... Pochi cicli per MUL e DIV ma non troppo oltre con il FO4... Questo ovviamente trascurando il costo: fare pipeline corte costa anche meno transistors e quindi meno area... Analogamente per fare MUL da 1-2 cicli, oltre a non avere un clock alto, avrai anche alta area, alto leakage e alto costo... Quindi è tutto un compromesso a seconda di quello che vuoi fare...

[digieffe]

Visto il basso TDP (95w) di Zen X8 (è probabile che il clock di base si fermi a 3.0ghz) e tenendo conto che l'ipc di zen dovrebbe essere (pessimisticamente) il 90% di broadwell ne conseguirebbe che avrebbe le stesse prestazioni dell' Intel Core i7-6850K http://wccftech.com/intel-broadwell-...800k-detailed/.

dato che l' Intel Core i7-6850K sarà prezzato a ~550$ e Intel Core i7-6800K a ~390$ mi sembra improbabile che sarà prezzato a meno di quest'ultimo (~400$) ...

[tuttodigitale]

@ bjt2
gli stadi che eseguono una MUL sarebbero scarsamente ottimizzati, visto che si passerebbe, valori indicativi, da un FO4 16 (2 bit/ciclo)- FO4 24 (3bit ciclo)-FO4 32 (4bit/ciclo).
A livello software, lo saprai meglio di me, ci sono algoritmi molto più avanzati, rispetto a quello elementare, e non c'è nessuna ragione per pensare che la soluzione sia utilizzare l'algoritmo X implementato in HW, ripetuto 1-2-3-4 volte in base alla lunghezza dello stadio.
Secondo me, rifanno completamente il moltiplicatore...

Sulle DIV, appunto, se utilizzano stadi molto più lunghi (50%), perchè la divisione intera richiederebbe 19 colpi di clock esattamente quanto bulldozer?

Sulle istruzioni floating point (FDIV, FADD e FMUL) idem. Anzi la FMUL che condivide parte degli algoritmi della MUL semplice, dovrebbe subire una riduzione di cicli. Eppure non è così.

Io sono convinto che il FO4 dipenda non solo da quanti bit macini per ciclo e dall'algoritmo usato, ma anche dalle funzioni della singola ALU.

Nel senso ho una pipeline che esegue sia moltiplicazione che divisioni. E' chiaro che lo stadio di questa pipeline sarà enormente più complesso di una che esegue un solo tipo di operazioni. Tenendo a mente che per attivare una funzionalità o l'altra è necessario fare ricorso ad una rete combinatoria, che introduce latenza, da quel poco che so di elettronica, direi che la partizione delle funzionalità su diverse pipeline, è un primo fattore che può ridurre il numero di stadi senza compromettere il FO4. Tanto più che in questo caso si parla di una riduzione della latenza solo per l'istruzione MUL.

Questo significherebbe anche che le 2 unità FMAC sono in grado di eseguire le FADD, vista l'identica latenza tra le unità bulldozer e ZEN.

[bjt2]

Originariamente inviato da tuttodigitale

@ bjt2
gli stadi che eseguono una MUL sarebbero scarsamente ottimizzati, visto che si passerebbe, valori indicativi, da un FO4 16 (2 bit/ciclo)- FO4 24 (3bit ciclo)-FO4 32 (4bit/ciclo).

Ho parlato di implementazione triviale della MUL, ovviamente è possibile, con l'adeguato hardware e consumo di area, fare in parallelo gli n bit e non in cascata e poi sommarli in parallelo, avendo così un ritardo di solo 2 stadi, con il secondo un ritardo maggiore perchè è un adder di n addendi, che può essere fatto in cascata 2 a 2, 3 a 3, ecc... Le soluzioni sono molteplici e mi pento di non aver fatto il piano di studi personalizzato all'università per includere l'esame "architettura dei sistemi integrati" dove si studiano a fondo tutte queste cose...

[bjt2]

Originariamente inviato da gridracedriver

si intendevo dire che l'FO4 di BD è troppo alto rispetto alla lunghezza delle sue pipe ed il suo clock infatti doveva essere più elevato di quello che poi è stato
19 non mi sembra poi chissà che risultato



grazie ancora, cercherò di capire al meglio quanto hai scritto
in sostanza un FO4 elevato non è per forza negativo se ad ogni ciclo mi permette di elaborare molti più bit rispetto ad uno basso
è tutto un trovare un giusto compromesso, ma dopo tutti questi anni ancora non sono arrivati a trovare l'equilibrio adatto? ok che dipende dal silicio, ma bene o male si è capito da anni che la corsa ai ghz è finita.

domanda 1: come mai parlate sempre di tutto ma mai delle SUB?

domanda 2: per stadi di una pipeline potete fare esempi pratici? cioè una pipe da 10 o 20 stadi che differenze può avere negli stadi stessi? ci sono stadi "fissi" e/o "variabili" e/o "secondari"? creano stadi nuovi? uno stadio in se in cosa consiste?... ecc?

scusate la nabbaggine

1) Sub e add cambia solo il segno di uno degli operandi, quindi è semplicissimo
2) E' molto complicato da spiegare in un post... Operazioni complicate possono essere divise in stadi e poi si può fare uno stadio più corto... Per le operazioni aritmetiche è più facile perchè sono operazioni ripetitive quindi è facile fare un solo passo e poi fare dei cicli (come le MUL) come implementazione base o replicare tutto come implementazione più veloce, ma per operazioni complicate come la decodifica delle istruzioni x86 ogni passo è diverso, quindi semplicemente per diminuire il FO4 e aumentare il clock, si spezza ad esempio a metà uno stadio e vi si mettono dei registri che tengono i risultati intermedi, comandati dal clock... Questo permette di aumentare il clock...

[bjt2]

Originariamente inviato da gridracedriver

sul SUB ci ho pensato appena l'ho scritto

sei stato chiarissimo, forse la mia domanda meno

ma ad esempio (porto questo esempio perché è il primo che mi è saltato in mente e che si trova facile):



l'unica differenza che vede "il mio occhio" è che in Jaguar (28nm) rispetto a Bocat (40nm) lo stadio "iDec" è stato aggiunto.

quindi quello che volevo dire è che ci sono degli "stadi" considerati "standard" "default" da cui partire per creare la pipe?
alcuni "conosciuti" ma di cui si può fare a meno?
alcuni che devono ancora essere "inventati" ?



comunque non temere queste pagine finiscono dritte tra i miei preferiti

Semplicemente il lavoro di decodifica che era diviso in 3 stadi, è stato riunito e ri-spezzato in 4 stadi... I nomi sono solo indicativi...

Probabilmente il limitatore del clock era lo stadio di decodifica e quindi hanno cercato di diminuire il FO4...

[bjt2]

Originariamente inviato da gridracedriver

quindi non c'è nulla di cui "inventarsi" a livello di pipe/stadi?

Il decoding può essere fatto in vari modi e AMD ha una tecnica innovativa (e penso brevettata, visto che INTEL non la usava) di memorizzare il predecoding in bit aggiuntivi della L1 istruzioni, come limiti di istruzione e informazioni di branch predicition, velocizzando il decoding e la previsione per le istruzioni già in cache e accorciando le pipeline. Per il resto le operazioni da fare in serie sono abbastanza definite... Resta solo da definire dove spezzare per formare gli stadi...

[tuttodigitale]

Originariamente inviato da gridracedriver

quindi non c'è nulla di cui "inventarsi" a livello di pipe/stadi?

Le pipeline aggiuntive possono servire anche per mantenere il FO4 inalterato. La fase di decodifica non viene certamente fatta allo stesso modo. Anzi in jaguar neppure il set di istruzioni è il medesimo.

Un ultimo particolare, in Jaguar non c'è una vera e propria fase di pre-decodifica, tipica dei grandi core AMD e Intel, nella quale vengono predeterminate le dimensioni dell'istruzione e salvate nella cache. Cioè le innovazioni di Jaguar sono da intendersi come quelle atte a risparmiare energia. Può capitare che queste vengono trasportate sui modelli di punta (vedi algoritmo di branch prediction e HDL di Jaguar in Excavator o il clamoroso caso Pentium M->cpu high end), ma non è certamente la prassi.

[Ren]

Originariamente inviato da gridracedriver

c'è la possibilità che in Zen siano riusciti ad accorciare la pipe lasciando inalterato FO4?
ciò vorrebbe dire avere quasi certamente le stesse frequenze di funzionamento di excavator considerando anche il fatto che si passa ad un processo più avanzato (essendo che FO4 è legato anche al livello/qualità del processo)?

Tutto è possibile, perché questi aspetti della pipeline non sono quasi mai pubblici. Ovviamente disegnare una pipeline ad alta frequenza con "meno stadi" non è semplice, inoltre presuppone un layout su silicio impeccabile.
Il vecchio K10(45nm) con soli 12stadi dava una pista al nehalem che ne aveva 17...

Apple ad esempio è passata da 16stadi a 9 (misspredict) aumentando di molto il clock (+40-50% ipad) anche se aiutata dal finfet. Tanto per cambiare hanno ridotto anche la dimensione del core (senza cache), che rimane più grande degli A57-72, ma lontano da skylake (x86 non aiuta).

Ancora oggi non mi spiego del tutto come hanno compiuto un miracolo simile...

ps. gridrace hai PM

[paolo.oliva2]

Vorrei un chiarimento, se possibile.
Per chi segue BD da Zambesi, si ricorderà che all'inizio Excavator era stato annunciato come un raddoppio di parti logiche di Steamroller. A posteriori, sembra facile intuire che l'Exavator di cui si parlava fosse in realtà Zen e che invece l'Excavator reale (probabilmente per i limiti di disponibilità silicio 28nm Bulk) fosse in realtà un perfezionamento di Steamroller con il passaggio Kaveri-Carrizo.

Io cerco un attimo di capirci, anche se a priori CMT e SMT sono praticamente opposti. Però... se parliamo di pipeline, mi sembra di capire che Zen sia più simile a BD di quanto lo sia Intel/SMT. Anche commercialmente, AMD mi sembra propensa a commercializzare Zen con un numero di core/TH superiore a Intel (Zen dovrebbe essere minimo X4/8TH, l'offerta Intel minima è X2/4TH).

Quello che faccio fatica a collegare, è che se da una parte AMD diciamo potrebbe raggiungere il 90% dell'IPC di Intel (copio quanto postato da altri Digieffe), non comprendo perchè AMD commercializzerebbe un die la cui offerta base avrebbe un numero di core doppio dell'equivalente Intel.
Sintetizzando, se Intel commercializza un X2+2 vs AMD X4, una volta che AMD aumenta l'IPC e inserisce l'SMT, commercialmente non sarebbe più valido offrire gli stessi numeri di core per contenere il prezzo e piazzarlo sul mercato al prezzo più competitivo possibile?

@Digieffe
Posso anche concordare con te sul discorso che Zen X8 abbia un prezzo a cavallo tra il 6850K e 6800 (anche se fare una correlazione di numero core senza sapere l'effettiva potenza ed ancor più la grandezza die è azzardato), però bisogna vedere l'offerta Zen per intero.

Ammesso che Zen venga offerto anche come X4/X6, AMD potrebbe avere un prezzo molto aggressivo perchè potrebbe sfruttare il fatto che un utente Intel dal 6700K agli i7 >X4 cambia il socket e di qui l'obbligo di cambiare mobo. Poi non è detto che Zen X8 non sia APU (con ovvie implicazioni HSA/Huma).

[digieffe]

Originariamente inviato da paolo.oliva2

Vorrei un chiarimento, se possibile.
Per chi segue BD da Zambesi, si ricorderà che all'inizio Excavator era stato annunciato come un raddoppio di parti logiche di Steamroller. A posteriori, sembra facile intuire che l'Exavator di cui si parlava fosse in realtà Zen e che invece l'Excavator reale (probabilmente per i limiti di disponibilità silicio 28nm Bulk) fosse in realtà un perfezionamento di Steamroller con il passaggio Kaveri-Carrizo.

Io cerco un attimo di capirci, anche se a priori CMT e SMT sono praticamente opposti. Però... se parliamo di pipeline, mi sembra di capire che Zen sia più simile a BD di quanto lo sia Intel/SMT. Anche commercialmente, AMD mi sembra propensa a commercializzare Zen con un numero di core/TH superiore a Intel (Zen dovrebbe essere minimo X4/8TH, l'offerta Intel minima è X2/4TH).

Quello che faccio fatica a collegare, è che se da una parte AMD diciamo potrebbe raggiungere il 90% dell'IPC di Intel (copio quanto postato da altri Digieffe), non comprendo perchè AMD commercializzerebbe un die la cui offerta base avrebbe un numero di core doppio dell'equivalente Intel.
Sintetizzando, se Intel commercializza un X2+2 vs AMD X4, una volta che AMD aumenta l'IPC e inserisce l'SMT, commercialmente non sarebbe più valido offrire gli stessi numeri di core per contenere il prezzo e piazzarlo sul mercato al prezzo più competitivo possibile?

@Digieffe
Posso anche concordare con te sul discorso che Zen X8 abbia un prezzo a cavallo tra il 6850K e 6800 (anche se fare una correlazione di numero core senza sapere l'effettiva potenza ed ancor più la grandezza die è azzardato), però bisogna vedere l'offerta Zen per intero.

Ammesso che Zen venga offerto anche come X4/X6, AMD potrebbe avere un prezzo molto aggressivo perchè potrebbe sfruttare il fatto che un utente Intel dal 6700K agli i7 >X4 cambia il socket e di qui l'obbligo di cambiare mobo. Poi non è detto che Zen X8 non sia APU (con ovvie implicazioni HSA/Huma).

ipotizzo che, tra frequenza ed ipc, Zen X8 non andrà meno dell X6 di punta intel, di conseguenza Zen X6 andrà oltre il 4+4 intel, resta da capire Zen X4 come si posizionerà.

tenedo conto che Amd deve recuperare mercato, ipotizzo a parità di prestazioni prezzi inferiori, ma non tanto da andare sotto il modello con meno core.

quindi se il modello di pari prestazioni (6850k) Intel lo vende a 500+ $ Amd vendererà Zen x8 a meno, ma non meno del 6700k in quanto ci sarà Zen x6 (già più potente di quest'ultimo) da vendere a prezzo leggermente inferiore.

[tuttodigitale]

Originariamente inviato da gridracedriver

c'è la possibilità che in Zen siano riusciti ad accorciare la pipe lasciando inalterato FO4?
ciò vorrebbe dire avere quasi certamente le stesse frequenze di funzionamento di excavator considerando anche il fatto che si passa ad un processo più avanzato (essendo che FO4 è legato anche al livello/qualità del processo)?

Il fo4 di un architettura non dipende dal silicio. Non a caso ti avevo detto che è una misura della latenza di uno stadio NORMALIZZATA.
Nella migliore delle ipotesi, sul silicio, anche un eventuale aumento di fo4 non impedirà un incremento di clock..

Le pipeline della patch, lato integer si sono accorciate di 1-2 stadi. Questo è un dato di fatto. Sul fo4 è difficile sbilanciarsi: se le latenze (le patch su zen dicono questo ad oggi) sulla FPU rimangono alte, identiche a quelle di BD, possiamo esser certi che il fo4 è invariato.

Per il momento, direi che hanno mantenuto il fo4 basso (alto clock) e accorciato le pipeline per mezzo di modifiche funzionali alle ALU (mia speculazione, ovviamente).