[Thread Ufficiale] Aspettando ZEN

[°Phenom°]

Uscisse una bella apu stra pompata in grado di pilotare bene un 1920x1080 in gaming la comprerei al volo

[Mister D]

Originariamente inviato da el-mejo

Anche per me saranno "solo" 4 core + ht.

Se la parte grafica avrà solo 768 sp non sarà necessaria alcuna hbm, basta e avanza la ddr4 2400mhz in dual channel. Se invece verranno proposte apu con diciamo 1280 sp un singolo die hbm da 2gb (1024bit @ 500mhz) ci potrebbe stare: avrebbe più o meno lo stesso rapporto banda/potenza di un r9 nano (4096bit @ 500mhz x una gpu 4096sp).
Ma un bestio del genere scordiamocelo prima del 2017 inoltrato imho.

Tu dici?
Ora siamo così 2133 MHz come massimo ufficiale per il memory controller delle apu che corrisponde a ((2133*64*2)/8)/1024= 33,33 GB/sec di banda.
E considera che amd fa delle ram sue a 2400 MHz ddr3 per le apu con banda di 37,5 GB/sec. Non è che le ddr4 aumentano la banda così perché si chiamano 4 e non 3. Aumentano la banda perché hanno più frequenza, soprattutto se i canali rimangono solo 2.
Il calcolo è lo stesso che siano ddr1/ddr2/ddr3/ddr4/gddr5.
Se già ora con ddr3 2400 una gpu con 512 sp è castrata come fa a non esserlo una gpu con ddr4 2400 sempre con 2 canali da 64 bit ciascuno??
Al massimo se mettiamo delle belle ddr4 3600 MHz allora sì che cambia la storia:
((3600*64*2)/8)/1024=56,25 GB/sec

[capitan_crasy]

Originariamente inviato da stefanonweb

Ok, ma vista la tua esperienza... Verosimilmente potremmo aspettarci APU a 6/8 core? Non penso sia logico continuare con 4 + Grafica... Tu personalmente che ne pensi? Grazie.

Io penso che finchè il mercato delle APU rimarrà quello attuale (middle) una soluzione 4 core (che comunque dovrebbe avere anche 4 logici) sarà quella più probabile; forse ci sarà quella speciale dedicata al gaming ma finchè verranno prodotte CPU, le APU saranno sempre un gradino sotto
Resta da vedere quanto ce l'avrà grossa la GPU integrata (basata su polaris) delle APU Zen che secondo me come potenza di calcolo puro si avvicinerà alle vecchie soluzioni HD79x0!

[sgrinfia]

Originariamente inviato da capitan_crasy

Io penso che finchè il mercato delle APU rimarrà quello attuale (middle) una soluzione 4 core (che comunque dovrebbe avere anche 4 logici) sarà quella più probabile; forse ci sarà quella speciale dedicata al gaming ma finchè verranno prodotte CPU, le APU saranno sempre un gradino sotto
Resta da vedere quanto ce l'avrà grossa la GPU integrata (basata su polaris) delle APU Zen che secondo me come potenza di calcolo puro si avvicinerà alle vecchie soluzioni HD79x0!

Ciao, una integrata con una potenza di calcolo di un hd 79x0 !,scherzi vero?.

[tuttodigitale]

Originariamente inviato da el-mejo

Anche per me saranno "solo" 4 core + ht.

Se la parte grafica avrà solo 768 sp non sarà necessaria alcuna hbm, basta e avanza la ddr4 2400mhz in dual channel. Se invece verranno proposte apu con diciamo 1280 sp un singolo die hbm da 2gb (1024bit @ 500mhz) ci potrebbe stare: avrebbe più o meno lo stesso rapporto banda/potenza di un r9 nano (4096bit @ 500mhz x una gpu 4096sp).
Ma un bestio del genere scordiamocelo prima del 2017 inoltrato imho.

considera che la stessa gpu da 512, accoppiata con memorie gddr5 fa segnare il 50-55% di prestazioni in più (Vedi hd7750, ma gira a 800vs720MHz, +11%) rispetto a kaveri con memorie ddr3 a 2400MHz.
Tra il miglioramento sulla compressione dati di gcn 1.2 (+30%), o ulteriore boost di clock , che passa da 720 a 950MHz(+30%) che non guasta mai, dovrebbe riuscire finalmente ad offrire prestazioni paragonabill alla scheda discreta.

