[Thread Ufficiale] Aspettando ZEN

[paolo.oliva2]

@Wolfhang

Non trovo il tuo post, ma il punto non è la frequenza ottenuta a quale TDP, ma è proprio un limite prestazionale del 14nm Intel. Il problema non è un 6700K a 90W o 140W, il problema è che 1,35V è il massimo Vcore applicabile al 14nm Intel, quindi è esclusivamente un limite di silicio, e a quel Vcore il 14nm Intel arriva sui 4,4GHz (con die piccoli, con più die più grandi richiede più Vcore a parità di frequenza), a meno che utilizzando raffreddamenti <0° (credo, non lo so).

Il 28nm Bulk GF, in accoppiata a XV, nei 65W arriva a una frequenza massima commerciale che è solamente di 100MHz inferiore a quella massima in OC ottenibile sul 14nm Intel, ma ovviamente anche il 28nm GF si può overcloccare, di certo con più margine rispetto ai +200MHz dal turbo di un 6700k al max 4,4GHz.

Per farti un paragone, il 9590 è venduto a 220W per 4,7GHz def e 5GHz turbo, ma seppur a quel TDP stratosferico, lo porti a 5,315GHz che di fatto rappresentano +600MHz def e +300MHz turbo.

A me, personalmente, non mi frega una tozza se Zen verrà venduto a 95W o 125W e, relativamente, a quale frequenza. Per me è molto più importante, sperando in un Zen sbloccato, a quale Vcore/frequenza/TDP può reggere il 14nm Samsung. Facendo un esempio... il 6700K non arriva a generare un TDP proibitivo per un sistema di raffreddamento casalingo, ma comunque non supera i 4,4GHz. Per me Zen potrebbe anche arrivare a 170W, ma se in RS/DU e con un Vcore "tranquillo" per il silicio, che cacchio me ne frega del TDP se poi questo vorrebbe dire 4,5GHz? (esempio).

La mia "paura", ora come ora, è il perchè di 95W per un X8+8... (dato ufficiale AMD), perchè io naso un prb di svettamento TDP oltre la frequenza def per 95W più di quanto potrebbe essere che in quei 95W AMD possa competere in potenza verso gli Intel a 140W. Diversamente, a parità di FO4, sulla carta il 14nm FinFet GF dovrebbe concedere frequenze superiori al 28nm Bulk sempre GF, quindi se non ci sarà un PP del 14nm peggiore rispetto al 28nm, 200-300MHz in più ci dovrebbero essere, per Zen 14nm (a parità FO4) rispetto a XV 28nm.

[cdimauro]

Originariamente inviato da george_p

Certo
Però sono un probabile complottista, visto che non dichiaro con sicurezza ma con un certo margine e beneficio del dubbio

Sofismi.

Originariamente inviato da paolo.oliva2

Che ci abbia preso?

http://www.kitguru.net/components/cp...s-leak-online/

KitGuru Says: If this leak is accurate, then it is clear that AMD has made some strides in terms of CPU power efficiency. We still don’t have an exact release date for Zen, but current rumours point towards a possible October release date, so hopefully we hear more in the coming months. Are any of you currently waiting to see what AMD brings to the table with Zen?

Parlano ancora di ES e commercializzazione per ottobre. Un ossimoro...

Originariamente inviato da Piedone1113

Antonio

Io ho visto benissimo i link, ma mi sembra che tu non abbia letto bene quello che ho scritto:

Se ricompili dai sorgenti, il software usato in quei test, con i compilatori moderni i risultati sarebbero ben diversi (perchè a scanso di equivoci, tutti i software ricompilati sotto linux per uso pro nei server mostravano un vantaggio per amd, stesso vantaggio che vide anche BigBlu).
Ma tutto questo è ininfluente sia per quello che fu (ormai appartiene alla storia) sia per quello che sarà zen.
Ci stiamo dilungando su questioni di nessun valore annoiando molti e gasando alcuni.

Per il resto non accuso nessuno e non credo che si voglia fare un processo su questo th, a nessuno (anzi nel vecchio th fu crocifissa GF)

