[Thread Ufficiale] Aspettando ZEN

[tuttodigitale]

Originariamente inviato da bjt2

mi pare di capire che per gli ASIC non si scende sotto un FO4 di 27 e tutti gli ARM sono ASIC... Perchè la logica e i flip flop che si usano per spezzare gli stadi sono troppo lenti e non si guadagna parecchio (vedrai una slide dove dice 1.6x di penalità su un FO4 12 rispetto alla migliore soluzione usata nelle CPU AMD). Quindi quella FPU NEON dovrebbe avere un FO4 di almeno 27...

Nel libro Closing the gap between Asic e Custom , viene fatto proprio il paragone tra le versioni full custom ARM (come xscale di Intel) e ASIC, e dice che l'overhead delle pipeline, con gli attuali strumenti di sviluppo passa da 3 delle soluzioni custom a 5FO4 per gli ASIC (contro i 20 di qualche anno fa)..
la penalità è assi più ridotta.
Nella fastispecie, il libro riporta un fo4 aumentato del 6% su un ARM11 (Questo fa pensare ad un'architettura con un fo4 di circa 30, la pipeline del ARM 11 ha 6 stadi).

Originariamente inviato da (un paragrafo del testo)

Latches are well-supported by synthesys tools, but are rarely used other than custom designs. Scripts can be used to convert timing critical portion of an ASIC to use latches of FF. high-speed FF are now available in some standard cell libraries and can be used in an automated design methodology to replace slower D-type FF on critical paths. Useful clock skew tailors the arrival time of the clock signal to different registres by adjusting buffers in the clock three and can be used in ASIC designer for pipeline balancing. With these methods, thepipeline delay overhead in ASICs can be reduced to as low as 5 FO4 delays. This enables more slack to be used for downsizing, voltage scaling, or increasing the clock frequency. From our pipeline model ASIC can close the gap for the microarchitecture and timging overhead factor to within 1,9x for custom

Mi pare strano che l'overhead, sia pari a fo4 27... i dati nella tabella sembrano essere veritieri ma vanno in direzione opposta a quanto c'è scritto nella slide successiva...la penalità è di circa con 2x (nel libro 1,9x), ma questo si riferisce esclusivamente al overhead...il CELL dal link è inserito nella lista dei ASICs eccellenti: figuriamo se CELL poteva girare ad oltre 3GHz sui 90nm con un fo4>27....infatti risulta avere un fo4 11:

Originariamente inviato da IBM

In the case of the Cell processor, having eliminated most of the barriers that cause inefficiency in high-frequency designs, the initial design objective was a cycle time no more than that of ten fan-out-of-fourinverters (10 FO4). This was later adjusted to 11 FO4
when it became clear that removing that last FO4 would incur a substantial area and power penalty.

il PPE, la cpu del CELL, ovviamente anche lui ha FO4 11, e "solo" 23 stadi. (per dire che la relazione di proporzionalità inversa pipeline lunghe uguale FO4 ridotto è alquanto sbagliato e viceversa)

Originariamente inviato da IBM

The PPE is a 64-bit Power-Architecture-compliant core optimized for design frequency and power efficiency. While the processor matches the 11 FO4 design frequency of the SPEs on a fully compliant Power processor, its pipeline depth is only 23 stages, significantly less than what one might expect for a design that reduces the amount of time per stage by nearly a factor of 2 compared with earlier designs

Sono perplesso.

Originariamente inviato da paolo.oliva2

Io comunque ho delle perplessità... perchè l'SMT è come se avesse l'I/O di 2 core sulla logica (potenziata) di 1 core, mentre il CMT ha parti logiche di 2 core (unite) con l'I/O di 2 core.

si alla buona la differenza fondamentale, è che i 2 thread sono gestiti da un unico scheduler (integer nel SMT), la cui complessità deve tener conto anche della gestione del thread aggiuntivo.

Originariamente inviato da paolo.oliva2

Posso capire che AMD, come sembra, abbia sviluppato contemporaneamente sia CMT e SMT, ma che abbia optato per il CMT perchè l'SMT obbligava a potenziare l'IPC del core e quindi avrebbe richiesto un finanziamento più ingente...

questo è un punto controverso...
se BD non avesse avuto il CMT avrebbe potuto avere un ipc più basso...

Originariamente inviato da paolo.oliva2

ma perchè non lavorare sul punto debole del CMT (la poteza ST) più che passare in toto su Zen?

è un punto interessante...
per aumentare le prestazioni nel ST devi aumentare la potenza del motore OoO (che è già decisamente migliore di quello visto in k10), e costa in termini di silicio. A quel punto non può non pensare di non mettere altre alu, per catturare i picchi..perchè non sfrutteresti effettivamente i vantaggi, ma ti prendi solo i difetti di una soluzione ad alta complessità.
Se hai molte alu (4+2 sono tante...), a quel punto, pensi che la maggior parte del tempo sarà attiva 1-2, ed ecco che affronti il problema di come utilizzarle meglio...e siamo arrivati al SMT...

ZEN e il SMT da questo punto di vista è la naturale evoluzione di Bulldozer e il CMT, anche se hanno messo tante di quelle belle cose, vedi cache, il checkpoint ecc...che in fin dei conti vanno tutti nella direzione di ridurre i punti deboli di BD..

Originariamente inviato da paolo.oliva2

Un +20% di IPC sarebbe stato possibile semplicemente facendo in modo, come Intel, che i TH prima "vanno" nei core liberi, se questi sono occupati si passa all'SMT. Il modulo perde il 20% per il CMT, ma il CMT esiste nel momento che tutti i 2 core del modulo sono in funzione, ma con 1 core a modulo attivo, tutte le risorse sono per quel core e quindi non dovrebbe entrare in causa del perdita del CMT.

questo è un problema di scheduler del sistema operativo

è una questione di punti di vista
PD guadagna il 72% con il CMT, ovvero c'è una penalizzazione rispetto a 2 core totalmente indipendenti.
Ma allo stesso tempo puoi pensare che il CMT faccia guadagnare il 16% di ipc...infatti i confronti delle versioni trinity e llano, vedono le prime primeggiare soprattutto nel ST..

il problema di BD (non so se vale lo stesso per PD), è anche il fatto che con CMT attivo o disattivato il consumo non cambia...questo fa pensare come sia stato concepito nell'offrire un gap ampio tra la frequenza base e quella nominale, tanto da nascondere, per via della frequenza molto ampia, anche il gap offerto dal CMT.

E questo non è uno scherzo...perchè con uno scheduler che carica 2core/2modulo, con soli 4 thread attivi la CPU è praticamente vicina al massimo carico


in sostanza, il turbo di un FX8350 doveva essere almeno pari a 4,5GHz su metà core....per avere una soluzione 2c/1m, convincente..in effetti il delta di frequenza base, e turbo (non raggiunta) era comunque del 17% per il fx8150...

Originariamente inviato da paolo.oliva2

indubbiamente giustificherebbe il perchè della scelta Zen, perchè un die Zen del 20% più piccolo di un die XV X16 con un ST più performante e uguale MT sarebbe certamente positiva...

-15% ma solo riferito al core+l1. (in effetti ho preso una accantonata quando ho detto che ZEN migliora le prestazioni nel MT per superficie, che spero si tramutino in watt, solo del 4%..)
se aggiungi l2 l3 e quant'altro i vantaggi sono molto più sottili ...

Originariamente inviato da paolo.oliva2

Ma AMD ha optato per Zen... sta cosa che il core Zen con SMT risulterebbe un -20% (occhio e croce) indubbiamente giustificherebbe il perchè della scelta Zen, perchè un die Zen del 20% più piccolo di un die XV X16 con un ST più performante e uguale MT sarebbe certamente positiva...

Paolo, la mia "analisi" era qualitativa.
I transistor che fanno parte dei core+l1 sono quelli che consumano il grosso dell'energia...non sapendo quanti transistor, ha un core ZEN ho rapportato le dimensioni dei core+l1 rispetto alla l3.
in sostanza quel -15% di superficie, si dovrebbe tradurre, se il throughput è pari al modulo XV, in un aumento dell'efficienza del 20% nel MT dovuta solo alla migliore architettura..
ovviamente questo ha parzialmente senso solo nel caso in cui il fo4 non fosse aumentato...(parziale perchè poi l'effettivo utilizzo dei transistor cambia da architettura ad architettura)

Originariamente inviato da paolo.oliva2

Una curiosità... a livello teorico, in un APU, l'implementazione HSA/Huma sarebbe più problematico con un'ottica SMT rispetto a CMT?

IMHO no, ma passo la parola all'esperto

[bjt2]

Originariamente inviato da tuttodigitale

Nel libro Closing the gap between Asic e Custom , viene fatto proprio il paragone tra le versioni full custom ARM (come xscale di Intel) e ASIC, e dice che l'overhead delle pipeline, con gli attuali strumenti di sviluppo passa da 3 delle soluzioni custom a 5FO4 per gli ASIC (contro i 20 di qualche anno fa)..
la penalità è assi più ridotta.
Nella fastispecie, il libro riporta un fo4 aumentato del 6% su un ARM11 (Questo fa pensare ad un'architettura con un fo4 di circa 30, la pipeline del ARM 11 ha 6 stadi).


Mi pare strano che l'overhead, sia pari a fo4 27... i dati nella tabella sembrano essere veritieri ma vanno in direzione opposta a quanto c'è scritto nella slide successiva...la penalità è di circa con 2x (nel libro 1,9x), ma questo si riferisce esclusivamente al overhead...il CELL dal link è inserito nella lista dei ASICs eccellenti: figuriamo se CELL poteva girare ad oltre 3GHz sui 90nm con un fo4>27....infatti risulta avere un fo4 11:

il PPE, la cpu del CELL, ovviamente anche lui ha FO4 11, e "solo" 23 stadi. (per dire che la relazione di proporzionalità inversa pipeline lunghe uguale FO4 ridotto è alquanto sbagliato e viceversa)



Sono perplesso.



si alla buona la differenza fondamentale, è che i 2 thread sono gestiti da un unico scheduler (integer nel SMT), la cui complessità deve tener conto anche della gestione del thread aggiuntivo.


questo è un punto controverso...
se BD non avesse avuto il CMT avrebbe potuto avere un ipc più basso...


è un punto interessante...
per aumentare le prestazioni nel ST devi aumentare la potenza del motore OoO (che è già decisamente migliore di quello visto in k10), e costa in termini di silicio. A quel punto non può non pensare di non mettere altre alu, per catturare i picchi..perchè non sfrutteresti effettivamente i vantaggi, ma ti prendi solo i difetti di una soluzione ad alta complessità.
Se hai molte alu (4+2 sono tante...), a quel punto, pensi che la maggior parte del tempo sarà attiva 1-2, ed ecco che affronti il problema di come utilizzarle meglio...e siamo arrivati al SMT...

ZEN e il SMT da questo punto di vista è la naturale evoluzione di Bulldozer e il CMT, anche se hanno messo tante di quelle belle cose, vedi cache, il checkpoint ecc...che in fin dei conti vanno tutti nella direzione di ridurre i punti deboli di BD..


questo è un problema di scheduler del sistema operativo

è una questione di punti di vista
PD guadagna il 72% con il CMT, ovvero c'è una penalizzazione rispetto a 2 core totalmente indipendenti.
Ma allo stesso tempo puoi pensare che il CMT faccia guadagnare il 16% di ipc...infatti i confronti delle versioni trinity e llano, vedono le prime primeggiare soprattutto nel ST..

il problema di BD (non so se vale lo stesso per PD), è anche il fatto che con CMT attivo o disattivato il consumo non cambia...questo fa pensare come sia stato concepito nell'offrire un gap ampio tra la frequenza base e quella nominale, tanto da nascondere, per via della frequenza molto ampia, anche il gap offerto dal CMT.

E questo non è uno scherzo...perchè con uno scheduler che carica 2core/2modulo, con soli 4 thread attivi la CPU è praticamente vicina al massimo carico


in sostanza, il turbo di un FX8350 doveva essere almeno pari a 4,5GHz su metà core....per avere una soluzione 2c/1m, convincente..in effetti il delta di frequenza base, e turbo (non raggiunta) era comunque del 17% per il fx8150...


-15% ma solo riferito al core+l1. (in effetti ho preso una accantonata quando ho detto che ZEN migliora le prestazioni nel MT per superficie, che spero si tramutino in watt, solo del 4%..)
se aggiungi l2 l3 e quant'altro i vantaggi sono molto più sottili ...

Paolo, la mia "analisi" era qualitativa.
I transistor che fanno parte dei core+l1 sono quelli che consumano il grosso dell'energia...non sapendo quanti transistor, ha un core ZEN ho rapportato le dimensioni dei core+l1 rispetto alla l3.
in sostanza quel -15% di superficie, si dovrebbe tradurre, se il throughput è pari al modulo XV, in un aumento dell'efficienza del 20% nel MT dovuta solo alla migliore architettura..
ovviamente questo ha parzialmente senso solo nel caso in cui il fo4 non fosse aumentato...(parziale perchè poi l'effettivo utilizzo dei transistor cambia da architettura ad architettura)


IMHO no, ma passo la parola all'esperto

27 FO4 non è la penalità. La penalità del registro è 10 per gli ASIC di base, 4.9 per gli ASIC ottimi e 2.5 per la migliore soluzione che usa AMD... Capirai che con una penalità di 5-10, scendere sotto 27, poi diventa una frazione importante del FO4... 27 non è un numero "fisso", mi pare di aver capito che non esistono sul mercato ASIC con FO4 minore di 27... Lo puoi fare, ma mano a mano si riduce il ritorno in frequenza, rispetto alla perdita di IPC dato dai molti stadi.

Se ti ricordi ho sempre detto che spezzare una pipeline non dimezza il FO4 perchè poi devi aggiungere il ritardo dei registri che usi per spezzare... Non sapevo quanto era... Ora si: da 2.5 a 10 FO4 a seconda della "tecnologia".
Il CELL è full custom, quindi usa i Flip Flop (FF) in configurazione 2.5 FO4...
Come AMD...

Per quanto riguarda le GPU... Le moderne GPU sono già SMT... Possono gestire migliaia di thread che vanno sulle miglialia di stream processors a blocchi di 16 (AMD) o 32 (NVIDIA)... D'altronde la latenza di ogni thread è così alta che senza SMT le GPU non avrebbero un gran throughput...Sono MASSIVAMENTE SMT...

[tuttodigitale]

@bjt2
che il cell fosse full custom, l'avevo immaginato, ma nel link postato lo danno per ASIC per tanto mi era venuto il dubbio che ci siano altre incongruenze sparse.

Fermo restando quello che dici è assolutamente vero, ma se BD mettiamo ha un FO4 17+3, nel caso di un ottimo asic avrebbe un 17+5, nel caso di un asic tipico 17+10 . La penalità quindi a livello di clock sarebbe 20/22, che probabilmente si tramuta in prestazioni per watt, a clock tranquilli, del 10-15% più basse. Come è saltato fuori quel fo4 27, non si sa...mi manca il passaggio logico, più tardi leggo con calma, magari c'è qualcosa che mi è sfuggito.

Per il momento resto dell'idea che la differenza tra un custom e un asic ottimo, è "solo" di 2.5 punti di fo4...

EDIT...
ecco l'inghippo
si riferisce al fo4 instruction...quello di uno custom è pari a 22 (nello specifico un'architettura da 34 stadi con fo4 8)
ll limite dovrebbe essere una cpu da 26 stadi e fo4 12. , per le asic ovviamente.

[paolo.oliva2]

Originariamente inviato da bjt2

Per quanto riguarda le GPU... Le moderne GPU sono già SMT... Possono gestire migliaia di thread che vanno sulle miglialia di stream processors a blocchi di 16 (AMD) o 32 (NVIDIA)... D'altronde la latenza di ogni thread è così alta che senza SMT le GPU non avrebbero un gran throughput...Sono MASSIVAMENTE SMT...

Quindi Zen X86 sarebbe un apripista giusto per quantificarne il TDP e per affinare il silicio, cosi da avere i parametri più precisi possibile e poter centellinare il TDP in modo certosino, unito poi all'affinamento architettura (Zen+).

Comunque è pure una bella mossa quella di produrre proci in esclusiva, tipo il discorso Zen APU lite per la PS4, perchè oltre a guadagnarci, AMD assimila esperienza che poi ricicla per sè... è come se una parte di progettazione/sviluppo/stesura sul silicio di Zen AMD a tutti gli effetti venga "sponsorizzata" da altri.
Quello che non comprendo ancora, è come possa poi essere il contratto... cioè se la PS4 neon utilizzerà un Zen X8 APU "lite", è ovvio che AMD non potrà produrla per sè, ma è anche ovvio che AMD comunque produrrà Zen APU... come possono poi coesistere nel mercato senza farsi competizione?
I rumor danno Zen X8 APU "lite" per PS4 a 2,2GHz... ma un possibile Zen APU X4 a 4GHz dovrebbe costare meno e rendere un sistema PC ad un prezzo concorrenziale rispetto ad una console che si aggirerebbe sui 400€.

Se mi ricordo bene, AMD avrebbe dichiarato che Zen+ (che altro poi non sarebbe che il passaggio da Zen X6 2016 a Zen APU 2017, se non continuerà pure con Zen X6) avrebbe una performances superiore del +10/15%, quindi presumibile che si traduca con un risparmio ulteriore di TDP alle stesse frequenze/potenze. Credo sia inutile grandi discorsi sui 95W/125W a cavallo dei 4GHz, perchè comunque un 10-15% di vantaggio TDP, da solo consentirebbe di soddisfare tutto il TDP necessario per la IGP che sul 14nm consentirebbe prestazioni superiori rispetto a quella montata su BR sul 28nm (se BR con 15W soddisfa X86 e IGP sul 28nm, figuriamoci una IGP con 10W/15W esclusivi sul 14nm)

[george_p]

Originariamente inviato da vegitto4

http://semiaccurate.com/forums/showp...postcount=3064

Originariamente inviato da paolo.oliva2

Quindi Zen X86 sarebbe un apripista giusto per quantificarne il TDP e per affinare il silicio, cosi da avere i parametri più precisi possibile e poter centellinare il TDP in modo certosino, unito poi all'affinamento architettura (Zen+).

Comunque è pure una bella mossa quella di produrre proci in esclusiva, tipo il discorso Zen APU lite per la PS4, perchè oltre a guadagnarci, AMD assimila esperienza che poi ricicla per sè... è come se una parte di progettazione/sviluppo/stesura sul silicio di Zen AMD a tutti gli effetti venga "sponsorizzata" da altri.
Quello che non comprendo ancora, è come possa poi essere il contratto... cioè se la PS4 neon utilizzerà un Zen X8 APU "lite", è ovvio che AMD non potrà produrla per sè, ma è anche ovvio che AMD comunque produrrà Zen APU... come possono poi coesistere nel mercato senza farsi competizione?
I rumor danno Zen X8 APU "lite" per PS4 a 2,2GHz... ma un possibile Zen APU X4 a 4GHz dovrebbe costare meno e rendere un sistema PC ad un prezzo concorrenziale rispetto ad una console che si aggirerebbe sui 400€.

Fottemberg lo ha scritto più volte nel corso dell'anno scorso che Zen (ma direi ormai i prodotti amd) è praticamente finanziato in questo modo. O più precisamente i costi di sviluppo e ricerca amd praticamente non ne ha.
Resta da capire quella misteriosa commessa di cui parlò più volte, ne ho perso le tracce.

Mi dai un link a zen apu lite in ps4? Questa mi sfugge

[paolo.oliva2]

OT.
Qualcuno in PVT mi potrebbe aiutarmi a capire? Quando ci sono i fulmini, 1-2 secondi prima io ho come un cortocircuito in casa, con tanto di rumore secco e lampo, nelle scatole di derivazione/interruttori, non in un posto specifico, ma a random per la casa. E' la massa a terra che non lavora bene e casa mia è diventata una cella simile al parafulmine? Fine OT

[paolo.oliva2]

Originariamente inviato da george_p

Fottemberg lo ha scritto più volte nel corso dell'anno scorso che Zen (ma direi ormai i prodotti amd) è praticamente finanziato in questo modo. O più precisamente i costi di sviluppo e ricerca amd praticamente non ne ha.
Resta da capire quella misteriosa commessa di cui parlò più volte, ne ho perso le tracce.

Mi dai un link a zen apu lite in ps4? Questa mi sfugge

L'avevo postata addietro, credo 1 mese fa almeno.. ci avevo discusso con Gridracedriver circa il TDP, in quanto le console è consono che non abbiano un procio esoso in TDP (95W massimo).
Io non ho una connessione veloce (WI-FI tramite SIM, miracolosamente a 400KB/s ma ping sopra il secondo e facilmente ingolfabile) che mi permetta di spulciare i miei post.
Comunque se cerchi PS4 NEON, dovrebbe saltare fuori questo Zen APU "LITE", basato su Polaris e clock 2,2GHz.

[george_p]

Originariamente inviato da paolo.oliva2

L'avevo postata addietro, credo 1 mese fa almeno.. ci avevo discusso con Gridracedriver circa il TDP, in quanto le console è consono che non abbiano un procio esoso in TDP (95W massimo).
Io non ho una connessione veloce (WI-FI tramite SIM, miracolosamente a 400KB/s ma ping sopra il secondo e facilmente ingolfabile) che mi permetta di spulciare i miei post.
Comunque se cerchi PS4 NEON, dovrebbe saltare fuori questo Zen APU "LITE", basato su Polaris e clock 2,2GHz.

Ok, trovata qui ma non hai postato il link alla notizia anche se credo di averla trovata se è in italiano e... non so ho vari dubbi. resta però l'indizio di una commessa grossa di cui parlò Fottemberg che avrebbe permesso ad amd di continuare sviluppo e ricerca pagati comodamente dal committente.
Poi se Zen è davvero molto potente a parità di consumi (e silicio permettendo anche) ci sta tutta la notizia di una apu zen su ps4... ma toccherà aspettare come al solito per vedere cosa è vero cosa no.

[bjt2]

Originariamente inviato da tuttodigitale

@bjt2
che il cell fosse full custom, l'avevo immaginato, ma nel link postato lo danno per ASIC per tanto mi era venuto il dubbio che ci siano altre incongruenze sparse.

Fermo restando quello che dici è assolutamente vero, ma se BD mettiamo ha un FO4 17+3, nel caso di un ottimo asic avrebbe un 17+5, nel caso di un asic tipico 17+10 . La penalità quindi a livello di clock sarebbe 20/22, che probabilmente si tramuta in prestazioni per watt, a clock tranquilli, del 10-15% più basse. Come è saltato fuori quel fo4 27, non si sa...mi manca il passaggio logico, più tardi leggo con calma, magari c'è qualcosa che mi è sfuggito.

Per il momento resto dell'idea che la differenza tra un custom e un asic ottimo, è "solo" di 2.5 punti di fo4...

EDIT...
ecco l'inghippo
si riferisce al fo4 instruction...quello di uno custom è pari a 22 (nello specifico un'architettura da 34 stadi con fo4 8)
ll limite dovrebbe essere una cpu da 26 stadi e fo4 12. , per le asic ovviamente.

L'ho letto sul tardi ieri sera, quindi qualcosa posso aver frainteso... Comunque mi pare logico che con una penalità di FO4 di 10 o 5 per ogni sdadio in più non conviene scendere sotto un certo FO4... Come ho scritto sopra il 27 non l'ho inteso come limite progettuale, ma come FO4 minimo di tutte le architetture ASIC in commercio... Ossia solo le architetture custom o semicustom (insomma ottimizzate) di INTEL, AMD (e forse APPLE) scendono sotto il 27...Il mio scopo era dare un limite minimo a quella macro NEON di esempio che gira a [email protected] sul nuovo 14nm FF LVT... Se il FO4 è almeno 27, come sembra, allora a 0.8V Zen andrà più di 2.41GHz e quindi si spera in clock ancora più alti, come ho scritto su twitter a Dresdenboy...

[bjt2]

Che poi la risposta sul FO4 della macro NEON me la devo dare da solo...
Sul 28nm HPP, lo stesso di XV, la macro NEON va al max a poco più di 1GHz...
Mentre XV va fino a 4.3GHz
Se la macro NEON va a 2.41GHz, a quanto arriverebbe XV? E a quanto Zen?

[george_p]

Originariamente inviato da bjt2

Che poi la risposta sul FO4 della macro NEON me la devo dare da solo...
Sul 28nm HPP, lo stesso di XV, la macro NEON va al max a poco più di 1GHz...
Mentre XV va fino a 4.3GHz
Se la macro NEON va a 2.41GHz, a quanto arriverebbe XV? E a quanto Zen?

E' realistico un confronto di questo tipo?
Intendo senza variabili di qualche tipo che ne determinino l'invalidità.

Immagino che questa macro vada a 2.41 GHz su un processo migliore del 28 nm attuale utilizzato da amd...

[tuttodigitale]

Originariamente inviato da george_p

Immagino che questa macro vada a 2.41 GHz su un processo migliore del 28 nm attuale utilizzato da amd...

vedi tu

[george_p]

Ok, comunque questa macro neon che architettura è? Non è all'altezza di Excavator come complessità ed elaborazione, giusto?
Quindi, ciò che voglio dire io è ok la possibilità di salire in frequenza ma con quanti transistor? Il numero dei transistor può essere un limite immagino e se si fino a che punto?
Quindi poi c'è da considerare anche il consumo che ne deriva per numero di transistor e per area occupata... comunque penso si possano fare delle previsioni di massima.
Parlo da assoluto ignorante.

[paolo.oliva2]

Originariamente inviato da tuttodigitale

vedi tu

Dati alla mano UFFICIALI certificano che il 14nm avrebbe frequenze maggiori del 28nm con un TDP dimezzato a parità di transistor.
In poche parole, un BR 28nm 4GHz def e 4,3GHz turbo 65W (il TDP non lo conosco esattamente), sul 14nm avrebbe un TDP /2 = <35W e nel contempo >4GHz def e > di 4,3GHz turbo.

Il dubbio di george_p è generalizzato un po' in tutti e credo di capirlo, è che le comparazioni sul 14nm si fermano a 4GHz... e il 28nm raddoppia il TDP per frequenze > di 4GHz, ma il 14nm non si conosce il comportamento, potrebbe come quadruplicare il TDP come invece scalare meglio del 28nm...

Se esistesse un esempio di quella macro oltre a 2,4GHz e 4GHz, quale potrebbe essere a 4,5GHz o 5GHz, si taglierebbe la testa al toro.

@George_p
Resta comunque il fatto che per i 4GHz def di Zen i dubbi oramai non ci dovrebbero essere.
1°) GF a suo tempo aveva riferito UFFICIALMENTE che il 14nm aveva rispettato le aspettative, cioè che il primo BETA test aveva raggiunto il range di frequenza di 3-4 GHz. Che poi l'estrapolazione possa far pensare 4GHz 95W per Zen X8 o 140W, è soggettiva, però la frequenza di 4GHz c'è.
2°) I dati sulla macro sono ufficiali e per Vcore/TDP portano pur sempre a Zen con 4GHz def, mi sembra nei 95W più che 125W, ma pur sempre di manica larga per 140W massimi del socket.
3°) Le comparazioni ufficiali 14nm vs 28nm portano ancora una ulteriore conferma che dove BR arriva sul 28nm (TDP/frequenza), il 14nm permetterebbe una frequenza maggiore unita ad un TDP inferiore... = XV 28nm 4GHz def /4,3GHz turbo sul 14nm >4GHz def e >4,3GHz turbo, unito ad un TDP che sul 28nm permetterebbe X8, mentre sul 14nm un raddoppio e quindi X16.
4°) Quella macro che rispecchia le caratteristiche del 14nm, ha comunque un FO4 che permette una frequenza minore allo stesso TDP di quanto potrebbe risultare utilizzando l'FO4 XV/ZEN, quindi Vcore e W sono per quell'FO4 e con l'FO4 di XV/Zen si avrebbe più frequenza a parità di TDP o la stessa frequenza a TDP inferiore.

Come scritto sopra, quello che taglierebbe la testa al toro sarebbe un dato ufficiale GF/Samsung dove si riporta (ad esempio) il comportamento di quella macro (Vcore e TDP) oltre che a 2,4GHz e 4GHz, anche a frequenze superiori, tipo 4,5GHz e 5GHz.

[AceGranger]

Originariamente inviato da paolo.oliva2

Io ho riportato l'articolo tale e quale l'hanno postato 3 testate (in anticipo con i tempi). Se in 5 anni ha commercializzato 3 release, per me sono quasi 2 anni a release e mi sembra che 1 anno e forse meno per la prox quando ancora Broadwell non si è ancora attestato...

dalla piattaforma 1366, poi 2011 e infine 2011-3, le CPU Server usono mediamente durate 1,5 anni a Generazione e piu o meno 3 anni il Socket;

Broadwell è uscito IN RITARDO, perchè hanno avuto i famosi problemi con i 14nm, quindi Haswell è durato piu del previsto e Broadwell durera meno del solito e 1 anno come le generazioni CPU Consumer; Skaylake-E uscira come previsto perchè serve per il mercato Server e devono aggiornare la piattaforma Socket.

Originariamente inviato da paolo.oliva2

Se me lo dici ora se ha già in programma di fare ste cose... perchè non vorrei che se le facesse dopo Zen, troverei lo stesso commento che AMD non c'entra nulla e l'aveva previsto da tempo.

tutto fino ad ora è sempre stato in funzione di AMD, ma visto che fino ad ora AMD è stata inesistente Intel ha fatto sempre i suoi comodi, se AMD tornera competitiva torneranno competitivi i prezzi.

[paolo.oliva2]

Originariamente inviato da AceGranger

dalla piattaforma 1366 e poi 2011, le CP usono mediamente durate 1,5 anni;

Ma è questo che dico... Se il dopo Broadwell lo annuncia tra 12 mesi e non 18 mesi, è prima o normale?

Broadwell è uscito IN RITARDO, perchè hanno avuto i famosi problemi con i 14nm, quindi Haswell è durato piu del previsto e Broadwell durera meno del solito e 1 anno come le generazioni CPU Consumer; Skaylake-E uscira come previsto perchè serve per il mercato Server.

No, aspetta, se Broadwell ci ha messo 24 mesi non è che si anticipa il seguente a 12 mesi, il seguente deve rispettare sempre i 18 mesi perchè il prezzo del procio è calcolato in base al tempo che sta sul mercato (n° pezzi venduti in X tempo con il plus a procio di tutta la spesa progettazione e silicio). Con Haswell ha guadagnato di più, ma in commercio non esiste prma ho guadagnato ora ci posso rimettere, e Broadwell non costa più di Haswell... quindi io ci vedo 2 cose... la prima è che normalmente Intel con il nuovo modello alza i prezzi, e non l'ha fatto a parte l'X10, la seconda è che accorcianto il tempo a 12 mesi da 18, Broadwell sarebbe dovuto risultare più costoso, e non lo è...
Il fatto che serve al mercato server, come hai evidenziato, qual'è il motivo? Se al momento l'alternativa è un Opteron X16 PD, ha forse paura Intel con il suo X24 Broadwell? Se SERVE, mi sembra per pararsi da un X32 Zen, e allora dove trovi sbagliato quando dico che Intel anticipa il post Broadwell per rinforzare la sua offerta di potenza?

tutto fin o ad ora è sempre stato in funzione di AMD, ma visto che fino ad ora AMD è stat inesistente Intel ha fatto sempre i suoi comodi, se AMD tornera competitiva torneranno competitivi i prezzi.

Questa è la cosa più normale del commercio, infatti si può criticare Intel per offerte/listini, ma non commercialmente. Allora concordi pure tu che i prezzi attuali sino alla potenza offerta da AMD, hanno una correlazione con il costo silicio (a parte gli i3 e almeno sino al 6600K), dopodichè si ha un'impennata di prezzi dove la superficie costa dal doppio a 4 volte di più? Commercialmente è giustificato dal fatto che quella potenza la può vendere solamente Intel, se la vuoi la paghi quanto richiesto da Intel. Ma per AMD, non capisco quale sia il metro di giudizio tra applicare un prezzo commerciale (e quindi con normali ricarichi) e un prezzo che risulterebbbe comunque enormemente gonfiato applicando un -20% sul listino Intel. Se un X8 può arrivare a costare 350€ (nel tuo post precedente avevi scritto "può dimezzare il prezzo degli X6", quindi 500€ il top degli X6, /2 = 250€, un X8 a 350€ mi sembra lecito), e sbaraccare il mondo, al contrario a 800€ sarebbe fagocitato da Intel e non otterrebbe nulla.
Poi è chiaro che sono punti di vista... ma finchè la possibilità di un X8 a 350€ risulta possibile perchè il costo lo permette con guadagno "normale", non penso che sia da escludere.

[tuttodigitale]

Secondo uno studio del 2014 la massima frequenza raggiungibile dal a9 (11 stadi) è di 3 GHz a 1,37V su fd-soi 28nm.
l'a9 sembra che abbia un fo4 piuttosto alto...(o sono i 28nm fd-soi a fare schifo, ci sarà un motivo se AMD non li ha usati )
con facilità dovrebbe superare i 3 GHz con i 14nm LPP....
anche se pare (Fonte: ARM) che nel 2010 c'era un'architettura con fo4 22... e nel 2009 un fo4 20.. vai ai scoprire di quali architetture si tratta...

zen ha un fo4 compreso tra 11-24 (non si è certo forzato, però il fatto che ci sia la possibilità di un fo4 <17 )
a dirlo è Yusuke Ohara. (articolo datato Dicembre 2015)
ZEN potrebbe consumare 60W a 3GHz, e 3,3GHz a 90W, per la natura low power del processo...e i 4GHz solo in turbo...troppo pessimista?
https://translate.googleusercontent....X1KUd7koB8O3Hw

[george_p]

John Bridgman di AMD afferma che Zen non è in ritardo sulla tabella di marcia:
clicca qui

[Ren]

Originariamente inviato da tuttodigitale

zen ha un fo4 compreso tra 11-24 (non si è certo forzato, però il fatto che ci sia la possibilità di un fo4 <17 )
a dirlo è Yusuke Ohara. (articolo datato Dicembre 2015)
ZEN potrebbe consumare 60W a 3GHz, e 3,3GHz a 90W, per la natura low power del processo...e i 4GHz (e oltre) solo in turbo...troppo pessimista?
https://translate.googleusercontent....X1KUd7koB8O3Hw

Non sappiamo se useranno le HDL.

Non sappiamo se avrà un F04 maggiore di BD.

Sappiamo che il silicio è sotto di almeno il 15% rispetto ad un 14nm intel.

Sappiamo che IBM per suoi core ad alta frequenza si è fatta sviluppare una versione HP, probabilmente Finfet.

[george_p]

Ma che senso ha dire che ha un FO4 compreso tra tot e tot... se lo sai lo dici se non lo sai o non puoi dirlo meglio il silenzio...