ps i 2 valori non vanno sommati: significa che andrà "solo" il 30% in più, quindi circa l'85-90% di una hd7750. In definitiva, considerando l'aumento di clock, siamo esattamente nelle stesse identiche condizioni gi bandwidth limited che hanno afflitto le gpu kaveri...


BRistol Ridge anche qualora fosse una soluzione da 512sp, porterà in dote miglioramenti di prestazioni significativi nei giochi. Figuriamoci un ulteriore incarnazione di GCN 1.3 (alcuni test suggeriscono che AMD sia ancora indietro rispetto a nvidia, negli algoritmi di compressione):

Comunque credo che non saranno meno di 1024 gli SP ad 1 GHz della soluzione APU ZEN e in tal caso le HBM o gddr5 sono obbligatorie...

[capitan_crasy]

Originariamente inviato da sgrinfia

Ciao, una integrata con una potenza di calcolo di un hd 79x0 !,scherzi vero?.

Facciamo un mini riassunto:
Llano aveva circa 400 Gigaflops.
Trinity aveva 763 Gigaflops.
Kaveri ha 856 Gigaflops.
Carrizo mobile ha 812 Gigaflop e la previsione per le APU Carrizo sul socket AM4 potrebbe arrivare al traguardo del Teraflops.
La vecchia HD7950 (detta Tahiti pro v.1) non arriva a 3 Teraflops (2.87 per la precisione).
Sono ottimista ma per il 2017 mi aspetto una GPU polaris evoluta + (forse) una CPU ZEN+ e credo che il traguardo di 3 Teraflops non sia così utopistico!
Quindi no, non scherzo...

[el-mejo]

Originariamente inviato da tuttodigitale

considera che la stessa gpu da 512, accoppiata con memorie gddr5 fa segnare il 50-55% di prestazioni in più (Vedi hd7750, ma gira a 800vs720MHz, +11%) rispetto a kaveri con memorie ddr3 a 2400MHz.
Tra il miglioramento sulla compressione dati di gcn 1.2 (+30%), o ulteriore boost di clock , che passa da 720 a 950MHz(+30%) che non guasta mai, dovrebbe riuscire finalmente ad offrire prestazioni paragonabill alla scheda discreta...
BRistol Ridge anche qualora fosse una soluzione da 512sp, porterà in dote miglioramenti di prestazioni significativi nei giochi. Figuriamoci un ulteriore incarnazione di GCN 1.3 (alcuni test suggeriscono che AMD sia ancora indietro rispetto a nvidia, negli algoritmi di compressione):

Comunque credo che non saranno meno di 1024 gli SP ad 1 GHz della soluzione APU ZEN.

In effetti è vero, e secondo me il vantaggio è più legato ai timing ottimizzati delle memorie di tipo gddr che dalla banda disponibile, infatti oltre i 2133mhz Kaveri ha guadagni di prestazioni risibili.
Rimango dell'opinione che passerà del tempo di vedere apu con hbm, sia per capire come verrà gestita questa memoria aggiuntiva (disponibile solo per la gpu salvo applicazioni HSA?) e sopratutto per la necessità dell'interposer, che fà lievitale il prezzo e le rese in maniera incompatibile per prodotti mainstream.
Il fatto che la prossima gpu Nvidia Pascal che andrà a rimpiazzare GM204 come fascia prestazionale, quindi su gpu del calibro di 500$, non le implementerà fa pensare. Soprattutto il fatto che le applicazioni gpgpu, di cui nvidia ha quasi tutto il mercato, sono perlopiù limitate dalla banda e trarrebbero grande beneficio anche dalle hbm di prima generazione.

[tuttodigitale]

il bandwidth limited, non si manifesti come il CPU limited, ovvero con un margine ben definito...in realtà si può nascondere il collo di bottiglia offerto dalla ram con l'aumento di forza bruta..
negli anni passati si vendevano nel mobile soluzioni da 720sp 128bit ddr3 che andavano quanto quelle da 400sp 128bit gddr5, entrambi andavano molto di più delle soluzioni 400sp 128bit ddr/gddr3...
Ancora più confusi?