Permettimi, Antonio: prima hai parlato al passato e ti sei anche riferito a quel periodo. Adesso parli di compilatori moderni. Le due cose non vanno molto d'accordo.

Originariamente inviato da bjt2

Devo dire che sono colpevole anche io, perchè è da eoni che non programmo più in assembler, visti i compilatori e le librerie ottimizzate... Mi riferivo al fatto che Cinebench sia compilato con il supporto a max 128 bit... Può darsi che mi sbaglio, ma nel caso che abbia ragione, sarebbe un ottimo bench...

Non vorrei che fosse compilato solo per le SSE. Avrebbe poco senso compilare usando le AVX, ma continuando a usare i registri soltanto a 128 bit: si perderebbe il maggior guadagno in termini prestazionali.

Beh, nel caso di Zen c'è poi il NB, il SB, il controller RAM più sofisticato e con frequenze più elevate... In ogni caso i conti dovrebbero tornare, forse aggiungendo qualcosa in più perchè quel SoC di cellulare, che ho supposto consumare 3W, con 8 core+GPU e accessori, sarà fatto con transistors RVT e HVT (almeno i 4 core little, se non anche la GPU, visto che va a 900MHz) e quindi a più basso leakage... Ma converrai che, per quanto complesso, un singolo core Zen non penso che equivalga, come consumo, a 4 core Big a 2.5GHz, 4 core little a 1.8GHz, una GPU da 122GFlops a 900MHz, più gli accessori (NB/SB ecc)... E infatti sul 28nm in 3W ci va un intero modulo XV attorno ai 2.5GHz... Quindi penso che si... 3W a 2.5GHz sia anche troppo per un core Zen... Ma non scordiamoci che Zen, per essere competitivo, deve arrivare almeno a 4GHz, per cui se andiamo con l'ipotesi della potenza con il cubo della frequenza, abbiamo 3*(4/2.5)^3=12W per core, 98W in totale... Quindi siamo al limite per i 95W per 8 core a 4GHz... Ma ricordiamoci che [email protected] è esagerato...

Anche nei SoC ARM c'è parecchia altra roba, come dicevo prima, e il tutto contenuto in appena 3W.

Comunque dal link di Paolo si parla di 2,8Ghz base a 3,2Ghz turbo, con 65W per il quad core e 95W per l'octa core.

Non siamo lontani dai 2,5GHz di cui parlavamo, ma quanto a consumi c'è un abisso. E personalmente trovo le informazioni abbastanza realistiche.

Il numero delle vie per cui aumenta quadraticamente la complessità è IMHO al livello del core RISC. Per questo è conveniente fare domini separati e non coda unica come INTEL. AMD ha INT/MEM e FP separati... Il Power 8 separa in Branch+condition code+int/fp+mem/int semplici... L'unica cosa che non mi piace è la coda unica int/fp come intel, parzialmente compensata dalle 4 unità memoria che possono fare istruzioni intere semplici e quindi 8 in totale.
Il cisc ha solo il vantaggio di una maggiore densità di codice... Ma se una istruzione cisc si traduce in n uops che potrebbero essere eseguite in parallelo, la complessità del motore OOO non diminuisce rispetto a un core risc dove devi mandare le n istruzioni separatamente...

Dipende da quanto "lavoro utile" facciano le uop nel caso dei CISC e dei RISC (perché ancora loro possono spezzare alcune istruzioni complesse in uops. I POWER lo fanno sicuramente, e da tempo).

Riguardo a decoder e uops, fra i commenti del link che hai riportato ne è apparso uno interessante e che riguarda Skylake. L'autore sostiene che il decoder utilizzato non sia a 5 vie, ma a 4. E dunque la capacità di generare fino a 5uop per ciclo di clock deriva dai pattern che adesso sono gestibili dal decoder: 1+1+1+1, 2+1+1+1, 3+1+1, 4+1, ... più ovviamente i casi più semplici, con meno uop generate.

Quindi da una parte il decoder rimane più semplice, visto che non ci sono 5 ma soltanto 4 unità di decodifica. E dall'altro diventa più flessibile ed efficiente, perché consente di intercettare più "casi d'uso".