Pensate in questo modo, l'operatore X e Y devono mettere le mani in maniera alternativa su un oggetto.
inizialmente il tempo impiegato da X e Y è 50-50.
X decide di raddoppiare la velocità e si passa ad un 33-66. Y sta iniziando a fare da collo di bottiglia.
X raddoppia ancora la velocità e si passa ad un 20-80. Il collo di bottiglia sta aumentando.
Nonostante ciò le prestazioni son aumentate del 33%primo caso, e di un ulteriore 20% nel secondo caso..
Per arrivare alla totale strozzatura, che approssimiamo a 10-90, Y dovrebbe essere 8 volte più lento di X....+12%...

Se ci pensate è esattamente quello che succede con i test di decompressione: aumentate il clock della sola cpu le prestazioni migliorano, aumentate il clock della ram, idem. Aumentate il clock di entrambi e avrete uno scaling perfetto.
questo per chiarire un concetto. Si può potenzialmente aumentare le prestazioni anche con un collo di bottiglia, che poi è esattamente quello che sta facendo AMD con kaveri (quella gpu rimane un piccolo mostro)..non è il massimo, ma meglio di niente...

Originariamente inviato da el-mejo

In effetti è vero, e secondo me il vantaggio è più legato ai timing ottimizzati delle memorie di tipo gddr che dalla banda disponibile, infatti oltre i 2133mhz Kaveri ha guadagni di prestazioni risibili.

le gddr5 hanno latenze molto più elevate (sono le HBM ad averle basse). Ho visto un pò test in giro, in effetti lo scaling è pessimo (e non dovrebbe esserlo). Che i 512sp non siano pesantemente bandwidth limited?NO
La realtà è ancora più triste, il collo di bottiglia secondo test sintetici sembra essere offerto dal MC... Ma come si fa?

[paolo.oliva2]

Originariamente inviato da gridracedriver

si il 95w si dice dall'inizio che sarebbe l'8 core, però il discorso del 32c a 750w non ha senso in quanto ti ricordo che il 6700k skylake a 14nm 4c è 91watt per 4/4.2 ghz def/turbo

a 4 ghz probabilmente ha metà efficienza che non ha 3ghz e a 2.5ghz guadagnerà ancora un 30% come efficienza l'architettura core... e zen sarà simile da questo punto di vista

Aspetta, quello che voglio dire è che è chiaro che l'efficienza aumenta al diminuire della frequenza, ma è anche chiaro che partendo da un Piledriver 125W X8 4GHz, AMD ha potuto realizzare un Opteron X16 (2 die X8) di poco sotto i 3GHz ma sotto i 140W TDP
Per dirla in matematica spiccia ed approssimativa, con un -35% di frequenza ha ottenuto un +100% di core con un +10% di TDP.

Mi sembra chiaro che far rientrare un Opteron Zen X32 nei 140W, partendo da un X4 95W,, vorrebbe dire aumentare di 8 volte i core (e non del doppio), cosa assolutamente impossibile, manco frazionando la frequenza operativa a 1/4.

Mi sembra ovvio che non si può considerare Zen 95W X4, come del resto tutte le info su Zen X32 riguardano X32 e non 32TH. Anche ipotizzando 32TH, si parlerebbe pur sempre di un X16 che vorrebbe sempre un X8 come punto di partenza e mai un X4.
Altresì è abbastanza auspicabile l'esatto contrario, cioè partendo da un Excavator Carrizo X4 APU 15W di poco sotto i 3GHz e sul 28nm, che Zen anche raddoppiando il TDP a core, già un X4 risulterebbe 30W (ma da togliere la parte IGP dell'APU Carrizo e del guadagno del 14nm sul 28nm).

Non sto facendo un discorso di bandiera... parto solamente dal presupposto TANGIBILE del TDP di un Carrizo sul 28nm e da qui proiettare Zen sul 14nm, mentre mi sembra errato partire che se Intel un X4+4 risulta 95W allora AMD NON PUO' avere un X8+8, non so se sono chiaro.

E poi alla fine io sinceramente non tifo per Zen.... Avrei preferito 100 volte un XV 8 moduli 125W 4GHz... , visto che ormai anche i muri hanno capito che il TDP alto di BD non aveva nulla a che vedere con l'architettura ed era un esclusivo problema di silicio.

[paolo.oliva2]

Originariamente inviato da Free Gordon

Quì lo dico e qui lo nego...ma imho l'octacore AMD, sarà un "semplice" 4+4...come tutti gli i7 desktop.

Se davvero fosse un 8core, avrebbe 16thread e quindi un potenziale MT "mostruoso" rispetto ad un i7 Intel...anche di uno Skylake....

Non ci credo sinceramente.

Ma ci spero!

Io preferisco 8 core PURI senza SMT che 4 core con SMT.
Magari puoi pensare che lo dico per bandiera... però io preferirei un XV X16 a 4GHz che un Zen X8+8 che va bene il +40% di IPC dichiarato ma forse anzichè girare a 4GHz va a 3GHz quindi alla fine IPC x Frequenza il guadagno si abbasserebbe al 10%...
Questo è come la penso... è indubbio che comunque un Zen X8+8 potrà sopportare carichi maggiori di un Piledriver X8/4M, ma basta gurdare il confronto 8370 vs 5960X e di qui proiettare un Piledriver o meglio Excavator X16 come si rapporterebbe... e non penso che AMD a prima botta con Zen possa arrivare ad una efficienza architetturale simile a quella Intel (efficienza, non potenza).
Quindi se l'architettura BD (su silicio idoneo) con un numero di moduli uguale al numero di core + SMT Intel può dire la sua, credo che lo stesso confronto BD ma vs Zen possa essere più favorevole a BD.

[digieffe]

Originariamente inviato da paolo.oliva2

Io preferisco 8 core PURI senza SMT che 4 core con SMT.
Magari puoi pensare che lo dico per bandiera... però io preferirei un XV X16 a 4GHz che un Zen X8+8 che va bene il +40% di IPC dichiarato ma forse anzichè girare a 4GHz va a 3GHz quindi alla fine IPC x Frequenza il guadagno si abbasserebbe al 10%...
Questo è come la penso... è indubbio che comunque un Zen X8+8 potrà sopportare carichi maggiori di un Piledriver X8/4M, ma basta gurdare il confronto 8370 vs 5960X e di qui proiettare un Piledriver o meglio Excavator X16 come si rapporterebbe... e non penso che AMD a prima botta con Zen possa arrivare ad una efficienza architetturale simile a quella Intel (efficienza, non potenza).
Quindi se l'architettura BD (su silicio idoneo) con un numero di moduli uguale al numero di core + SMT Intel può dire la sua, credo che lo stesso confronto BD ma vs Zen possa essere più favorevole a BD.

facendo 100 l'IPC ST di excavator e 185 quello del modulo, Zen avrebbe 140 in ST e (supponendo un guadagno del 30% in HT) 182 in HT.

Ne consegue che 1 core+ht Zen =~ 1 modulo XV.

Ma i più preparati hanno scritto che il guadano in HT sarà maggiore di Intel (30%), quindi se ciò sarà vero 1 core+ht Zen > 1 modulo XV.

resta il discorso della frequenza, se come ha scritto qualcuno (tuttodigitale ?) le pipeline saranno simili ad XV, allora anche le frequenze saranno analoghe. In altre parole credo che a parità di Watt XV non esprimerà maggior througput (IPC x freq x core) di Zen, ma semai il contrario.

EDIT: poi credo che tu facessi il paragone con un 140w mentre Zen sarà a 95w. ci sarà da capire quanti core inseriranno per il 140w di zen.

[Free Gordon]

Originariamente inviato da el-mejo

Se invece verranno proposte apu con diciamo 1280 sp un singolo die hbm da 2gb (1024bit @ 500mhz) ci potrebbe stare: avrebbe più o meno lo stesso rapporto banda/potenza di un r9 nano (4096bit @ 500mhz x una gpu 4096sp).
Ma un bestio del genere scordiamocelo prima del 2017 inoltrato imho.