Questo spiega perché rimangono i 16 byte per ciclo di clock analizzati. Poiché la dimensione media delle istruzioni è di poco inferiore a 4 byte, come detto prima, 4 * 4 = 16 e rientriamo in questo limite. Con 5 istruzioni decodificate per ciclo di clock si sarebbero sforati i 16 byte: 5 * 4 = 20.

Originariamente inviato da digieffe

ricordo che appena il fenomeno fu scoperto lessi qualcosa proposito delle figure che facevano quel lavoro, erano inquadrate in qualcosa tipo stealtmarketing, undercovermarketing e forse guerrillamarketing.

non credo di avere il tempo di andare a cercare, ma soprattutto dovrei sperare che utilizzino lo stesso nickname.

Non perderci tempo: sono tutte tecniche di marketing che non si applicano agli scenari ipotizzati qui.

Originariamente inviato da Wolfhang

Si, ma quando lavorano contemporaneamente CPU e iGPU la CPU viene segata a 3 GHz per rientrare nel TDP e la stessa cosa succede anche con Carrizo mobile, cosí rispondo pure a Paolo sulla questione delle frequenze nominali di AMD

Oibò. Povero Paolo.

Originariamente inviato da Roland74Fun

In realtà il termine secondo la lingua italiana é inesatto.

Il suffisso "-ista" generalmente viene usato per il soggetto che svolge una parte attivo in un determinato settore od in una certa situazione/avvenimento.

Ad es: Carburatorista= chi si occupa di carburatori.
Marmista= chi lavora il marmo.
Elettricista= chi lavora con apparati/impianti elettrici.
E così via.

Se, tanto per fare un esempio, dico che gli USA hanno applicato strategie di intelligence o militari riservate per destabilizzare governi di alcuni stati dell'America Latina e per affermare ciò pubblico libri con note, riferimenti e con prove documentali, allora non sono un complottista ma un complottologo, cioè uno che studia i complotti, anche se in taluni casi si potrebbe parlare di congiura se l'oggetto delle attenzioni é un numero più o meno ristretto di individui.

Chi invece si interessa di questi avvenimenti per puro diletto personale, leggendo librri di complottologi o siti internet più o meno affidabili, allora non é un complottologo ma un complottofilo, ossia un semplice appassionato.

Il termine complottista in senso stretto andrebbe invece utilizzato in riferimento a chi si fa promotore/autore di certe situazioni. Nell'esempio succitato gli USA.

Non sarà corretto grammaticalmente, ma è entrato nel lessico familiare, tant'è che la Treccani lo riporta come neologismo. D'altra parte non è certo l'unico caso di parola non perfettamente in linea con la lingua.

Comunque secondo te chi genera/alimenta complotti potrebbe rientrare o no nel termine? Per essere chiari, mi riferisco a gente che, di punto in bianco, si mette a scrivere che c'è un complotto blah blah blah ordito da blah blah ai danni di blah. Di fatto il complotto viene creato da roba che qualcuno s'è messo a scrivere.

Originariamente inviato da paolo.oliva2

Non capisco il concetto di spostare il buono Intel a seconda di come fa comodo. Quando si parla di silicio, è migliore quello Intel, quando si parla di prestazioni, di colpo il silicio Intel è come tutti gli altri e le prestazioni vengono dall'architettura.

Lo sai che ti dico? Cosa si inventerà (se) Zen andrà più di Broadwell? Di chi sarà la colpa? Il 14nm Intel del 25% migliore, l'architettura Intel cazzuta... forse la colpa la si dara all'HIS.... ma saranno sempre altre chiacchiere.

Ti stai arrampicando sugli specchi, cercando di cambiare discorso: non mi pare di aver citato Zen.

Ti ricordo che AMD ha sempre usato il SOI, anche coi 32nm di Bulldozer, che sarebbe superiore al bulk di Intel (sempre 32nm), se ho capito bene quello che è stato scritto finora qui sull'argomento.

Dunque AMD sarebbe comunque stata in vantaggio in termini di processo produttivo.

Non di prestazioni, perché i risultati sono stati quelli che sono...

[Wolfhang]

Originariamente inviato da bjt2