E' quasi 3 anni che è in commercio una APU con 18CU 1152sp (quella di PS4) e 8 core Jaguar,non credo che ci siano limiti tecnologici per produrla già oggi con 4 core XV e 20 CU + 2GB di HBM...
Il problema sono i costi... e il mercato risicato di una soluzione del genere...

[affiu]

Originariamente inviato da paolo.oliva2

Io preferisco 8 core PURI senza SMT che 4 core con SMT.
Magari puoi pensare che lo dico per bandiera... però io preferirei un XV X16 a 4GHz che un Zen X8+8 che va bene il +40% di IPC dichiarato ma forse anzichè girare a 4GHz va a 3GHz quindi alla fine IPC x Frequenza il guadagno si abbasserebbe al 10%...
Questo è come la penso... è indubbio che comunque un Zen X8+8 potrà sopportare carichi maggiori di un Piledriver X8/4M, ma basta gurdare il confronto 8370 vs 5960X e di qui proiettare un Piledriver o meglio Excavator X16 come si rapporterebbe... e non penso che AMD a prima botta con Zen possa arrivare ad una efficienza architetturale simile a quella Intel (efficienza, non potenza).
Quindi se l'architettura BD (su silicio idoneo) con un numero di moduli uguale al numero di core + SMT Intel può dire la sua, credo che lo stesso confronto BD ma vs Zen possa essere più favorevole a BD.

D'accordo ma 8 core puri come li intendete, ma da dove escono fuori i 16 threads?
Forse è stato più conveniente diminuire l'area di un core con un core piu potente di 2 singole unita integer sfruttando la miniaturizzazione;
Alla fine hanno accorpato i 2 core integer di un singolo modulo bulldozer in un super core, che riesce a elaborare 2 threads alla volta(come d'altronde fa un modulo bulldozer, sempre 2 sono) ma occupando un area minore di un altro qualsiasi ipotetico modulo-dual integer a 14 nm.
Così si avrebbe la parte in virgola mobile di pari livello e non condivisa come nei due core integer del modulo ma associata ad un singolo core zen.
La prova fatta sulle lunghezze degli stadi, anche sconosciuta, con bulldozer, poteva significare elaborare senza interferenza fra i threads in esecuzione....
Immagina un 8 core zen in overclock max daily;.....significherebbe tenere tutti i programmi di qualsiasi programma utilizziamo, tutti attivi, fare conversioni video, tenere aperti una 5nquina di giochi aperti ecc ecc, ed il procio non lo affatichi, anzi quando sta a riposo è quasi spento.
In maniera teorica non si puo sdoppiare la matematica, cioè se si volessero 2 threads senza interferenza di dipendenze reciproche, bisogna che un thread abbia il suo core dedicato, a questo va aggiunto il tempo di esecuzione.
Adesso quindi un singolo core zen dovrebbe gestire 2 threads, ma come fanno ad NON interferire?
Forse le pipeline alte e la frequenza più alta possibile, potrebbe diminuire la possibilità che i thread interferiscono tra loro nonostante i 2 threads abbiano risorse del singolo core da dividere.

[bjt2]

Originariamente inviato da el-mejo

In effetti è vero, e secondo me il vantaggio è più legato ai timing ottimizzati delle memorie di tipo gddr che dalla banda disponibile, infatti oltre i 2133mhz Kaveri ha guadagni di prestazioni risibili.
Rimango dell'opinione che passerà del tempo di vedere apu con hbm, sia per capire come verrà gestita questa memoria aggiuntiva (disponibile solo per la gpu salvo applicazioni HSA?) e sopratutto per la necessità dell'interposer, che fà lievitale il prezzo e le rese in maniera incompatibile per prodotti mainstream.
Il fatto che la prossima gpu Nvidia Pascal che andrà a rimpiazzare GM204 come fascia prestazionale, quindi su gpu del calibro di 500$, non le implementerà fa pensare. Soprattutto il fatto che le applicazioni gpgpu, di cui nvidia ha quasi tutto il mercato, sono perlopiù limitate dalla banda e trarrebbero grande beneficio anche dalle hbm di prima generazione.

L'interposer costerà anche di più, ma se fai una APU con 8/16/32GB di RAM, non sono necessari gli slot RAM (MB meno costosa) e neanche le RAM (!)... Quindi a conti fatti forse spendi anche di meno e con meno consumi e più prestazioni...

[bjt2]

Originariamente inviato da paolo.oliva2

Io preferisco 8 core PURI senza SMT che 4 core con SMT.
Magari puoi pensare che lo dico per bandiera... però io preferirei un XV X16 a 4GHz che un Zen X8+8 che va bene il +40% di IPC dichiarato ma forse anzichè girare a 4GHz va a 3GHz quindi alla fine IPC x Frequenza il guadagno si abbasserebbe al 10%...
Questo è come la penso... è indubbio che comunque un Zen X8+8 potrà sopportare carichi maggiori di un Piledriver X8/4M, ma basta gurdare il confronto 8370 vs 5960X e di qui proiettare un Piledriver o meglio Excavator X16 come si rapporterebbe... e non penso che AMD a prima botta con Zen possa arrivare ad una efficienza architetturale simile a quella Intel (efficienza, non potenza).
Quindi se l'architettura BD (su silicio idoneo) con un numero di moduli uguale al numero di core + SMT Intel può dire la sua, credo che lo stesso confronto BD ma vs Zen possa essere più favorevole a BD.

Il consumo è molto non lineare con le frequenze. Un 32 core Zen è possibile con clock tra i 2 e i 2,5GHz, IMHO. Ricordiamo che i primi opteron a 16 core avevano un clock base di 1,6GHz e un turbo di +1.2GHz... Non credo che non si siano fatti passi in avanti dai primi opteron...

[Mister D]

Originariamente inviato da affiu

D'accordo ma 8 core puri come li intendete, ma da dove escono fuori i 16 threads?
Forse è stato più conveniente diminuire l'area di un core con un core piu potente di 2 singole unita integer sfruttando la miniaturizzazione;
Alla fine hanno accorpato i 2 core integer di un singolo modulo bulldozer in un super core, che riesce a elaborare 2 threads alla volta(come d'altronde fa un modulo bulldozer, sempre 2 sono) ma occupando un area minore di un altro qualsiasi ipotetico modulo-dual integer a 14 nm.
Così si avrebbe la parte in virgola mobile di pari livello e non condivisa come nei due core integer del modulo ma associata ad un singolo core zen.
La prova fatta sulle lunghezze degli stadi, anche sconosciuta, con bulldozer, poteva significare elaborare senza interferenza fra i threads in esecuzione....
Immagina un 8 core zen in overclock max daily;.....significherebbe tenere tutti i programmi di qualsiasi programma utilizziamo, tutti attivi, fare conversioni video, tenere aperti una 5nquina di giochi aperti ecc ecc, ed il procio non lo affatichi, anzi quando sta a riposo è quasi spento.
In maniera teorica non si puo sdoppiare la matematica, cioè se si volessero 2 threads senza interferenza di dipendenze reciproche, bisogna che un thread abbia il suo core dedicato, a questo va aggiunto il tempo di esecuzione.
Adesso quindi un singolo core zen dovrebbe gestire 2 threads, ma come fanno ad NON interferire?
Forse le pipeline alte e la frequenza più alta possibile, potrebbe diminuire la possibilità che i thread interferiscono tra loro nonostante i 2 threads abbiano risorse del singolo core da dividere.

Ciao,
escono fuori dalle slide su ZEN dove a chiare lettere è riportato SMT sinonimo di Simultaneus Multi Threading, cioè quella tecnologia che permette, duplicando le risorse pre core (i registri, alcune unità logiche), di poter processare n thread (con n=2 nel caso di intel, n=4 nel caso dei Power7 di IBM o anche n=8 nel caso degli utlimi Power8) simultaneamente per ogni core fisico.
Quindi in Zen è stato abbandonato il concetto di CMT in favore del SMT e ogni core sarà quindi composto da una unità integer e una floating point con l'aggiunta di questa tecnica che aumenta sia l'efficienza delle pipeline sia il throughput in MT.
Quindi Zen 8 core potrà processare fino a 8 thread contemporaneamente e fino a 16 thread simultaneamente (cioè quando le pipe del core stallano ed è in attesa) ipotizzando quindi un SMT a 2 vie. Se fosse 4 vie un 8 core potrebbe processare anche 32 thread simult.

Per quanto riguarda l'interferenza tra thread nei processori con SMT può avvenire solo se il thread B è conseguente al risultato del thread A e in questo caso il thread A verrà messo un un core fisco e il thread B anche. Le pipe del thread B andranno in stallo se il thread A non darà in tempo il risultato e inizieranno a processare un thread C. Appena il thread A darà il risultato allora le pipe del thread B si rimetteranno al lavoro perché i dati saranno presenti in cache o in ram. Lo scaling del SMT è dato cmq dall'ottimizzazione del codice e dalla parallelizzazione dello stesso. Più un codice può contenere parti che vengono elaborate in parallelo più il SMT porterà beneficio. Altresì più un codice è ottimizzato per non far stallare le pipe, più il SMT non entrerà in gioco e non darà beneficio, viceversa un codice poco ottimizzato che fa mandare in stallo le pipe consente al SMT di entrare in funzionamento e di annullare i tempi morti processando altro. Questo è un veloce riassunto, poi se vuoi trovi un sacco di materiale in inglese su come il SMT funziona, chiaramente materiale anche molto tecnico.

[tuttodigitale]

Originariamente inviato da affiu

In maniera teorica non si puo sdoppiare la matematica, cioè se si volessero 2 threads senza interferenza di dipendenze reciproche, bisogna che un thread abbia il suo core dedicato, a questo va aggiunto il tempo di esecuzione.
Adesso quindi un singolo core zen dovrebbe gestire 2 threads, ma come fanno ad NON interferire?
Forse le pipeline alte e la frequenza più alta possibile, potrebbe diminuire la possibilità che i thread interferiscono tra loro nonostante i 2 threads abbiano risorse del singolo core da dividere.

è lo scheduler del sistema operativo a dover gestire il carico. Le CPU, almeno quelle con SMT a 2 vie, gestiscono la priorità con la logica FIFO. Ovvero il primo core logico che fa richiesta ha la precedenza.
Ovviamente la perdita, inevitabile delle prestazioni nel ST (i 2 thread sono in competizione) è compensata dalle migliori prestazioni complessive (Che poi è quello che conta).
Ci sono molte più dipendenze su un codice sequenziale, ed è per questo che la CPU si trova impossibilitata a sfruttare totalmente la sua ampiezza. Il motore OoO, ovvero lo scheduler della CPU, fa proprio questo: manda in esecuzione in parallelo codice sequenziale, manipolandone anche l'ordine di esecuzione....Nonostante i buoni propositi, spesso questo non basta. Le unità esecutive lasciate vuote, vengono riempite dal thread appartenente all'altro core logico, ovviamente che era stato già prelevato e decodificato.
Il secondo thread, infatti, deve rubare già le risorse del primo per essere utile allo scopo, è meglio sottolinearlo, se no pare, che venga in soccorso solo quando serve...è un pò come quando uno si porta la borsa da pronto soccorso. Il peso e il disagio del trasporto rappresentano il peso sulla decodifica, cache l0-l3, e sullo scheduler, lo spray medicale il thread, e la botta/ferita, una pipeline di esecuzione da riempire...
se la ferita è così profonda (predizione rami sbagliata) il primo thread (anche questo un medicinale) deve attendere un'altra ferita, prima di iniziare ad operare.

[affiu]

A tuttodigitale e Mister D

Va bene tutta la spiegazione ma io parto sempre da bulldozer, seppur sbagliando, è cioè che il modulo nasce per processsare 2 thread, ma non possiamo concepire un modulo bulldozer come 2 core ''veri e propri'' in quanto non hanno le risorse di un singolo core ''normale''; tutto questo per consentire di elaborare sempre 2 threads anche se pero in 2 ''unità integer'' e conservando il principio di esecuzione 1-core-1thread.
Se allora fanno come dite voi significa che si abbandonera questo concetto ...in pratica io parto dal die di un fx 8350: 4 moduli x 8 unità integer; da questo cerco di immaginare quanto si può ridurre il die di un ipotetico quad-modulo-zen e da questo pensare di mettere 4 core zen dentro al modulo.
Tutto questo è possibile mantenendo sempre il connubio 1-core-1thread?!
In fondo se fosse possibile tramite il passaggio da 32 nm a 14 nm perchè escluderlo e sempre ''una forma di smt''( a due vie in questo caso) deve essere perchè da un ipotetico modulo zen escono 4 thread quanto nello stesso modulo bulldozer ne uscivano sempre 2 thread elaborati.

[Mister D]

Originariamente inviato da affiu

A tuttodigitale e Mister D

Va bene tutta la spiegazione ma io parto sempre da bulldozer, seppur sbagliando, è cioè che il modulo nasce per processsare 2 thread, ma non possiamo concepire un modulo bulldozer come 2 core ''veri e propri'' in quanto non hanno le risorse di un singolo core ''normale''; tutto questo per consentire di elaborare sempre 2 threads anche se pero in 2 ''unità integer'' e conservando il principio di esecuzione 1-core-1thread.
Se allora fanno come dite voi significa che si abbandonera questo concetto ...in pratica io parto dal die di un fx 8350: 4 moduli x 8 unità integer; da questo cerco di immaginare quanto si può ridurre il die di un ipotetico quad-modulo-zen e da questo pensare di mettere 4 core zen dentro al modulo.
Tutto questo è possibile mantenendo sempre il connubio 1-core-1thread?!
In fondo se fosse possibile tramite il passaggio da 32 nm a 14 nm perchè escluderlo e sempre ''una forma di smt''( a due vie in questo caso) deve essere perchè da un ipotetico modulo zen escono 4 thread quanto nello stesso modulo bulldozer ne uscivano sempre 2 thread elaborati.

Ciao,
non possiamo concepirlo come core vero e proprio solo perché ci siamo abituati in epoca moderna a vedere ogni core di una cpu superscalare x86 formata da 1 INTU e 1 FPU + tutte le unità logiche necessarie al rifornimento/smistamento di dati alle pipeline.
Con il CMT le unità di esecuzione sono 2 INTU + 1 FPU per ogni modulo e alcune parti condivise (unità di fetch, decodifica e cache L2 per il modulo BD/PD mentre da steamroller in avanti sono solo rimaste fetch e cache condivise a livello di modulo, il resto è singolo per ogni unità integer) ma il numero di thread processati dipende dalle unità integer ergo ci sono 8 core integer reali e il problema dell'interferenza è gestito a livello di OS o di motore OoO perché con il CMT i thread processati in ogni ciclo di clock pari al numero delle unità fisiche presente, cioè 8.
Purtroppo amd ha deciso di ritornare indietro come approccio e aggiungere il SMT perché conviene sia per un motivo di efficienza, sia perché costa poco in termini di die in rapporto al guadagno in MT.
Il connubio 1 core 1 thread verrà abbandonato in favore quindi 1 core n thread con n a seconda di quante vie verranno implementate con il SMT.
A vedere dalle porte, secondo i rumors usciti fin'ora, ci sarebbe spazio già per un SMT 4 ma molto probabilmente, a mio modo di vedere, si tengono l'asso per ZEN+. Ergo è più probabile che ZEN sia un smt 2 vie, ergo un 1 core 2 thread. Non esisterà il concetto di modulo se non nel fatto che una parte di cache L3 è condivisa ogni tot core (4 core -> 8MB di cache l3 ergo si può parlare di modulo zen con 4 core ma questi potranno processare 8 thread per quanto detto fin d'ora. Non puoi però paragonare il modulo di una volta con quello di ora perché sono due cose completamente diverse. Guarda il conteggio delle unità INT e FP. Il modulo zen conta 4 INTU e 4 FPU e ricalca il vecchio stile dove ogni core di una cpu era formato da 1INTU+1FPU).

[Free Gordon]

Originariamente inviato da bjt2

L'interposer costerà anche di più, ma se fai una APU con 8/16/32GB di RAM, non sono necessari gli slot RAM (MB meno costosa) e neanche le RAM (!)... Quindi a conti fatti forse spendi anche di meno e con meno consumi e più prestazioni...

Avrebbe senso una APU simile per il mobile...anche con soli 8GB di ram totali. Direi che bastano e avanzano. Anche molti desktop da ufficio ne potrebbero giovare.. ma credo farebbe più fortuna nel mobile, dato il prezzo di vendita in media più alto.