Si sa da tempo che il risparmio energetico su Kaveri è buggato... E' per questo che Carrizo fa moooolto meglio...

In che senso scusa, guarda che le frequenze della CPU vengono tagliate anche sulle APU carrizo...

[bjt2]

Originariamente inviato da cdimauro

Non vorrei che fosse compilato solo per le SSE. Avrebbe poco senso compilare usando le AVX, ma continuando a usare i registri soltanto a 128 bit: si perderebbe il maggior guadagno in termini prestazionali.

Si, scusa... SSE...

Originariamente inviato da cdimauro

Anche nei SoC ARM c'è parecchia altra roba, come dicevo prima, e il tutto contenuto in appena 3W.

Comunque dal link di Paolo si parla di 2,8Ghz base a 3,2Ghz turbo, con 65W per il quad core e 95W per l'octa core.

Non siamo lontani dai 2,5GHz di cui parlavamo, ma quanto a consumi c'è un abisso. E personalmente trovo le informazioni abbastanza realistiche.

Ma stiamo parlando del 28nm, giusto? E l'athlon x4 845 in 65W è dato 3.5 base e 3.8 turbo, con core excavator e suppongo che siano gli scarti con la GPU non funzionante... Sempre sul 28nm...
Lascia stare il link di Paolo... Sono scopiazzate del rumor di un tizio, appena iscritto e con un solo post su un forum, dove afferma quello senza prove... E i siti acchiappaclick ci sono andati a nozze... Si parla di un ES step A0... Siccome combacia con i preconcetti di molta gente (clock non superiore all'octacore intel) è stranamente stato preso per vangelo...

Sul 28nm l'x4 845 in 65W fa 3.5GHz base e 3.8 turbo e Zen sul 14nm fa peggio?!?!? Ma stiamo scherzando?!?!? A questo punto faccio uno shrink di excavator e salgo pure di più...

Originariamente inviato da cdimauro

Dipende da quanto "lavoro utile" facciano le uop nel caso dei CISC e dei RISC (perché ancora loro possono spezzare alcune istruzioni complesse in uops. I POWER lo fanno sicuramente, e da tempo).

Ma che razza di RISC sarebbe?

Originariamente inviato da cdimauro

Riguardo a decoder e uops, fra i commenti del link che hai riportato ne è apparso uno interessante e che riguarda Skylake. L'autore sostiene che il decoder utilizzato non sia a 5 vie, ma a 4. E dunque la capacità di generare fino a 5uop per ciclo di clock deriva dai pattern che adesso sono gestibili dal decoder: 1+1+1+1, 2+1+1+1, 3+1+1, 4+1, ... più ovviamente i casi più semplici, con meno uop generate.

Quindi da una parte il decoder rimane più semplice, visto che non ci sono 5 ma soltanto 4 unità di decodifica. E dall'altro diventa più flessibile ed efficiente, perché consente di intercettare più "casi d'uso".

Questo lo si sapeva da tempo: 4 decoder con al massimo una uop fusion, quindi 5 in totale. E la fusion solo in alcuni casi: cmp+jcc consecutivi, alu op +mem ecc...

Originariamente inviato da cdimauro

Questo spiega perché rimangono i 16 byte per ciclo di clock analizzati. Poiché la dimensione media delle istruzioni è di poco inferiore a 4 byte, come detto prima, 4 * 4 = 16 e rientriamo in questo limite. Con 5 istruzioni decodificate per ciclo di clock si sarebbero sforati i 16 byte: 5 * 4 = 20.

Ovviamente 16 byte alla volta è il fetch dalla Icache, ma ha un buffer di almeno 32 byte (non ricordo di preciso) su cui operare per la decodifica... E comunque esistono anche istruzioni di 1 solo byte...
Non ricordo se per la uop fusion, oltre ai limiti delle operazioni, ci sono anche limiti sull'occupazione... Sicuramente non devo superare la lunghezza del buffer...

[bjt2]

Originariamente inviato da Wolfhang

In che senso scusa, guarda che le frequenze della CPU vengono tagliate anche sulle APU carrizo...

Ho letto su semi o anand (non ricordo) che nelle varie generazioni di APU mobile sono state aggiustate gradatamente cose che non funzionavano... Ad esempio l'AVFS c'era anche prima di carrizo... Solo che non funzionava ed era disabilitato... Così per molte altre cose... Ho già detto che su Kaveri le frequenze CPU con GPU attiva erano fisse e basse, ad esempio...

[Free Gordon]

Originariamente inviato da Roland74Fun

In realtà il termine secondo la lingua italiana é inesatto.

[cdimauro]

Originariamente inviato da bjt2

Si, scusa... SSE...

Allora tutto quadra.

Ma stiamo parlando del 28nm, giusto? E l'athlon x4 845 in 65W è dato 3.5 base e 3.8 turbo, con core excavator e suppongo che siano gli scarti con la GPU non funzionante... Sempre sul 28nm...
Lascia stare il link di Paolo... Sono scopiazzate del rumor di un tizio, appena iscritto e con un solo post su un forum, dove afferma quello senza prove... E i siti acchiappaclick ci sono andati a nozze... Si parla di un ES step A0... Siccome combacia con i preconcetti di molta gente (clock non superiore all'octacore intel) è stranamente stato preso per vangelo...

Mi riferivo soltanto a Zen, secondo le informazioni del link di Paolo.

Dunque possiamo andare a buttare tutti i discorsi fatti.

Sul 28nm l'x4 845 in 65W fa 3.5GHz base e 3.8 turbo e Zen sul 14nm fa peggio?!?!? Ma stiamo scherzando?!?!? A questo punto faccio uno shrink di excavator e salgo pure di più...

Ma l'architettura di Zen non dovrebbe essere molto più efficiente?

Ma che razza di RISC sarebbe?

Da un pezzo i RISC non sono più quelli per cui è nato questo concetto / macrofamiglia.

Se è per questo, fanno anche uso di microcodice, e nello specifico sicuramente ARM e PowerPC/POWER, che hanno istruzioni molto complesse.

Questo lo si sapeva da tempo: 4 decoder con al massimo una uop fusion, quindi 5 in totale. E la fusion solo in alcuni casi: cmp+jcc consecutivi, alu op +mem ecc...

Con la uop fusion si fa l'inverso: si genera una uop "fondendone" due. Dunque il numero di uop generate dal decoder diminuirebbe.

Mentre Skylake genera una uop in più rispetto ai predecessori...

Ovviamente 16 byte alla volta è il fetch dalla Icache, ma ha un buffer di almeno 32 byte (non ricordo di preciso) su cui operare per la decodifica...

Mi pare che la decodifica operi soltanto su 16 byte alla volta, mentre il fetch dalla ICache è di 32 byte.

E comunque esistono anche istruzioni di 1 solo byte...

Certamente. E ce ne sono alcune che generano 4 uop, e alcune... microcodice.

Non ricordo se per la uop fusion, oltre ai limiti delle operazioni, ci sono anche limiti sull'occupazione... Sicuramente non devo superare la lunghezza del buffer...

Non lo ricordo nemmeno io. :-/

[george_p]

Originariamente inviato da cdimauro

Sofismi.

E cosa pretendi da un complottista? Tu, persona normale

[george_p]

Originariamente inviato da bjt2

Si sa da tempo che il risparmio energetico su Kaveri è buggato... E' per questo che Carrizo fa moooolto meglio...

Puoi spiegare meglio?

[Free Gordon]

Originariamente inviato da cdimauro

Non lo ricordo nemmeno io. :-/

Il link che hai in firma su Python è interessante.

[cdimauro]

Enjoy!

[digieffe]

Originariamente inviato da cdimauro

Non perderci tempo: sono tutte tecniche di marketing che non si applicano agli scenari ipotizzati qui.

sinceramente non riesco a capire lo scenario che è in atto qui.

Ti ricordo che AMD ha sempre usato il SOI, anche coi 32nm di Bulldozer, che sarebbe superiore al bulk di Intel (sempre 32nm), se ho capito bene quello che è stato scritto finora qui sull'argomento.

Dunque AMD sarebbe comunque stata in vantaggio in termini di processo produttivo.

Non di prestazioni, perché i risultati sono stati quelli che sono...

"medio un po'": è risaputo che il 32mn soi è uno tra i peggiori PP di GF, insieme al 65mn. (questo era uno degli equivoci)

qualcuno ti spieghera meglio ed in dettaglio, ma "maccheronicamente" ciò che sul 45mn girava a 3.8 sul 32mn girava a 2.9 (o 3.0?). Sul 32nm cerano anche altri component gpu, ecci, fatto sta che andava meno del 45.

[affiu]

Originariamente inviato da cdimauro

Ti faccio presente che Bulldozer è stato presentato qualche mese dopo che Intel aveva presentato Sandy, e usando lo stesso processo produttivo (32nm).

D

Ciao.

Non si chiede precisione ed accuratezza ma uno a gennaio 2011 ed uno ad ottobre 2011.
Poi di altra imprecisione, a mio parere io la vedrei anche qui:

Originariamente inviato da cdimauro

Mi pare ovvio: se Sandy Bridge, che è sempre a 32nm, si mangia a colazione Bulldozer (stesso processo produttivo) a frequenze inferiori e con l'SMT, allora c'è qualcosa che non va nel CMT.

Ma qui sto dicendo un'ovvietà.

De gustibus. Ma che il CMT sia stato fallimentare lo vedi sullo stesso processo produttivo: non serve scomodare i 14nm. Vedi sopra.

Bah a mio parere personale non credo che si possa utilizzare la parola ''mangia'' perchè ad esempio in ambito multi-task tra bulldozer e sandy non vedo affatto nessuna superiorità sempre parlando di vari aspetti tecnici di un processore.
In secondo luogo se proprio dobbiamo essere precisi, escluso il single-threads, se paragoniamo sandy a piledriver in ambito multi-thread non vedrei nessuna superiorità in multi-threads...e sempre sul 32nm siamo per entrambi.
In ambito multitask ti inviterei a leggere qui:
http://www.hwupgrade.it/forum/showpo...&postcount=348
Qui c'è stata la richiesta:http://www.hwupgrade.it/forum/showpo...postcount=6306
http://www.hwupgrade.it/forum/showpo...postcount=6300
Qui la risposta:
http://www.hwupgrade.it/forum/showpo...postcount=6302
http://www.hwupgrade.it/forum/showpo...postcount=6313
......ovviamente non se visto nessuna prova a confutare l'ipotesi o argomentazione....come te lo spiegheresti?....chi sarebbe superiore in quest'ambito?

Il cmt di per se è solo un astrazione filosofica a mio parere ma non nasce per caso ma in un ottica di integrazione per le future APU amd ed non è una scelta certamente vincente in ambito desktop ma in ambito apu amd di certo non è peggiorato nelle evoluzioni di codeste.
Ora su zen bisognerà capire che tipo di smt amd adotterà, perchè io avrei forti dubbi che si discosti molto dal cmt di bulldozer in quanto un core si che deve elaborare piu thread(in questo caso 2 ed in futuro magari più di uno) ma in che modo:
1)a threads ''inter-dipendenti'' cioè che non interferiscono
2)a threads ''inter-dipendenti'' cioè che interferiscono.
Lo so che non hanno senso le due supposizioni ma vorrei intendere se un threads venga in qualche modo ''bloccato'' da un altro oppure ''parcheggiato'' .....figuriamoci nel dopo zen+ fusion in cui un core fusion amd drovà elaborarne 4/8/n(come filosoficamente fanno le gpu d'altronde) threads alla volta stile cmt di bulldozer odierno
Sarebbe tutta qui, sempre a mio parere la differenza tra il smt e il cmt, cioè come vengano elaborati i threads senza che questi si affoghino tra loro....appunto da qui si vede cosa sia il motivo del multi-task di bulldozer dato che tra sandy e bulldozer sempre 8 threads alla volta elaborano, ma in modo diverso.
adesso si attende capire dove sia la differenza tra :
Bulldozer:1-core-1-thread
Zen: 1-core-2-threads...ma come???

[digieffe]

Originariamente inviato da bjt2

Si, scusa... SSE...



Ma stiamo parlando del 28nm, giusto? E l'athlon x4 845 in 65W è dato 3.5 base e 3.8 turbo, con core excavator e suppongo che siano gli scarti con la GPU non funzionante... Sempre sul 28nm...
Lascia stare il link di Paolo... Sono scopiazzate del rumor di un tizio, appena iscritto e con un solo post su un forum, dove afferma quello senza prove... E i siti acchiappaclick ci sono andati a nozze... Si parla di un ES step A0... Siccome combacia con i preconcetti di molta gente (clock non superiore all'octacore intel) è stranamente stato preso per vangelo...

Sul 28nm l'x4 845 in 65W fa 3.5GHz base e 3.8 turbo e Zen sul 14nm fa peggio?!?!? Ma stiamo scherzando?!?!? A questo punto faccio uno shrink di excavator e salgo pure di più...

c'e gia il 3.7 (o 3.8?) base e 4.1 turbo 65w - forse è A12 9800

[bjt2]

Originariamente inviato da cdimauro

Ma l'architettura di Zen non dovrebbe essere molto più efficiente?

Il mio discorso vale se sono riusciti a rimanere nello stesso FO4, aumentando l'IPC. Ed è possibile, perchè se le unità rimangono le stesse (intese con lo stesso numero di stadi), Zen ha solo 2 ALU in più. Ma questo non aumenta il FO4 perchè già lo scheduler della FPU di BD è a 4 vie e quindi dovrebbe essere possibile fare nello stesso FO4 anche lo scheduler a 4 vie della ALU. Le altre cose possono essere eventualmente implementate con uno o due stadi in più. L'SMT per esempio penso possa essere implementato come il CMT: già in BD il front end supporta 2 thread... Quindi è molto simile. L'unica cosa sono le cache: ma basta aumentare la latenza in cicli e si può fare il ciclo più corto...
Le unità sembra che siano rimaste le stesse perchè le latenze non sono diminuite (anzi alcune istruzioni hanno latenza maggiore), quindi non ho perso la speranza di un FO4 basso...

Originariamente inviato da cdimauro

Con la uop fusion si fa l'inverso: si genera una uop "fondendone" due. Dunque il numero di uop generate dal decoder diminuirebbe.

Mentre Skylake genera una uop in più rispetto ai predecessori...

Immagino che qui ci possa essere del misunderstanding... Mi pare di ricordare che 5 sono le istruzioni massime decodificate, che risultano in 4 uop di cui una fusa, ma potrei sbagliarmi...

Originariamente inviato da cdimauro

Mi pare che la decodifica operi soltanto su 16 byte alla volta, mentre il fetch dalla ICache è di 32 byte.

AMD fa fetch di 32 byte alla volta e il buffer è 64 byte, ma legge 16 byte alla volta, anche perchè una istruzione può essere anche 15 byte e quindi questo è il minimo che deve leggere... Immagino che sia una cosa simile per INTEL, ma in ogni caso il buffer deve essere pari almeno al doppio della granularità del fetch...

Originariamente inviato da cdimauro

Certamente. E ce ne sono alcune che generano 4 uop, e alcune... microcodice.

O alcune che ne generano 200 e oltre... Come FSINCOS...

[bjt2]

Originariamente inviato da george_p

Puoi spiegare meglio?

Non ti so dire i dettagli, ne mi sono salvato il link al post del tizio, che comunque era vago... Ricordo solo che disse che ci sono delle cose implementate che non funzionano e che sono disabilitate... Per esempio il doppio controller DDR3 e GDDR5 che doveva consentire di fare APU con memoria GDDR5 locale e che non si è potuta fare perchè buggata, l'AVFS che funziona solo su Carrizo, ma era già presente in Kaveri, ma disabilitato, ecc...

[bjt2]

Originariamente inviato da digieffe

c'e gia il 3.7 (o 3.8?) base e 4.1 turbo 65w - forse è A12 9800

Bristol Ridge... Ok, ma ancora deve uscire...
65W compresa GPU? E funzionerà il turbo con la GPU accesa?

[Piedone1113]

Originariamente inviato da affiu

Ciao.

Non si chiede precisione ed accuratezza ma uno a gennaio 2011 ed uno ad ottobre 2012.
Poi di altra imprecisione, a mio parere io la vedrei anche qui:


Bah a mio parere personale non credo che si possa utilizzare la parola ''mangia'' perchè ad esempio in ambito multi-task tra bulldozer e sandy non vedo affatto nessuna superiorità sempre parlando di vari aspetti tecnici di un processore.
In secondo luogo se proprio dobbiamo essere precisi, escluso il single-threads, se paragoniamo sandy a piledriver in ambito multi-thread non vedrei nessuna superiorità in multi-threads...e sempre sul 32nm siamo per entrambi.
In ambito multitask ti inviterei a leggere qui:
http://www.hwupgrade.it/forum/showpo...&postcount=348
Qui c'è stata la richiesta:http://www.hwupgrade.it/forum/showpo...postcount=6306
http://www.hwupgrade.it/forum/showpo...postcount=6300
Qui la risposta:
http://www.hwupgrade.it/forum/showpo...postcount=6302
http://www.hwupgrade.it/forum/showpo...postcount=6313
......ovviamente non se visto nessuna prova a confutare l'ipotesi o argomentazione....come te lo spiegheresti?....chi sarebbe superiore in quest'ambito?

Il cmt di per se è solo un astrazione filosofica a mio parere ma non nasce per caso ma in un ottica di integrazione per le future APU amd ed non è una scelta certamente vincente in ambito desktop ma in ambito apu amd di certo non è peggiorato nelle evoluzioni di codeste.
Ora su zen bisognerà capire che tipo di smt amd adotterà, perchè io avrei forti dubbi che si discosti molto dal cmt di bulldozer in quanto un core si che deve elaborare piu thread(in questo caso 2 ed in futuro magari più di uno) ma in che modo:
1)a threads ''inter-dipendenti'' cioè che non interferiscono
2)a threads ''inter-dipendenti'' cioè che interferiscono.
Lo so che non hanno senso le due supposizioni ma vorrei intendere se un threads venga in qualche modo ''bloccato'' da un altro oppure ''parcheggiato'' .....figuriamoci nel dopo zen+ fusion in cui un core fusion amd drovà elaborarne 4/8/n(come filosoficamente fanno le gpu d'altronde) threads alla volta stile cmt di bulldozer odierno
Sarebbe tutta qui, sempre a mio parere la differenza tra il smt e il cmt, cioè come vengano elaborati i threads senza che questi si affoghino tra loro....appunto da qui si vede cosa sia il motivo del multi-task di bulldozer dato che tra sandy e bulldozer sempre 8 threads alla volta elaborano, ma in modo diverso.
adesso si attende capire dove sia la differenza tra :
Bulldozer:1-core-1-thread
Zen: 1-core-2-threads...ma come???

Io ho sempre pensato che a segare BD sia stato il silicio, ma non bd Desktop, quanto piuttosto Opteron.
Avere la possibilità di un x16 bd a 4.0ghz su multisocket avrebbe permesso ad AMD di insidiare intel nel mercato server in tutte quelle situazioni dove si devono gestire molteplici istanze.
Il fallimento è stato li, dove si fanno i soldi è li, ed è li che ha toppato, il mercato desktop non era prioritario nella progettazione di bd.

[digieffe]

Originariamente inviato da bjt2

Bristol Ridge... Ok, ma ancora deve uscire...
65W compresa GPU? E funzionerà il turbo con la GPU accesa?

3.8ghz base, 4.1 turbo, 65wè il tdp comprensivo di gpu 512sp a 1.1ghz

ancora non si sa se c'è una diminuzione della frequenza

[bjt2]

Originariamente inviato da digieffe

3.8ghz base, 4.1 turbo, 65wè il tdp comprensivo di gpu 512sp a 1.1ghz

ancora non si sa se c'è una diminuzione della frequenza

Se mantiene i 3.8 anche con GPU accesa al max, visti gli 1.1GHz, vuol dire che i 4 core a 3.8GHz consumano max 20W... Non male... Vuol dire che un octacore 3.8GHz 40W ci può stare... E un 16 core 80W... Sul 28nm!
E un octacore 4GHz@95W sul 14nm non si può fare?!?!?!