[Thread Ufficiale] CPU serie FX: AMD Bulldozer/Piledriver - Aspettando Steamroller

[Grizlod®]

edit:

[el-mejo]

Per diminuire le circuiterie (quindi transistors), inoltre FMAx, penso siano più portate all'architettura BD (cioè con filosofia K1x comporterebbe maggior complessità che inciderebbe sul TDP). Le XOP, mi pare siano una rivisitazione delle ex SSE5 che Intel boicottò a suo tempo e che nessuno se le fila.

Anche le stesse FMAC se le filano in pochi (nei confronti delle varie SSE per es.), sostanzialmente benchmarks e forse qualche progetto BOINC.
Ok l'innovazione, ma AMD deve innovare dove conta per essa...tipo il DRAM controller integrato nella CPU; per le istruzioni è costretta ad "inseguire"Intel.
Non puo permettersi invenzioni "fuori", non la cagherà nessuno.

EDIT: ricordavo bene...con Intel è sempre la stessa storia... https://en.wikipedia.org/wiki/XOP_instruction_set

A parte che fa brutto togliere istruzioni su una generazione sucessive (a meno che siano del tutto obsolete, come le 3dnow+), in genere quelle istruzioni ci mettono diversi anni ad essere implementate in maniera diffusa.
Già il fatto che vengano usato in aree specifiche come progetti Boinc significa che danno un boost prestazionale, e se Amd vuole tornare a competere nel settore server/HPC dove ogni ciclo risparmiato è un ciclo guadagnato(:D ) e dove impenmentazioni ad hoc non sono un problema, è meglio che li mantenga.

In fondo Intel supporta comunque istruzioni avanzate senza avere problemi di transistor, ipc e tdp: Amd deve fare lo stesso.

[george_p]

Per diminuire le circuiterie (quindi transistors), inoltre FMAx, penso siano più portate all'architettura BD (cioè con filosofia K1x comporterebbe maggior complessità che inciderebbe sul TDP). Le XOP, mi pare siano una rivisitazione delle ex SSE5 che Intel boicottò a suo tempo e che nessuno se le fila.

Anche le stesse FMAC se le filano in pochi (nei confronti delle varie SSE per es.), sostanzialmente benchmarks e forse qualche progetto BOINC.
Ok l'innovazione, ma AMD deve innovare dove conta per essa...tipo il DRAM controller integrato nella CPU; per le istruzioni è costretta ad "inseguire"Intel.
Non puo permettersi invenzioni "fuori", non la cagherà nessuno.

EDIT: ricordavo bene...con Intel è sempre la stessa storia... https://en.wikipedia.org/wiki/XOP_instruction_set

Dieci anni fa non era affatto così. L'era post Sanders Da Ruiz in poi ha creato solo disastri uno dopo l'altro all'azienda facendola sopravvivere con le tecnologie che si portava dietro dagli athlon e athlon 64 precedenti.
In quegli anni anche AMD apportava il suo contributo alle istruzioni nelle architetture X86, poi sempre più giù.

[paolo.oliva2]

Scusate, che l'IPC di BD sia basso, nessuno discute, ma che sia una tragedia, finiamola con le estrapolazioni di parte.
Messo per iscritto:
Ste battute esistevano per il Phenom II?
Benissimo, allora vediamo. Pile nel rapporto IPC per frequenza non sta sotto ad un Phenom II, e per anticipare i soliti bench capati, valutando ALMENO 500MHz in meno dovuti al silicio.
Il Phenom II lottava con SB?
Benissimo, quanto ha incrementato di IPC Intel da SB a tutt'oggi? Con Excavator BD avrebbe incrementato del 20/25% l'IPC.
Ora... Se BD avrebbe ridotto il divario (siamo concordi che Excavator FX non sia stato prodotto causa silicio?) che esisteva tea Phenom II e SB, non capisco perché BD sarebbe un cesso e il Phenom II no, soprattutto valutando che il 45nm è stato il miglior silicio di AMD vs un 32nm che forse è perfino peggiore del 65nm.

Per far notare cosa vuole dire il silicio, il Phenom I sul 65nm era 140W per 2,6GHz e anche meno, il Phenom II era 125W a 3GHz con un 13,5% in più di IPC. Il Phenom II nel 32nm non ha raggiunto lo stesso TDP/prestazioni/frequenze che aveva sul 45nm, e Llano è stato posticipato di ben 6 mesi, con motivazione ufficiale prb IGP, ma visto che i problemi all'IGP non ci sono stati con BD e che l'evoluzione di potenza è stata lineare da Llano a post Trinity, mi sembra abbastanza evidente che se AMD aveva prb, li aveva nel clock della parte X86, visto che dai 4GHz annunciati si è segato più di 1GHz.

Postare in continuazione i millemila core che fa Intel, come per far passare che sia merito dell'architettura, è un'offesa all'intelligenza individuale, sia perché è palese che dipenda dal silicio, e sia perché quando i millemila core li fa Intel, anche se 2GHz, vanno più che bene, mentre un X12 12TH se lo facesse AMD non servirebbe a nulla.

P.S.
Valutando un Carrizo mobile ed un Llano mobile, BD offre (credo) lo stesso IPC, ma con 1/3 del TDP di Llano le stesse potenze. Se L'architettura BD fosse esosa, sarebbe possibile ugualmente che un salto dal 45nm al 28nm conceda più potenza con Carrizo a metà del TDP rispetto alla soluzione K10 di allora? I Carrizo hanno un TDP che il 50% è dedicato all'IGP, i K10 mobile sul 45nm non erano APU, e visto i 3,1 miliardi di transistor (500.000 in più di un 5960X) si prendono tutto il lusso di inserire Huma e compatibilità hardware HSA.Azzo. si parla di un 28nm bulk, non di un 14nm

[tuttodigitale]

scusa, ma hai capito almeno i grafici che hai postato :mbe: ?

o mamma, ma ci sei o ci fai? (scusami per la brutalità, ma quando ci vo ci vo)
Tu hai detto che un x16 da 2,5 GHz non è migliore di un x5650/60, che poi è il quote a cui mi riferivo con i benchmark postati (non è difficile da capire vista che la sequenza quote/risposta ha una sua linearità, che tu fai finta che non esista per motivi sconosciuti) . E postato test che dimostrano l'esatto contrario.


si si,:asd: direi di si
SI, un x16 batte con facilità un x5650 :rolleyes:

Dimmi che senso dire " un x16 da 2,5 GHz non è migliore di un x5650 perchè gli xeon SB, (che non menziono in alcun modo, se non nell'ultimo paragrafo :confused: ) , sono migliori. :muro:

in alcuni casi i dati sono gonfiati anche dal semplice fatto che assistiamo ai limiti della piattaforma g34 (AMD, vedi slide, aveva in programma di cambiarla con l'introduzione di Piledriver)
http://tof.canardpc.com/view/2718a3f4-afdf-4e38-9f4c-d9fa609cb821.jpg


Esempio in SAP abbiamo:
6386se da 2,8GHz vs 6176 da 2,3 GHz, clock+22% perf+15%. Ora con tutta la fantasia che uno ci può mettere, mi pare difficile che PD abbia un ipc inferiore a BD. Sulla carta, perde circa il 10-15% rispetto al solo potenziale della cpu.

Ps per stabilire i rapporti di forza ho fatto un semplice ragionamento: se un fx8350 da 4GHz è circa il 5% più veloce di un i7 2700k (clock +14%), un fx 16 da 3,5GHz dovrebbe essere migliore di un SB octa core da 3GHz (clock +17%).

[george_p]

Scusate, che l'IPC di BD sia basso, nessuno discute, ma che sia una tragedia, finiamola con le estrapolazioni di parte.
Messo per iscritto:
Ste battute esistevano per il Phenom II?
Benissimo, allora vediamo. Pile nel rapporto IPC per frequenza non sta sotto ad un Phenom II, e per anticipare i soliti bench capati, valutando ALMENO 500MHz in meno dovuti al silicio.
Il Phenom II lottava con SB?
Benissimo, quanto ha incrementato di IPC Intel da SB a tutt'oggi? Con Excavator BD avrebbe incrementato del 20/25% l'IPC.
Ora... Se BD avrebbe ridotto il divario (siamo concordi che Excavator FX non sia stato prodotto causa silicio?) che esisteva tea Phenom II e SB, non capisco perché BD sarebbe un cesso e il Phenom II no, soprattutto valutando che il 45nm è stato il miglior silicio di AMD vs un 32nm che forse è perfino peggiore del 65nm.

Per far notare cosa vuole dire il silicio, il Phenom I sul 65nm era 140W per 2,6GHz e anche meno, il Phenom II era 125W a 3GHz con un 13,5% in più di IPC. Il Phenom II nel 32nm non ha raggiunto lo stesso TDP/prestazioni/frequenze che aveva sul 45nm, e Llano è stato posticipato di ben 6 mesi, con motivazione ufficiale prb IGP, ma visto che i problemi all'IGP non ci sono stati con BD e che l'evoluzione di potenza è stata lineare da Llano a post Trinity, mi sembra abbastanza evidente che se AMD aveva prb, li aveva nel clock della parte X86, visto che dai 4GHz annunciati si è segato più di 1GHz.

Postare in continuazione i millemila core che fa Intel, come per far passare che sia merito dell'architettura, è un'offesa all'intelligenza individuale, sia perché è palese che dipenda dal silicio, e sia perché quando i millemila core li fa Intel, anche se 2GHz, vanno più che bene, mentre un X12 12TH se lo facesse AMD non servirebbe a nulla.

P.S.
Valutando un Carrizo mobile ed un Llano mobile, BD offre (credo) lo stesso IPC, ma con 1/3 del TDP di Llano le stesse potenze. Se L'architettura BD fosse esosa, sarebbe possibile ugualmente che un salto dal 45nm al 28nm conceda più potenza con Carrizo a metà del TDP rispetto alla soluzione K10 di allora? I Carrizo hanno un TDP che il 50% è dedicato all'IGP, i K10 mobile sul 45nm non erano APU, e visto i 3,1 miliardi di transistor (500.000 in più di un 5960X) si prendono tutto il lusso di inserire Huma e compatibilità hardware HSA.Azzo. si parla di un 28nm bulk, non di un 14nm

Abbiamo fonti e documenti ufficiali riguardo la scelta di una precedente architettura al posto di quella nuova (BD) per la realizzazione della prima APU AMD aka Llano?
No, perché sinceramente penso che la scelta sia ricaduta sull'architettura vecchia proprio perché la nuova faceva ridere i polli.
Se invece esistono documenti ufficiali dove amd aveva, non capisco nemmeno per quale motivo, scelto da sempre di optare per una precedente architettura allora va bene.
E tutto questo lo sapevano bene dall'inizio.

[AceGranger]

o mamma, ma ci sei o ci fai? (scusami per la brutalità, ma quando ci vo ci vo)
Tu hai detto che un x16 da 2,5 GHz non è migliore di un x5950/60, che poi è il quote a cui mi riferivo con i benchmark postati (non è difficile da capire vista che la sequenza quote/risposta ha una sua linearità, che tu fai finta che non esista per motivi sconosciuti) . E postato test che dimostrano l'esatto contrario.

si, si, un x16 batte con facilità un x5950 :rolleyes:

Dimmi che senso dire " un x16 da 2,5 GHz non è migliore di un x5950 perchè gli xeon SB, (che non menziono in alcun modo, se non nell'ultimo paragrafo :confused: ) , sono migliori. :muro:


quella parte era riferita al primo Bulldozer serie 6200, tu parlavi di PD serie 6300;

"l'X16 è uscito a 2.6 GHz e a malapena stava al passo con i vecchi westmere 6 core X5660-X5650 "
il TOP gamma Bulldozer era 2,6 GHz, mentre il Piledriver 2,8 GHz.

io confrontavo la prima serie BD con Westmere e PD con Sandy Bridge, che l'unico confronto corretto da fare, visto che si parla per entrambi di prima generazione e seconda generazione a 32nm; e il risultato non cambia la differenza architetturale sui 32 nm che è abissale, silicio o non silicio.
non capisco perchè partire da un FX8350 per fare i paragoni quando puoi fare un paragone sicuramente piu preciso partendo dalle prestazioni di un PDX16 a 2,8 e di un SBX8 core 2,7, evidentemente scalare su 8 core o su 16 non è la stessa cosa.... un 3,5 non ce la farebbe a stare dietro allo xeon, manco a piangere, e quella è pure la situazione migliore.

poi oh, pensala un po come vuoi, i bench li hai postati tu e mi pare che parlino chiaro, compresa la tabella riassuntiva in fondo all'articolo.

[Grizlod®]

A parte che fa brutto togliere istruzioni su una generazione sucessive (a meno che siano del tutto obsolete, come le 3dnow+), in genere quelle istruzioni ci mettono diversi anni ad essere implementate in maniera diffusa.
Già il fatto che vengano usato in aree specifiche come progetti Boinc significa che danno un boost prestazionale, e se Amd vuole tornare a competere nel settore server/HPC dove ogni ciclo risparmiato è un ciclo guadagnato(:D ) e dove impenmentazioni ad hoc non sono un problema, è meglio che li mantenga.

In fondo Intel supporta comunque istruzioni avanzate senza avere problemi di transistor, ipc e tdp: Amd deve fare lo stesso.Ben, ma le XOP, sono obsolete. Oggi, nessuno scrive/programma per AMD, a meno che non venga pagata (vedi Cyberlink con le SSE4a). Se poi ci metti che i compilatori intel, quando leggono una stringa che non sia proprietaria, virano su istruzioni meno performanti, FMAC di AMD viene letteralmente eluso (apposta). Non per nulla variano le FMA4/3 da Intel.

Questo accade soprattutto sui server.
Non metto in dubbio che diano il boost, ma in ambito commerciale, non viene favorita AMD...ed oggi più che mai è ciò che serve.

Ad AMD serve tornare sul trono con un processore performante!

[Grizlod®]

Dieci anni fa non era affatto così. L'era post Sanders Da Ruiz in poi ha creato solo disastri uno dopo l'altro all'azienda facendola sopravvivere con le tecnologie che si portava dietro dagli athlon e athlon 64 precedenti.
In quegli anni anche AMD apportava il suo contributo alle istruzioni nelle architetture X86, poi sempre più giù.Si vero... anche oggi le apporterebbe, ma dato che le SH la guardano dall'alto in basso, non se le filano nessuna.
Ciò significa (IMO) che dovrà riprendersi lo scettro prima di poter dire la sua.


Mi auguro che con Zen, tirino fuori il meglio che possano da una CPU. Rumors dicono di aver eliminato tutti i colli di bottiglia dei vari Bus ed aggiuno (io) che tutta la CPU dovrebbe essere stata progettata ad hoc. Il nome in codice Zen, dovrebbe essere derivato da una filosofia della perfezione.

Per rendere l'idea, linko un .pdf guida che riguarda il layout per slot RAM, che i produttori di mainboard per sistemi embedded dovrebbero rispettare sui loro PCB:
http://subscriptions.amd.com/assets/pdf/zen_memory_whitepaper_final.pdf

[tuttodigitale]

quella parte era riferita al primo Bulldozer serie 6200, tu parlavi di PD serie 6300;

"l'X16 è uscito a 2.6 GHz e a malapena stava al passo con i vecchi westmere 6 core X5660-X5650 "
il TOP gamma Bulldozer era 2,6 GHz, mentre il Piledriver 2,8 GHz.
ancora non ci capiamo. Io non parlavo di PD ma di BD (probabilmente avrei fatto meglio a prendere test pre-PD, per eliminare l'equivoco).
su anandtech (e anche nelle slide che ho postato) ci sono riferimenti agli opteron 6200 basati su Bulldozer e al x5650/5670
Ora ti posto cinebench, che dovrebbe essere uno dei bench peggiori visto le caratteristiche di BD:
http://images.anandtech.com/graphs/graph6508/51991.png
ti pare possibile che un bulldozer a 2.6GHz a malapena stava al passo con le cpu x5650, quando la versione da 2,3 GHz, va il 10 % in più, in uno dei casi peggiori? Ma come dicevo poco più su, ci sono test dove la differenza è abissale.

Poi, che ci aspettavamo ben altre prestazioni, è un altro discorso. In molti test, si fatica davvero a credere che c'è un intero nodo di differenza tra la serie 6100 e 6200/6300.

Qui si parla di BD come architettura fallimentare. Intel ha cancellato le evoluzioni di Prescott, quando si rese conto che investire su netbust portava solo a perdite. AMD invece ha continuato a investire su BD, presentando ben 3 revisione dell'architettura, esattamente come ci si attendeva nel 2011 (solo per motivi tecnologici non hanno debuttato sul mercato desktop).


non capisco perchè partire da un FX8350 per fare i paragoni quando puoi fare un paragone sicuramente piu preciso partendo dalle prestazioni di un PDX16 a 2,8
per fare prima. :D


poi oh, pensala un po come vuoi, i bench li hai postati tu e mi pare che parlino chiaro, compresa la tabella riassuntiva in fondo all'articolo.
Ancora più veloce!
praticamente, la tabelle ci dice la differenza di un ipotetico opteron x16 da 3,5GHz e il e5 da 3,1 GHz: 88% le prestazioni, che non sarebbe neppure male considerando il lieve aumento di TDP (no so se questo si traduca in maggiori consumi

[tuttodigitale]

Abbiamo fonti e documenti ufficiali riguardo la scelta di una precedente architettura al posto di quella nuova (BD) per la realizzazione della prima APU AMD aka Llano?
No, perché sinceramente penso che la scelta sia ricaduta sull'architettura vecchia proprio perché la nuova faceva ridere i polli.
un'architettura che fa ridere i polli non la migliori in 6 mesi. AMD ha impiegato un ulteriore anno per fare uscire PD, per un 5-7% di prestazioni in più. Il risultato è che PD è decisamente migliore di k10, e per estensione BD non è inferiore a k10 sui 32nm.


http://thefoundryfiles.com/tag/14nm/

Il fatto che Intel sia riuscita quasi a raddoppiare il numero di transistor con i 32nm, può essere un indice del fatto, che il gate ha dimensioni effettive di 32nm contro i 45nm di GloFo?

[Grizlod®]

Il fatto che Intel sia riuscita quasi a raddoppiare il numero di transistor con i 32nm, può essere un indice del fatto, che il gate ha dimensioni effettive di 32nm contro i 45nm di GloFo?Non escludo che Intel ci sia riuscita, puo darsi che abbia effettivamente il know-how; non prenderei cmq per oro colato i dati che rilascia. Ci vorrebbe una fonte indipendente esterna o almeno qualche cliente (dopo l'apertura delle proprie fabs) che ne verificasse la bontà con dati effettivi.

Personalmente non escludo neppure che i dati siano gonfiati ma che abbia trovato l'uovo di colombo con la sua architettura. Naturalmente è solo un mio pensiero. Certo i suoi sockets, con tutti quei pins, inducono a smentirmi...forse.

[george_p]

un'architettura che fa ridere i polli non la migliori in 6 mesi. AMD ha impiegato un ulteriore anno per fare uscire PD, per un 5-7% di prestazioni in più. Il risultato è che PD è decisamente migliore di k10, e per estensione BD non è inferiore a k10 sui 32nm.


Il fatto che Intel sia riuscita quasi a raddoppiare il numero di transistor con i 32nm, può essere un indice del fatto, che il gate ha dimensioni effettive di 32nm contro i 45nm di GloFo?

Amd ha avuto, per fortuna, culo con il RCM che l'ha salvata da disastro sicuro perché senza quello e senza silicio sarebbe rimasta ferma all'8150 invece che all'8350.

Si va bene, il K10 messo sul 32 nm non rende, ma sul k10 non hanno usato il RCM come per BD 2, altrimenti manco col telescopio ti facevano un trinity, invece per la prima APU hanno messo un K10 proprio perché superiore per IPC al BD che al suo posto ti scordavi frequenze di 3600 mhz :)

[Pat77]

Legendary CPU architect Jim Keller leaves AMD

http://hexus.net/tech/news/cpu/86585-legendary-cpu-architect-jim-keller-leaves-amd/

[george_p]

Anche questo va ;)


jim keller lascia amd, zen è pronto e sarà velocissimo (http://www.bitsandchips.it/9-hardware/6059-jim-keller-lascia-amd-zen-e-pronto-e-sara-velocissimo)

[paolo.oliva2]

Amd ha avuto, per fortuna, culo con il RCM che l'ha salvata da disastro sicuro perché senza quello e senza silicio sarebbe rimasta ferma all'8150 invece che all'8350.

Si va bene, il K10 messo sul 32 nm non rende, ma sul k10 non hanno usato il RCM come per BD 2, altrimenti manco col telescopio ti facevano un trinity, invece per la prima APU hanno messo un K10 proprio perché superiore per IPC al BD che al suo posto ti scordavi frequenze di 3600 mhz :)

Ma siamo sempre li.

L'RCM abbassa il TDP del 32nm, ma lo abbassa perché il 32nm è un cesso o vogliamo continuare all'infinito che il 32nm ha un TDP alto perché l'architettura BD è esosa?

O sono io che non comprendo, allora spiegatemi.
Le frequenze di BD e di Intel sono le stesse, AMD ha un IPC del 50% inferiore, ciò vul dire che le ALU elaborano il 50% in meno e possono avere tutti gli stalli del mondo, ma finché è in stallo, la ALU non elabora e quindi non consuma. Le cache hanno più latenze quindi a paritá silicio DEVE consumare meno.
Se considerassimo efficienza, si dovrebbe interpretare che una architettura riesce a raggiungere potenze più elevate con un numero inferiore di transistor e quindi con consumi inferiori.

Ora faccio 2 domande:

Se un 8350 ha 1,2 miliardi di transistor e va la metà di un 5960X, ma il 5960X ha il doppio abbondante (2,6 miliardi) di transistor, con che giudizio posso dire che BD è meno efficiente? Ammetto che la forza bruta Intel sia da considerarsi un punto di efficienza, concordo.
Ma se 1,2 miliardi di transistor consumano quasi come 2,6 miliardi di transistor di Intel, per quanto scritto sopra, mi sembra che la perdita di efficienza sia nel silicio e non nell'architettura.

Che poi AMD sviluppi features per abbassare il TDP, è ovvio, come è ovvio che se avesse un silicio con 140W per 2,6miliardi di transistor esisterebbe un 8350 X20 a 140W senza necessità di ricorrere all'RMC.

[tuttodigitale]

Anche questo va ;)


jim keller lascia amd, zen è pronto e sarà velocissimo (http://www.bitsandchips.it/9-hardware/6059-jim-keller-lascia-amd-zen-e-pronto-e-sara-velocissimo)
come volevasi dimostrare. L'architettura è bella e terminata. k8 era bello e pronto nel 1999, quindi. Ma per motivi tecnici (silicio) hanno preferito comunque continuare con k7, con il die shrink a 0,13nm (il SOI, secondo test interni fatti da IBM permetteva un +35% di clock in più).

Sarà velocissimo è ancora presto per dirlo. Almeno questo è quello che la storia insegna.
Non è un segreto che bulldozer dovesse uscire con i 45nm. Quello che non sapevo che erano previsti 8, si proprio otto core . Sulla carta, bulldozer doveva consumare pochissimo, non più di esa-core k10, di pari frequenza.

Altre informazioni utili: il SOI 32nm consentiva sulla carta un clock fino al 50% più elevato parità di architettura e consumi.

Ad architettura finita, dicembre 2010, AMD pubblicò diverse slide: in una appariva la cpu Zambesi superiore rispetto al thuban 1100T del 50% in una serie di test specifici come: 3d mark06-cpu score, cinebench r11.5 e pcmark07/media. Peccato che ad un fx8150 siano mancati 1,2-1,4GHz all'appello.

Il confronto con gli opteron magny course è ancora più impietoso: +73% in floating point e +40% con gli int. Imho, AMDfa benissimo a pubblicare solo dati certi.


L'RCM abbassa il TDP del 32nm, ma lo abbassa perché il 32nm è un cesso o vogliamo continuare all'infinito che il 32nm ha un TDP alto perché l'architettura BD è esosa?

Notizia datata 2007, CPU con 8 core bulldozer era prevista per i 45nm! :read: Non doveva consumare un piffero a 4 GHz con i 32nm (le previsioni sulle prestazioni, indicano addirittura una frequenza base di 5GHz, senza RCM ovvio)

[macellatore]

Legendary CPU architect Jim Keller leaves AMD


Vabbè, esistono spiegazioni complicate, e ne esiste una semplice.
Lascio a voi quale scegliere :cool:

[tuttodigitale]

Per me sono solo 3 i motivi:
1) keller non vuole rimanere
2) AMD nell'immediato non ha intenzione di progettare una nuova architettura (aspetta il prodotto ZEN, le prestazioni, e non l'ipc, saranno determinanti per il futuro di AMD)
3) AMD vuole cambiare chief architect.

Intel cambia l'intera squadra di ingegneri da una evoluzione all'altra.
La politica Tick Tock, dopo lo shrink di Nehalem su 32nm, sembra più una manovra di marketing, perchè alla fine ci sono casi in cui il tick ha portato aumenti di ipc più importanti della fase di Tock.
In ultim con il passaggio da Haswell a Broadwell, un semplice die shrink sulla carta, ha migliorato l'ipc praticamente del doppio rispetto al passaggio da Broadwell e Skylake.

[capitan_crasy]

Anche questo va ;)


jim keller lascia amd, zen è pronto e sarà velocissimo (http://www.bitsandchips.it/9-hardware/6059-jim-keller-lascia-amd-zen-e-pronto-e-sara-velocissimo)

http://i.imgur.com/QXzpZhD.gif
:D

[paolo.oliva2]

Io credo che il problema sia basato su certezze che non ci sono.
Di solito i contratti di persone come Keller si basano.su un fisso ed una miriade di bonus in base al venduto e a volte anche con penali se non si arriva ad un determinato target.

Se vogliamo essere realistici, BD non è una soluzione di super core, ma doveva essere una soluzione del minimo TDP a parità di potenza. La critica su BD è per quello che consuma per quello che dà, ma verso Intel, perché con tutto quanto abbiamo di ufficiale, BD è più efficiente per consumo/prestazioni del K10. Se poi è meno efficiente di Intel, quanto lo sarebbe stato il K10? Llano Trinity ne è la prova anche se lo si vuole ignorare.

Keller se se ne va da AMD, per me ci possono essere solamente 2 motivi. O ha capito che non ci sarà un silicio all'altezza e se ne va, o AMD punta a proseguire sull'efficienza di BD a scapito dell'IPC con ovvio scontro di idee con Keller.

Non dimentichiamoci che AMD va bene con gli APU, quello che manca sarebbe un Opteron. Se il silicio nega efficienza, è inutile produrre un procio come un 5960X che Intel lo fa a 140W e con AMD al max sarebbe X6, meglio scroccare ancor più un Excavator

[maxsona]

Mi sembra la prassi di Keller andarsene dopo poco

[george_p]

Ma siamo sempre li.

L'RCM abbassa il TDP del 32nm, ma lo abbassa perché il 32nm è un cesso o vogliamo continuare all'infinito che il 32nm ha un TDP alto perché l'architettura BD è esosa?

O sono io che non comprendo, allora spiegatemi.
Le frequenze di BD e di Intel sono le stesse, AMD ha un IPC del 50% inferiore, ciò vul dire che le ALU elaborano il 50% in meno e possono avere tutti gli stalli del mondo, ma finché è in stallo, la ALU non elabora e quindi non consuma. Le cache hanno più latenze quindi a paritá silicio DEVE consumare meno.
Se considerassimo efficienza, si dovrebbe interpretare che una architettura riesce a raggiungere potenze più elevate con un numero inferiore di transistor e quindi con consumi inferiori.

Ora faccio 2 domande:

Se un 8350 ha 1,2 miliardi di transistor e va la metà di un 5960X, ma il 5960X ha il doppio abbondante (2,6 miliardi) di transistor, con che giudizio posso dire che BD è meno efficiente? Ammetto che la forza bruta Intel sia da considerarsi un punto di efficienza, concordo.
Ma se 1,2 miliardi di transistor consumano quasi come 2,6 miliardi di transistor di Intel, per quanto scritto sopra, mi sembra che la perdita di efficienza sia nel silicio e non nell'architettura.

Che poi AMD sviluppi features per abbassare il TDP, è ovvio, come è ovvio che se avesse un silicio con 140W per 2,6miliardi di transistor esisterebbe un 8350 X20 a 140W senza necessità di ricorrere all'RMC.


Mah, guarda Paolo, si paragona il 32nm e l'architettura Llano affermando che il K10 fa schifo uguale sui 32 nm mentre, e a questo NESSUNO ha ancora risposto, io personalmente (mi) chiedo: Come mai hanno usato Llano sul 32 nm per la prima APU e NON BD?

Poi per far sembrare ancora l'architettura modulare cmt migliore del K10 come efficienza si insiste sul fatto che Trinity e Richland raggiungono frequenze elevate mentre Llano no ... ECCAVOLI!!!!! Se queste evoluzioni di BD godono del RCM e Llano no perché insistere su questo scorretto confronto?
O facciamo i paragoni a parità di silicio e features (RCM) per tutti o non li facciamo, intanto senza RCM BD non ce l'hanno messo manco per sbaglio su APU ma il K10 si. E continuo ad affermare che per questo BD fa ridere i polli ma piangere altri.

E soprattutto Buldozza doveva uscire sui 45 nm? Consumava pochissimo????
Beh, perché non ce l'hanno messo allora visto che i 45 nm erano ottimi? ;)

E ancora, BD a otto cores? O vogliamo dire otto mezzi cores, perché un core intero non condivide la FPU... e in ogni caso consumi a parte anche a frequenze elevate PD con la serie 9xxx a 5 Ghz non spacca le cpu intel. Penso sia molto palese questo per capire le prestazioni di una architettura.





come volevasi dimostrare. L'architettura è bella e terminata. k8 era bello e pronto nel 1999, quindi. Ma per motivi tecnici (silicio) hanno preferito comunque continuare con k7, con il die shrink a 0,13nm (il SOI, secondo test interni fatti da IBM permetteva un +35% di clock in più).

Sarà velocissimo è ancora presto per dirlo. Almeno questo è quello che la storia insegna.
Non è un segreto che bulldozer dovesse uscire con i 45nm. Quello che non sapevo che erano previsti 8, si proprio otto core . Sulla carta, bulldozer doveva consumare pochissimo, non più di esa-core k10, di pari frequenza.

Altre informazioni utili: il SOI 32nm consentiva sulla carta un clock fino al 50% più elevato parità di architettura e consumi.

Ad architettura finita, dicembre 2010, AMD pubblicò diverse slide: in una appariva la cpu Zambesi superiore rispetto al thuban 1100T del 50% in una serie di test specifici come: 3d mark06-cpu score, cinebench r11.5 e pcmark07/media. Peccato che ad un fx8150 siano mancati 1,2-1,4GHz all'appello.

Il confronto con gli opteron magny course è ancora più impietoso: +73% in floating point e +40% con gli int. Imho, AMDfa benissimo a pubblicare solo dati certi.


Notizia datata 2007, CPU con 8 core bulldozer era prevista per i 45nm! :read: Non doveva consumare un piffero a 4 GHz con i 32nm (le previsioni sulle prestazioni, indicano addirittura una frequenza base di 5GHz, senza RCM ovvio)

Ah si, per te i consumi di un BD a "otto cores" per essere bassi (pochissimo come scrivi tu) dovevano essere non più di un esacore K10? Ma naturalmente mi auspico sempre sul 45 nm e non sul 32 ipoteticamente valido.
Punti di vista indubbiamente e a ognuno il suo ma sta di fatto che la realtà dei fatti vede amd cambiare totalmente strada.

E per me Zen non sarà velocissimo fino a che non lo vedo realizzato. Quindi non mi interessa discutere su questo, soprattutto perché di BD sappiamo e ci discuto continuando ad affermare i miei pensieri in base alla realtà dei fatti (inclusa la mancata superiorità a parità di "cores" con intel) e non certo sulle slide di amd e sulla "carta".

Dal prossimo anno formulerò i miei pensieri su Zen.

[george_p]

http://i.imgur.com/QXzpZhD.gif
:D

Ahahah Capitano, fortuna non divento isterico facilmente per ste cose :D
Come l'autore anche io sono fiducioso. Mi auguro solo di rivederlo tra qualche anno in amd a Keller. Penso se lo tengano ben stretto se ha lavorato bene.

[tuttodigitale]

Se vogliamo essere realistici, BD non è una soluzione di super cor
Dico di più, assodato il fatto che un FX8150 doveva avere 4,8-5GHz di base e che i 32 nm garantiva un corposo "fino +50% di frequenza a parità di consumi", si può risalire alle frequenze che doveva avere bulldozer octa-core a 45nn.


Lo sai cosa scopriamo? Che su 45nm AMD pensava di riuscire a far girare un SAMPLE bulldozer ad almeno 3,3GHz (quel fino al50% di frequenze in più, pò essere rigirato in: i 45nm hanno una frequenza pari ad almeno il 66% dei 32nm). E queste non sono previsioni, campate in aria, visto che avevano già prodotto ES bulldozer su 45nm.
Quello che sembra chiaro che un modulo BD, almeno su 45nm, consuma quanto se non meno di due core Nehalem, alla stessa frequenza.

Infatti nelle retroscena delle dimissioni di Meyer, si mormora che Thuban sia stato arbitrariamente ritardato di 9 mesi (si vede che il CEO era soddisfatto dell'andamento delle vendite delle soluzioni quad core) ed è questo in ultimo che non avrebbe permesso a BD di debuttare su 45nm.


Poi per far sembrare ancora l'architettura modulare cmt migliore del K10 come efficienza si insiste sul fatto che Trinity e Richland raggiungono frequenze elevate mentre Llano no ... ECCAVOLI!!!!! Se queste evoluzioni di BD godono del RCM e Llano no perché insistere su questo scorretto confronto?
Perchè RCM no ti dà il 35-55% di clock in più (questa è la differenza di clock tra le apu llano e Richland), al più solo un 10%.
Ora che sai dati (postati nel dettaglio da me in questo stesso thread) perchè insisti sul fatto che i vantaggi di BD siano dovuti al RCM, quando contribuisce solo per il 10%, nell'aumento di clock.

PS mi dici cosa c'entra il CMT? Il CMT con core meno ampi è migliore solo perchè in un codice fortemente threaded si aumenta l'efficienza computazionale. Pensa che ci sono processori che hanno una sola alu per core che si basano proprio su questo principio e destinati al mercato HPC. Quindi il CMT ha indiscutibili punti di vantaggio. Non meno importante la possibilità concreta di avere un octa-core su 45nm.


E soprattutto Buldozza doveva uscire sui 45 nm? Consumava pochissimo????
Beh, perché non ce l'hanno messo allora visto che i 45 nm erano ottimi? ;)
Problemi di tempistiche a quanto pare. Meyer avrebbe deliberatamente ritardato il rilascio di Thuban, annientando di fatto il progetto bulldozer. (

Ah si, per te i consumi di un BD a "otto cores" per essere bassi (pochissimo come scrivi tu) dovevano essere non più di un esacore K10? Ma naturalmente mi auspico sempre sul 45 nm e non sul 32 ipoteticamente valido.

ovvio che si parla di 45nm.
Dalle slide, che ripeto riferiscono prestazioni superiori del 50%, in test specifici, e non un generico "fino a", si risale al fatto che la frequenza di clock, di base era compresa tra i 4,8 e i 5GHz.

Nella peggiore delle ipotesi bulldozer a 45nm doveva girare a 3,3 GHz (ma più probabile 3,6)

In pratica, si ripete le stesse cose: i 32nm non sono migliori dei 45nm, se non grazie all'utilizzo del RCM, che però è una tecnologia indipendente dal silicio.

@per il capitano andrebbe corretto questo passaggio, in prima pagina
Il progetto originario del primo Bulldozer prevedeva una CPU a 4/6core sul processo produttivo a 45nm SOI con supporto alle SSE5.
http://pcper.com/images/reviews/436/Slide113.jpg
slide del 2007

Ancora convinti che 3,6 GHz e 125W per un octa-core siano giusti per il 32nm, quando AMD prevedeva di avere simili valori con i 45nm?

[george_p]

@ tuttodigitale: Ma scusa, scrivo proprio in base ai tuoi dati, che prendo per buoni. Sei tu a scrivere nei post precedenti che le migliorie di PD sono esclusivamente dovute all'introduzione di RCM mica io. E quindi il 32 nm non è migliorato niente in base a questo ragionamento. Ne abbiam discusso settimana passata mi pare, no?

Ma poi, come fai a dire che Llano non avrebbe lo stesso boost? Visto soprattutto che non è uscito sui 32 nm con RCM. Questo non lo capisco proprio e perdonami ma non posso prendere per buono tutti i dati che riporti.

E ripeto, rispondi al perché come mai BD su apu è stato sostituito da Llano, forse perché non sarebbe arrivato nemmeno lui ai 3 Ghz?
Appunto.


Infine, consumi a parte, abbiamo comunque i vari FX della serie 9xxx che arrivano già a frequenze vicine ai 5 Ghz, e sono pure versioni migliori dei primi BD visto che appartengono a PD ...ma anche consumando 125 w (la metà quasi rispetto ai 220) come prestazioni non sono mica tutta quella potenza menzionata dalle slide cui ti riferisci.... beh certo viaggi a 4.7 ghz... in cinebench sono simili in MT a Ivi Bridge e vengono superati in ST, non certo a parità di frequenza visto che l'amd va a 33% in più rispetto al concorrente. In altri test non c'è proprio storia e mi spiace.

http://www.anandtech.com/bench/product/1289?vs=1330



Ancora convinti che 3,6 GHz e 125W per un octa-core siano giusti per il 32nm, quando AMD prevedeva di avere simili valori con i 45nm?

Un octa-core che va quanto un esacore non fa proprio una bella figura soprattutto a quella frequenza... dai, hai il 33% di core in più... che poi sappiamo già non essere core al 100% (FPU condivisa)

[capitan_crasy]

@per il capitano andrebbe corretto questo passaggio, in prima pagina

http://pcper.com/images/reviews/436/Slide113.jpg
slide del 2007

Ancora convinti che 3,6 GHz e 125W per un octa-core siano giusti per il 32nm, quando AMD prevedeva di avere simili valori con i 45nm?

Non riesco più a trovare la discussione (dovrebbe essere la prima su "aspettando il K10" non aperta da me che allora si chiamava erroneamente K8L), ma i primissimi rumors su BD dati dalla stessa AMD parlavano di una struttura similare a quella del K10 (niente architettura clustered core) appunto a 4/6 core costruito sui 45nm SOI (allora si attendevano i primi K10 a 65nm).
Thuban eredito il processo produttivo (e il numero di core) del primissimo BD ovvero i 45nm low-k mettendo la parola fine sul tanto citato e solo teorizzato Super K10, che ricordo era un architettura di base K10 ma con alcune possibili caratteristiche dei primissimi BD.
Quella slide era già nell'epoca del cambio di rotta ovvero dal poco citato e mai realizzato progetto "hydra" (il quale poi prese il nome di "Orochi") ovvero il primo disegno di una CPU 8 core nativa AMD.

[sgrinfia]

Non riesco più a trovare la discussione (dovrebbe essere la prima su "aspettando il K10" non aperta da me che allora si chiamava erroneamente K8L), ma i primissimi rumors su BD dati dalla stessa AMD parlavano di una struttura similare a quella del K10 (niente architettura clustered core) appunto a 4/6 core costruito sui 45nm SOI (allora si attendevano i primi K10 a 65nm).
Thuban eredito il processo produttivo (e il numero di core) del primissimo BD ovvero i 45nm low-k mettendo la parola fine sul tanto citato e solo teorizzato Super K10, che ricordo era un architettura di base K10 ma con alcune possibili caratteristiche dei primissimi BD.
Quella slide era già nell'epoca del cambio di rotta ovvero dal poco citato e mai realizzato progetto "hydra" (il quale poi prese il nome di "Orochi") ovvero il primo disegno di una CPU 8 core nativa AMD.

Sei sicuro? del( K8L), se ne parlava già nel 2006 :confused:

[tuttodigitale]

@ tuttodigitale: Ma scusa, scrivo proprio in base ai tuoi dati, che prendo per buoni. Sei tu a scrivere nei post precedenti che le migliorie di PD sono quasi esclusivamente dovute all'introduzione di RCM mica io. E quindi il 32 nm non è migliorato niente in base a questo ragionamento. Ne abbiam discusso settimana passata mi pare, no?
*fixed

Ma poi, come fai a dire che Llano non avrebbe lo stesso boost? Visto soprattutto che non è uscito sui 32 nm con RCM.
ma il boost è del 4/3,6 GHz, 11%. Mica n-mila.

Questo non lo capisco proprio e perdonami ma non posso prendere per buono tutti i dati che riporti.
che la velocità di clock da llano a richland sia aumentato del 35-55%, in base al TDP, non li dico io, ma le schede tecniche delle cpu.
Quindi anche ammettendo che RCM, migliori del 11% le frequenze anche su k10 (e non ho motivo per pensare il contrario) la differenza è comunque notevole +20-40% di clock in più.

Un octa-core che va quanto un esacore non fa proprio una bella figura soprattutto a quella frequenza... dai, hai il 33% di core in più... che poi sappiamo già non essere core al 100% (FPU condivisa)
ma anche un +10 in più nel MT a parità di watt, vuol dire aumentare comunque l'efficienza, anche rispetto a Nehalem. Nessuno ha mai detto che è immensamente migliore di k10. Neppure Richland lo è nei confronti di llano e c'è il RCM che lo aiuta.

[george_p]

*fixed


ma il boost è del 4/3,6 GHz, 11%. Mica n-mila.


che la velocità di clock da llano a richland sia aumentato del 35-55%, in base al TDP, non li dico io, ma le schede tecniche delle cpu.
Quindi anche ammettendo che RCM, migliori del 11% le frequenze anche su k10 (e non ho motivo per pensare il contrario) la differenza è comunque notevole +20-40% di clock in più.


ma anche un +10 in più nel MT a parità di watt, vuol dire aumentare comunque l'efficienza, anche rispetto a Nehalem. Nessuno ha mai detto che è immensamente migliore di k10. Neppure Richland lo è nei confronti di llano e c'è il RCM che lo aiuta.

Scusa, ma ti riporto, evidenziandole, le vostre stesse frasi, tralasciando la frase di paolo dove aumenti l'ipc aggiungendo una pipeline.

Riformulo la mia domanda precedente. Perché con llano lo stesso procedimento non sarebbe possibile?
Con BD aumenti ipc e frequenza abbassandone il tdp mentre con Llano non lo puoi fare, perché? Lo dici tu o amd?
E' ovvio che amd continua(va) a investire su BD piuttosto che sul K10, è questo il vero motivo per il quale K10 è stato solo un rimpiazzo veloce e d'emergenza.

E non hai nemmeno risposto alla mia ennesima domanda. Perché hanno usato K10, visto che è così scarso a salire in frequenza, piuttosto che BD nella prima APU? (Beh ti ho aiutato)

Inoltre, hai aggiunto "quasi" alla mia frase
Sei tu a scrivere nei post precedenti che le migliorie di PD sono esclusivamente dovute all'introduzione di RCM mica io
Oltre quel quasi cosa ha permesso le migliorie se non il silicio?



Ma puoi anche valutare Zambesi che è uscito con Llano, il K10 starebbe sempre sotto.
Pile non ha migliorato il silicio, è stato l'RCM che ha permesso un aumento frequenze e una diminuzione TDP nel moduo inserendo una pipeline ed aumentando l'IPC. Gli ultimi 8370 derivano da Warsavia ed è lo stesso PP dei Piledriver, soltanto con un RCM ottimizzato per 4GHz. È sempre il B2f da 4 anni.



Come ha detto Paolo è stato il RCM, a permettere a PD di girare a 4GHz:

come puoi vedere il RCM, ha permesso di aumentare l'efficienza a 3,6GHz (frequenza del 8150) del 20-25%, che si traduce in una riduzione del TDP da 125 a 100 W. In pratica, come ha detto Paolo, il 32nm di PD non è migliore dei 32nm usati da BD, almeno che non si dimostri che un FX8150 cosnumi a 4 GHz 160 o più W.

[paolo.oliva2]

George_P

Io la tempistica se ricordo bene è stata che prima è uscito Llano X4 APU e poi 6 mesi fopo Zambesi FX. Poi è uscito Trinity Piledriver e poi l'FX Piledriver.
Llano era stato presentato molto prima e mi ricordo che era stato accolto con "WAW" e che il TH ci aveva ricamato sopra.
Ma Llano era slittato di 6 mesi, e nonostante questo è uscito 6 mesi prima di Zambesi. Mi pare ovvio che un APU in chiave BD a quel punto doveva essere progettata 1 anno prima di Zambesi... Come fai a girare tutto dicendo che AMD ha fatto uscire Llano altrimenti BD APU avrebbe fatto schifo?
iComunque basta fare 2 proporzioni. Llano era 100W, 50W per la parte X86 e 50W per la parte IGP. In quei 50W, ci sono 4 core K10 con 512KB di L2 (2MB totali) e niente L3. Zambesi 8150 era 125W 4M o X8, NIENTE RCM, e se dividi a metà, in 65W ci sono 2M o X4, con il doppio di L2 di un Llano, 4MB di L3 che in Llano sono assenti, frequenze def del 20% superiori e turbo del 33% superiori. Insomma, a parità di silicio BD offre un IPC/frequenza = potenza superiore al K10, diverso dal K10 sul 45nm vs BD sul 32nm, come pure confermato da BD prototipo sul 45nm.
Nella logica di produzione di un procio, si deve trovare il bilanciamento idoneo tra IPC e frequenza per la resa migliore, e di qui, in base al TDP, n core nativi a die.
Kaveri che ha fatto? Ha aumentato l'IPC, e di conseguenza è aumentato il TDP, e per restare dentro ad un TDP prefissato, si sono dovute diminuire le frequenze. (Qui si continua a dire che un IPC superiore diminuirebbe le frequenze a parità di potenza e quindi i consumi, leggenda metropolitana, visto che Kaveri smentisce in toto).
Con l'RCM si è abbassato il TDP e questo ha consentito di aumentare l'IPC e di un 11,11% le frequenze def. Steamroller FX e tantomeno Excavator non potevano entrare in produzione chiave FX 32nm perché non ci sarebbe stato il margine di TDP, con la soluzione che o si abbassavano le frequenze a parità di core o si diminuiva il numero max di core.
Il discorso SMT o CMT, se lo vediamo in quest'ottica,ha poco a che vedere con efficienza, ma o fai un CMT con un determinato IPC al limite X6, o fai un SMT ma non più di X4, ma in ogni caso la potenza massima MT sarebbe simile. Se il silicio ha questi limiti, non è che se fai SMT ti viene un 5960X.

--------------------

I miei dubbi sono che un CMT ora come ora ha 5 anni di sviluppo e un'efficienza ben superiore rispetto alla prima uscita Zambesi. Un procio SMT sarebbe acerbo, e se valutiamo i pro e i contro tra CMT e SMT, per me non è ben chiaro quale sia più efficiente, perché l'SMT di Intel è certamente più efficiente ma lo è anche perché poggia su un silicio nettamente più efficiente di quello GF... Poi mi sembra scontato che AMD non butti via i soldi, o che ha tecnici incapaci, insomma, se il CMT portasse meno vantaggi, nessuno lo implementerebbe.
Ora ad un CMT rodato per 5 anni, razionalmente, io non penso che AMD possa contrapporre un SMT che abbia la stessa efficienza, inteso che possa arrivare alla stessa potenza complessiva massima die a parità di TDP. Nulla da dire che offrirebbe più forza bruta, ma dubito una potenza MT uguale.
Il punto di Keller, se è uscito, io lo vedo in queste righe.

[shellx]

cut..

Keller se se ne va da AMD, per me ci possono essere solamente 2 motivi. O ha capito che non ci sarà un silicio all'altezza e se ne va, o AMD punta a proseguire sull'efficienza di BD a scapito dell'IPC con ovvio scontro di idee con Keller.

Praticamente gli unici due motivi che io ho scartato a priori. Soprattutto il secondo: si come no... amd paga un ingegnere di architetture per tutto il progetto, spreca risorse e denaro per poi alla fine decidere di accantonare zen, fanculizzare keller, per proseguire e contintuare con un vecchio, impacciato e inefficiente progetto in ambito desktop, neppure Intel potrebbe permettersi cambi di rotta cosi drastici dal punto di vista di spreco di denaro e risorse.

Tra l'altro i tuoi non mi sembrano neppure motivi positivi, non per altro, speriamo che non sia cosi e che hai torto marcio, perchè se uno solo di quei due motivi è reale, dal prossimo anno ci toccherà usare cpu Intel perchè non ci sarà altra scelta di marchio in ambito desktop..

[davo30]

Praticamente gli unici due motivi che io ho scartato a priori. Soprattutto il secondo: si come no... amd paga un ingegnere di architetture per tutto il progetto, spreca risorse e denaro per poi alla fine decidere di accantonare zen, fanculizzare keller, per proseguire e contintuare con un vecchio, impacciato e inefficiente progetto in ambito desktop, neppure Intel potrebbe permettersi cambi di rotta cosi drastici dal punto di vista di spreco di denaro e risorse.

Tra l'altro i tuoi non mi sembrano neppure motivi positivi, non per altro, speriamo che non sia cosi e che hai torto marcio, perchè se uno solo di quei due motivi è reale, dal prossimo anno ci toccherà usare cpu Intel perchè non ci sarà altra scelta di marchio in ambito desktop..

Sarò ormai disilluso, ma penso che Keller se ne sia andato perchè, brutalmente, ha capito che Zen non vedrà luce e ha quindi deciso di impiegare meglio il suo tempo, invece di stare a litigare con una fonderia che spara processi produttivi a caso (oggi ti do i 22nm SOI, anzi no 14XM, anzi no 14FF LPE, anzi no i 20SHP). Gia solo il fatto che AMD abbia dichiarato "2016" come data di uscita, e i qualche rumor da già inizio 2017, mi fa un po prudere il naso....

[shellx]

Sarò ormai disilluso, ma penso che Keller se ne sia andato perchè, brutalmente, ha capito che Zen non vedrà luce e ha quindi deciso di impiegare meglio il suo tempo, invece di stare a litigare con una fonderia che spara processi produttivi a caso (oggi ti do i 22nm SOI, anzi no 14XM, anzi no 14FF LPE, anzi no i 20SHP). Gia solo il fatto che AMD abbia dichiarato "2016" come data di uscita, e i qualche rumor da già inizio 2017, mi fa un po prudere il naso....

Buu...io in merito sono un pò più ottimista, o meglio dire, non accetto di credere una cosa del genere, per i motivi che ho spiegato nel post precedente. Mi piace invece credere che è andato via perchè il suo lavoro come progettista architetturale è svolto a termine (il progetto disegnato dell'architettura). Tutto il resto che viene dopo non è più di sua competenza, adesso sta ad altri ingegneri portare su wafer quello che keller ha disegnato al computer, implementare quindi poi l'architettura nel silicio, avere quest'ultimo di un calibro idoneo, i vari test di resistenza e stabilità elettrica e di clock, e tutto il resto dei processi che van fatti per portare una cpu a prodotto finito.
Dove hai letto inizi 2017 ?

[tuttodigitale]

ho detto che con RCM hanno aumentato l'efficienza del 20-25% a parità di clock, che è cosa ben diversa nel dire che ha aumentato la frequenza del 25% a parità di consumo.
La frequenza di clock da fx8150 a fx8350, è passata da 3,6GHz a 4 GHz, +11%.

Ho aggiunto quel quasi perchè penso che un minimo di miglioramento il silicio lo abbia ricevuto, se non altro per le rese (Paolo che ha preso il fx8150 all'uscito ha avuto risultati scarsi in OC). Ma visto che tra RCM e miglioramenti del silicio hanno migliorato le frequenze complessivamene solo del 11%, perchè tu pensi che llano possa chiudere il gap ENORME, a livello di frequenze (dal 35 al 55%), solo con l'impiego di RCM?



E non hai nemmeno risposto alla mia ennesima domanda. Perché hanno usato K10, visto che è così scarso a salire in frequenza, piuttosto che BD nella prima APU? (Beh ti ho aiutato)

che k10 sia scarso a salire in frequenza sui 32nm è un dato di fatto, non un opinione. Le prove di OC parlano di 3,6GHz raggiunti a fatica, con consumi esagerati (stimati 180W per la sola apu). Confronti questi numeri con FX8150 (che non ha RCM, ma in compenso ha il doppio dei core) e trova le differenze...



Riformulo la mia domanda precedente. Perché con llano lo stesso procedimento non sarebbe possibile?
Con BD aumenti ipc e frequenza abbassandone il tdp mentre con Llano non lo puoi fare, perché? Lo dici tu o amd?
le frequenze di BD un k10 se le sogna a parità di silicio e core. llano x2 a 3,6GHz consumerebbe circa 360W.
In base alle informazioni che abbiamo, si ha la quasi certezza bulldozer octa-core su 45nm potesse superare i 3,3GHz di base (AMD le previsioni sui 32nm le avrà fatte basandosi anche sui risultati di BD su 45nm o no?).
Un calcolo sommario ci dice che a parità di frequenza 2 core k10 consumano ALMENO il 33% in più di un modulo BD. E un dual core Nehalem ALMENO il doppio di un modulo BD. Ergo un FX8150 non doveva consumare più di un i7 2700k.
Un core BD nel ST, avrebbe avuto un amplissimo margine termico. Sono quasi sicuro che poteva raggiungere i 4,6GHz in turbo core (ricordiamo che k10 si ferma comunque ad un importante 3,8GHz su 3 core).


E' ovvio che amd continua(va) a investire su BD piuttosto che sul K10, è questo il vero motivo per il quale K10 è stato solo un rimpiazzo veloce e d'emergenza.
OMG, guarda che llano sarebbe basato su k10 lo si sapeva già nel 2009. Forse con llano non volevano mettere troppa carne a fuoco.
Poi il "rimpiazzo" non è stato veloce, visto che a quanto pare non è stato neppure uno scherzo, con i suoi 7 mesi di ritardi..
http://www.xbitlabs.com/news/cpu/display/20101105174003_AMD_s_Llano_Production_to_Initiate_in_July_2011.html

pubblico un'altra slide e così chiudiamo una volta per tutte la questione, (spero):
http://www.hwupgrade.it/articoli/cpu/2376/llano_1.jpg
questa slide si riferisce a llano. Notare quel >3GHz. Non si sono mai visti.
e infine 1,3 V quando llano ha un vcore di 1,41 V: solo questo dato porta llano a consumare quasi il 20% in più. Ovviamente a 3 GHz AMD prevedeva tensioni inferiori a 1,3V.

[celsius100]

Io credo che il problema sia basato su certezze che non ci sono.
Di solito i contratti di persone come Keller si basano.su un fisso ed una miriade di bonus in base al venduto e a volte anche con penali se non si arriva ad un determinato target.

Se vogliamo essere realistici, BD non è una soluzione di super core, ma doveva essere una soluzione del minimo TDP a parità di potenza. La critica su BD è per quello che consuma per quello che dà, ma verso Intel, perché con tutto quanto abbiamo di ufficiale, BD è più efficiente per consumo/prestazioni del K10. Se poi è meno efficiente di Intel, quanto lo sarebbe stato il K10? Llano Trinity ne è la prova anche se lo si vuole ignorare.

Keller se se ne va da AMD, per me ci possono essere solamente 2 motivi. O ha capito che non ci sarà un silicio all'altezza e se ne va, o AMD punta a proseguire sull'efficienza di BD a scapito dell'IPC con ovvio scontro di idee con Keller.

Non dimentichiamoci che AMD va bene con gli APU, quello che manca sarebbe un Opteron. Se il silicio nega efficienza, è inutile produrre un procio come un 5960X che Intel lo fa a 140W e con AMD al max sarebbe X6, meglio scroccare ancor più un Excavator
Keller ha sempre fatto così
finito il lavoro se ne va
tanto ad affinare l'architettura e fare die-srhink ci sono altri
x lo scontro di idee, se fosse stato cosi sarebbe andato via l'anno scorso, ormai Zen e fatto e finito
poi che possano avere problemi con GF e scontato, ma Papermaster sa benissimo che ci sono i 22nm ex IBM che è impossibile abbiamo gia rovinato quelli di GF, e cmq Samsung e TSMC nn sono messe male col finfet

[davo30]

Buu...io in merito sono un pò più ottimista, o meglio dire, non accetto di credere una cosa del genere, per i motivi che ho spiegato nel post precedente. Mi piace invece credere che è andato via perchè il suo lavoro come progettista architetturale è svolto a termine (il progetto disegnato dell'architettura). Tutto il resto che viene dopo non è più di sua competenza, adesso sta ad altri ingegneri portare su wafer quello che keller ha disegnato al computer, implementare quindi poi l'architettura nel silicio, avere quest'ultimo di un calibro idoneo, i vari test di resistenza e stabilità elettrica e di clock, e tutto il resto dei processi che van fatti per portare una cpu a prodotto finito.
Dove hai letto inizi 2017 ?

Mi sembra su Wccftech o su Novellatommaso2000 recentemente.

[shellx]

Mi sembra su Wccftech o su Novellatommaso2000 recentemente.

Non ho trovato da nessuna parte sta notizia. Non è che per caso ti stai confondendo con Cannonlake ?
http://hardware.hdblog.it/2015/02/05/Intel-Cannonlake-le-CPU-a-10nm-potrebbero-essere-rinviate/

Di Zen l'unico rinvio che trovo parla di fine 2016
http://hardware.hdblog.it/2015/09/12/amd-zen-ritardo-2016/

[paolo.oliva2]

Praticamente gli unici due motivi che io ho scartato a priori. Soprattutto il secondo: si come no... amd paga un ingegnere di architetture per tutto il progetto, spreca risorse e denaro per poi alla fine decidere di accantonare zen, fanculizzare keller, per proseguire e contintuare con un vecchio, impacciato e inefficiente progetto in ambito desktop, neppure Intel potrebbe permettersi cambi di rotta cosi drastici dal punto di vista di spreco di denaro e risorse.

Tra l'altro i tuoi non mi sembrano neppure motivi positivi, non per altro, speriamo che non sia cosi e che hai torto marcio, perchè se uno solo di quei due motivi è reale, dal prossimo anno ci toccherà usare cpu Intel perchè non ci sarà altra scelta di marchio in ambito desktop..

Zen è già in scaletta, io mica ho detto che non ci sarà Zen, ma forse non Zen che voleva Keller.
Il problema non è architetturale a mio avviso, ma di silicio. Un silicio buono aumenterebbe un 8350 di un 30/40% a parità di core (tra IPC +20/25% e una frequenza di 4,5GHz def e senza aumentare i core). Senza silicio, bene che vada ci ritroveremo un 6700k marcato AMD, a parole la manna di quelli che giocano, a fatti che acquisterebbero ugualmente Intel perché calerebbe di prezzo.

Guarda, un'architettura, che sia CMT o SMT, per me deve avere un numero di TH almeno 12 ed uguagliarsi in MT. Io non voglio un i7 X4+4 marcato AMD, vorrei un AMD fascia i7 socket 2011, che sia CMT, SMT, Pluto, Paperino, non mi importa, ma voglio un procio con i contro-fiocchi.
Mi voglio divertire, voglio una mobo che sfrutti al 101% il procio, che non mi faccia impazzire con BIOS ciofeca e che il procio sia aperto e disponibili asino all'OC. Col 5960X il piatto è servito, con AMD vedremo, ma permetti che nel caso di silicio buono io abbia più garanzie su un FX EX-Zen che in un Zen SMT al buio?
Se questo poi viene interpretato come anti-Intel e/o anti SMT e difesa ad oltranza CMT, a me non sembra, ma io, come scritto sopra, andrebbe più che bene un 8350 potenziato del 35/40% e se poi da X8 passasse a X10/X12, cacchio, ci farei la firma.

[george_p]

@tuttodigitale: con la quasi certezza non si ha certezza ugualmente quindi son tutti dati speculativi senza prove di laboratorio.
K10 può non arrivare a quelle frequenze come dici tu, anche perché non è ottimizzato ed è una architettura, penso io, ormai strarodata e usata al limite, ma anche avesse raggiunto i 3.300 col RCM il culo a BD glielo faceva lo stesso.

Ok che Llano era già previsto nel 2009, non ricordo assolutamente nulla delle slide.
Tanto un BD senza RCM, come per Llano, non avrebbe fatto proprio niente di meglio e anzi.

Ma mica mi è chiaro il fatto che per BD con RCM l'efficienza migliora ABBASSANDO il tdp mentre invece su Llano non lo abbasserebbe... guarda che i calcoli di cui scrivi son solo teorici e basati su slide amd (se


llano x2 a 3,6GHz consumerebbe circa 360W.
Ascolta, le prove fatte in OC di Llano ovvio che su quel 32 nm schifoso portano a consumi alti... il mio discorso se leggi bene ciò che scrivo non è su un llano già realizzato ma sul fatto che tu dai per scontato che un Llano con RCM non abbasserebbe il tdp come successo per BD.

Continui a giocare con le parole a tuo vantaggio, cioè confrontando Llano senza RCM contro un BD (PD in realtà) con RCM.
Ovvio che Llano in OC consumi così tanto su quel pessimo silicio ed è ovvio che un Llano X 2 consumi il doppio, ma a chi interessa.

BD ha avuto solo il culo di avere l'RCM e K10 no, se no a quest'ora con ancora l'FX 8150 non si parlava di quanto BD salga più in frequenza rispetto a un K10 senza RCM.

[george_p]

Praticamente gli unici due motivi che io ho scartato a priori. Soprattutto il secondo: si come no... amd paga un ingegnere di architetture per tutto il progetto, spreca risorse e denaro per poi alla fine decidere di accantonare zen, fanculizzare keller, per proseguire e contintuare con un vecchio, impacciato e inefficiente progetto in ambito desktop, neppure Intel potrebbe permettersi cambi di rotta cosi drastici dal punto di vista di spreco di denaro e risorse.

Tra l'altro i tuoi non mi sembrano neppure motivi positivi, non per altro, speriamo che non sia cosi e che hai torto marcio, perchè se uno solo di quei due motivi è reale, dal prossimo anno ci toccherà usare cpu Intel perchè non ci sarà altra scelta di marchio in ambito desktop..

Quoto.
Ma quante seghe mentali però eh :D
Non sappiamo un cazzo di tutto quello che ci sta dietro e ci facciamo tutto un film, naturalmente sempre in negativo eh tipico italiano, su cui incazzarci e piangere e lamentarci.

Per i fazzoletti aspetterei almeno l'uscita di Zen ;)

[sgrinfia]

Quoto.
Ma quante seghe mentali però eh :D
Non sappiamo un cazzo di tutto quello che ci sta dietro e ci facciamo tutto un film, naturalmente sempre in negativo eh tipico italiano, su cui incazzarci e piangere e lamentarci.

Per i fazzoletti aspetterei almeno l'uscita di Zen ;)

LA STORIA INFINITA :asd: :asd:

[tuttodigitale]

Ascolta, le prove fatte in OC di Llano ovvio che su quel 32 nm schifoso portano a consumi alti... il mio discorso se leggi bene ciò che scrivo non è su un llano già realizzato ma sul fatto che tu dai per scontato che un Llano con RCM non abbasserebbe il tdp come successo per BD.
ma chi ha detto che non avrebbe migliorato.
L'abbassamento del TDP l'hanno utilizzato per aumentare il clock del 11%. Le differenze di clock sono tali (dal 35 al 55% in più) che anche un +11% per k10, danno alle architetture BD un netto vantaggio a livello di clock. Che poi un apu a 3,3 GHz sia comunque competitiva su BD a 4,1 GHz a parità di core, non l'ho mai messo in discussione.
Non mi stancherò mai di ripeterlo (siete avvisati) che il problema di AMD non erano le prestazioni nel MT, visto che era alla pari con Intel.

Ora non voglio essere polemico, ma basta farsi un conto abbastanza elementare per rendersi conto che BD (la prima versione) potenzialmente va più di k10 nel ST.

Facciamo finta che una cpu esacore k10 e una cpu octa-core BD vadano uguali nel MT, che poi non è tanto falso.
1) k10 ha un numero maggiore di core. Ogni core k10 consuma mediamente il 33% di un core BD. Con un solo core attivo, k10 avrà minor margine termico. Possiamo quantificare questo vantaggio in circa 6W.

2)BD è in grado, quasi di azzerare il consumo degli altri core al minimo. Mentre in k10, la tensione di alimentazione dei core "dormienti" è pari a quella di un core attivo. Dopo un rapido calcolo, si scopre, che il consumo è superiore di circa 20W. In sostanza, quei core in più raddoppiano di fatto il consumo energetico.

in pratica 1) e 2) permettono a BD di risparmiare circa 25W: ma aspetta un attimo! un FX8150 a 4GHz non consumava circa 25W in più secondo tom's?
Praticamente AMD BD guadagna 11%

3) Le prestazioni di un core BD decadono quando viene utilizzato il secondo core. Sappiamo che il CMT di BD offre prestazioni pari al 73% di un dual core CMP. Ergo un core rende l'86%, che si traducono in prestazioni superiori del 16%.

4) includiamo anche una piccola perdita nell'efficienza dello scaling del 5% tra 6 e 8 core.

Risultato. Se cpu BD 8 core va forte nel MT quanto una soluzione esacore k10:
Le prestazioni per core sono pari a circa, per la 4), al 26%.

Ma nel ST per la 1) 2) e la 3), le prestazioni salgono del 29%.

Questo significa che un octa-core che è pari ad una soluzione esa-core nel MT, può essere più veloce della soluzione con meno core nel ST...

Ovviamente l'analisi non è completa, ma di suo ricordiamo che l'architettura FO4, 17 vs 22, può girare a frequenze del 25% più elevate. In pratica BD odvrebbe avere un andamento più favorevole nel rapporto (delta frequenza)/(delta consumo)

infatti sempre nelle slide di AMD, si parlavano di prestazioni nel ST le più elevate tra le architetture in circolazione: Conroe e k10.

Ascolta, le prove fatte in OC di Llano ovvio che su quel 32 nm schifoso portano a consumi alti... .

Guarda che llano e Zambesi hanno subito lo stesso tragico destino. Entrambi sono stati posticipati di 7mesi, e sono usciti a poco distanza uno dall'altro. Questo è indice del fatto che AMD ha lavorato duramente per raggiungere quelle (scarse) prestazioni su k10. Anche perchè il lavoro per migliorare la resa dei 32nm per certi versi è indipendente dal tipo di architettura.
O pensi che il Tick/Tock siano soldi buttati? Prima migliori il silicio, poi ci stampi su una nuova architettura, senza temere di rifare buona parte del lavoro daccapo. Visti che solo per un piccolo (ma con perdite delle prestazioni del 30%) bug al design B1 di BD, llano e Zambesi non sono usciti a meno di un mese di distanza.

Paragrafando Paolo.oliva: Se (il tick tock) lo fa Intel tutto bene, se lo fa AMD è il male assoluto.


il mio discorso se leggi bene ciò che scrivo non è su un llano già realizzato ma sul fatto che tu dai per scontato che un Llano con RCM non abbasserebbe il tdp come successo per BD.
A ridaglie un ipotetico a8-3870k da 80W è meglio di un a10-6700 da 65W?
A 65W, llano a8-3800 viaggiava a 2,4GHz....un +11% offerto dal RCM non lo rende di certo migliore di un a10-6700 (3,7GHZ, +54% di frequenza base, certo tutto merito del RCM....).
E a 3,6GHz invece di consumare 180W ne avesse consumato 150W cosa sarebbe cambiato? Perchè alla fine il consumo a 4GHz di un FX è sceso da 152 a 125W, nulla di così eclatante.

[george_p]

Guarda, ci rinuncio visto che continui a rispondermi come prima.

[tuttodigitale]

scrivo sintentico
1) prova oc senza RCM (valori indicativi)
FX8150 oc a 4,4GHz vs A8-3870K 3,6 GHz
8 core vs 4 core
COMMENTO: stravince BD, che sale una bellezza anche senza RCM.

2) fallimento silicio
a) previsti 4,8/5GHz di base per bulldozer, frequenza non raggiunta neppure con il turbo core.
b) Vcore decisamente più elevato per llano
c) >3GHz obiettivo di frequenza fallito.
d) mancanza del turbo core.

Commento: k10 su 45nm viaggiava a frequenze decisamente elevate, basti pensare ai 3,7GHz base di phenom II 980. Quindi qualsiasi riferimento sul fatto che k10 su 32nm non potesse quantomeno in OC superare i 4GHz (cosa che avveniva con una certa frequenza con un buon sistema di raffreddamento ad aria), non trova alcun fondamento. E comunque sono falliti due obiettivi che AMD aveva in mente (1,3 V e oltre i 3GHz) dopo 7 mesi di ritardo l'apu di punta aveva solo 2,9GHz e 1,41 di Vcore.

DOMANDA: perchè AMD ha ritardato la messa in produzione di llano?

3) fx8350 con RCM ha migliorato:
a) frequenze del 11%
b) prestazioni del 18%
una buona evoluzione e nulla di più. Senza RCM probabilmente non ci avremmo fatto neanche caso al passaggio BD-PD.

DOMANDA: perchè VI ostinate a dire che PD è buono mentre BD, è mediocre quando le prestazioni sono molto simili in termini di ipc http://anandtech.com/bench/product/698?vs=434

4) llano vs Richland
a)basati entrambi sui 32nm
b) Richland ha RCM, che permette di aumentare le prestazioni del 10% con lo stesso TDP.
c) frequenze di base, più alte del 35-55% per Richland.
d) A 65W, la differenza è di 1,3GHz (1,4Ghz turbo).

Commento: Le differenze a livello di prestazioni sono tali che neanche l'uso di RCM (2,4 *11%=<2,7GHz) non può in alcun modo annullare il gap (o addirittura invertire le parti) esistente con Richland Il link sotto rappresenta con buona approssimazione il possibile gap esistente se anche llano avesse avuto RCM:
http://anandtech.com/bench/product/403?vs=675

Guarda, ci rinuncio visto che continui a rispondermi come prima.
Non ho nulla da aggiungere (e in realtà non ho aggiunto niente ai due post precedenti, ma solo cercato di correggere affermazioni che contrastano palesemente con la realtà dei fatti).

Non scriverò mai che un
1)k10 possa superare mediamente BD (prima versione) sui 32nm SOI, con o senza RCM
2) k10 non è un architettura progettata per superare i 3 GHz (ma lo sai che AMD aveva fatto girare un ES di Agena a 3GHz? e parliamo di 65nm...)
3) che llano sia stata una soluzione di ripiego. Fatta in fretta in furia.
4) che i miglioramenti dei 32nm SOI nei primi del 2011, non abbia tratto vantaggi alcuno llano (allora pechè è stato rimandato?)

perchè tutti gli elementi portano a pensarla esattamente all'incontrario

[george_p]

Detto molto semplicemente, io avrei voluto vedere un confronto tra una apu con BD (zambesi) senza RCM da confrontarlo con Trinity (che ha aggiunto solo 200 Mhz rispetto all'8150) per capire veramente quanto sia il miglioramento. Cosa impossibile perché BD prima versione non è stato realizzato su apu senza RCM.

Sei liberissimo di scrivere e pensare secondo ciò cui credi per carità ma ti rispondo invece riprendendo in dettaglio un tuo precedente post.
Soprattutto per riprendere il nocciolo fondamentale sull'architettura BD.
Poi, per carità, il K10 è una vecchia architettura e vuole dire che più di quel tanto non poteva più offrire ma per lo meno era stravecchia e non "nuova" come BD.
E per me confrontare APU con CPU pura è come confrontare banane con pere.

Dico di più, assodato il fatto che un FX8150 doveva avere 4,8-5GHz di base e che i 32 nm garantiva un corposo "fino +50% di frequenza a parità di consumi", si può risalire alle frequenze che doveva avere bulldozer octa-core a 45nn.

Me le ricordo eccome le slide di water-glofo.
Ti davano per certo un aumento del +50% di frequenze o -50% nel tdp.
Slides però e, purtroppo, non certezze.



Lo sai cosa scopriamo? Che su 45nm AMD pensava di riuscire a far girare un SAMPLE bulldozer ad almeno 3,3GHz (quel fino al50% di frequenze in più, pò essere rigirato in: i 45nm hanno una frequenza pari ad almeno il 66% dei 32nm). E queste non sono previsioni, campate in aria, visto che avevano già prodotto ES bulldozer su 45nm.

Ok, siamo arrivati a calcolare la frequenza di un "octa-core" BD sui 45 nm, ma spiegami meglio, "amd pensava di riuscire a far girare un SAMPLE bulldozer ad almeno 3,3 ghz" è lungi dall'averlo fatto.
Se dopo scrivi "E queste non sono previsioni, campate in aria, visto che avevano già prodotto ES bulldozer su 45nm." allora lo ha fatto a 3,3 ghz oppure no?
Certezze contro pensare e previsioni perdono di sicuro le prime.
Vedi anche ultima tua frase più giù.



Quello che sembra chiaro che un modulo BD, almeno su 45nm, consuma quanto se non meno di due core Nehalem, alla stessa frequenza.
Mah, chiaro o non chiaro io vedo che 4 moduli BD, sempre dai tuoi dati, consumano quanto un 6 core thuban e col 33% di core in più BD va quanto l'esacore... troppo poco per definire BD una buona architettura ma per te vale il contrario perché tanto "sale" in frequenza... e si è visto quanto sale.


Dalle slide, che ripeto riferiscono prestazioni superiori del 50%, in test specifici, e non un generico "fino a", si risale al fatto che la frequenza di clock, di base era compresa tra i 4,8 e i 5GHz.
Lo ricordo si.
Ma cmq con gli FX 9590 amd ha raggiunto i 4,8 ghz ottenendo prestazioni quasi pari al quadcore intel ivy bridge... facciamo finta che i 32 nm funzionino e togliamo il 50% di tdp, otteniamo 225/2=112,5 w.
Cosa manca all'architettura amd? Ad oggi quanto avrebbe dato in più? Consideriamo che ha anche l'RCM dalla sua.
Mi sfugge se ivy bridge abbia l'igpu o meno.



Nella peggiore delle ipotesi bulldozer a 45nm doveva girare a 3,3 GHz (ma più probabile 3,6)
Vedi risposta in basso.


In pratica, si ripete le stesse cose: i 32nm non sono migliori dei 45nm, se non grazie all'utilizzo del RCM, che però è una tecnologia indipendente dal silicio.

Si, l'ho capito benissimo e i fatti parlano abbastanza chiaro.

Ancora convinti che 3,6 GHz e 125W per un octa-core siano giusti per il 32nm, quando AMD prevedeva di avere simili valori con i 45nm?

Guarda che ti sei fatto un idea sbagliata, almeno verso il sottoscritto, visto che tutti ci aspettavamo che il 32 nm funzionasse e che BD viaggiasse ad almeno quei 4,8 ghz per arrivare forse anche a 6 ghz, me le ricordo bene le discussioni di 5 anni fa su questo thread.

Proprio per quello la mancanza di silicio fa capire quanto debole e troppo dipendente da quest'ultimo sia stata questa architettura (e questa non è certo previsione ma dato di fatto).

Ma scusa, se amd prevedeva (e prevedeva è diverso da aveva realizzato, quindi CERTEZZA ASSOLUTA) un octa-core e sottolineo OCTA=OTTO CORE a 3,6 ghz sui 45 nm con 125 w di tdp da contrapporre all'esacore thuban sempre con 125 w di tdp ...mi spieghi quanto migliore sia una architettura del genere, definita NUOVA, rispetto al K10?

Ti spiego, come scritto tanti post fa, perché per me non è per niente buona:
rispetto all'esacore hai due cores in più, il 10% di frequenza in più (300 mhz), ottieni le stesse prestazioni o poco più e consumi lo stesso tanto (125 w di tdp).
Ecco l'esempio che facevo sempre io... sullo stesso silicio.
Dove sono i consumi ridottissimi di BD nei 45 nm?
Ahhh si, ha due cores in più... e per un octacore 4 FPU in meno... ah ma le hanno potenziate... e menomale se no che prestazioni offriva allora? Tutta questa potenza non ce la vedo rispetto all'esacore thuban.
Consideralo allora un Quad.Core potenziato e ragioniamo meglio ma continuo a non vedere questo consumo così tanto ridotto come lo descrivi tu, sia sui 45 nm sia sui 32 nm.

Chiudo questa ennesima loopata, per tornare dalle previsioni e slides alla realtà dei fatti.

AMD ha azzerato le sue quote in ambito server, ridotte in ambito desktop (High End soprattutto) e fatto la sua scelta di tornare quanto prima possibile ad un approccio architetturale diverso da questo così tanto incompreso CMT. A dispetto di tutte le sue stesse slides, prove e controprove fatte con BD in laboratorio e soprattutto su strada.
Questa è l'unica certezza, che piaccia o meno.

[paolo.oliva2]

Ascolta, le prove fatte in OC di Llano ovvio che su quel 32 nm schifoso portano a consumi alti...

In questa riga che ti ho quotato hai racchiuso quanto si dice da inizio TH.

Il silicio 32nm è schifoso, porta a consumi alti. Il 32nm SOI non ha avuto nessuna evoluzione e l'architettura BD ha implementato solo l'RCM che porta un guadagno esiguo.
Su questa base, l'architettura BD, PER COLPA DEL SILICIO, non ha potuto implementare evoluzioni, quali Steamroller e Excavator (FX).
Non ti pare fazioso il confronto con Intel sul 22nm/14nm, con le ultime evoluzioni architetturali, in cui Intel ha potuto aumentare sia IPC che frequenze, ad un 8350 Piledriver e imputando il divario al CMT fallimentare?

Io sto solamente dicendo che l'efficienza o meno di BD con CMT non la si può valutare nel l'interezza perché gambizzata dal silicio, stop. Per contro si riportano proci Intel con un TDP/numero core migliore di AMD, l'IPC dell'ultima architettura Intel, e bla bla bla, ignorando in toto il fattore silicio.
Carrizo sul 28nm, è efficiente BD o no? Migliorerebbe l'efficienza se fosse sul 22nm o ancor più su un 14nm?
Per quale motivo un APU basato su BD modulare è efficiente ed invece un procio non APU non può esserlo se non per il silicio? O sono di parte? 1 modulo BD dovrebbe consumare circa quanto 1 core +SMT Intel, con tutti i pro e i contro che vuoi, ma è ovvio che a parità di silicio si dovrebbe avere un TDP simile tra n moduli = n core + SMT. Quando nel reale con gli FX si ha un TDP di 1 modulo tanto quanto 2 core +SMT, questo è o non è fattore silicio?

[george_p]

@Paolo: si dicono tante cose nel thread non solo che K10, o almeno quel K10 con Igpu abbia limite di frequenza fermo su 2.900 sul 32nm, penso che la più importante sia il fatto che BD come architettura ha prestazioni scarse a parità di frequenza, semplice e Vero.
Poi può salire fino a 10 Ghz per essere la più potente cpu dell'universo ma per far questo dipende almeno al 50% (ma a salire) dal solo silicio, di suo offre ben poco.
Questo è obbiettivamente un dato di fatto.
Per questo motivo non hai avuto il tuo "10 cores" o più che andrebbe più correttamente chiamato penta-core.

Il silicio 32nm è schifoso, porta a consumi alti.
Il 32 nm non porta a consumi alti ma semplicemente non li fa scendere rispetto al 45 nm che è ben diverso.

[paolo.oliva2]

ma chi ha detto che non avrebbe migliorato.
L'abbassamento del TDP l'hanno utilizzato per aumentare il clock del 11%. Le differenze di clock sono tali (dal 35 al 55% in più) che anche un +11% per k10, danno alle architetture BD un netto vantaggio a livello di clock. Che poi un apu a 3,3 GHz sia comunque competitiva su BD a 4,1 GHz a parità di core, non l'ho mai messo in discussione.
Non mi stancherò mai di ripeterlo (siete avvisati) che il problema di AMD non erano le prestazioni nel MT, visto che era alla pari con Intel.

Ora non voglio essere polemico, ma basta farsi un conto abbastanza elementare per rendersi conto che BD (la prima versione) potenzialmente va più di k10 nel ST.

Facciamo finta che una cpu esacore k10 e una cpu octa-core BD vadano uguali nel MT, che poi non è tanto falso.
1) k10 ha un numero maggiore di core. Ogni core k10 consuma mediamente il 33% di un core BD. Con un solo core attivo, k10 avrà minor margine termico. Possiamo quantificare questo vantaggio in circa 6W.

2)BD è in grado, quasi di azzerare il consumo degli altri core al minimo. Mentre in k10, la tensione di alimentazione dei core "dormienti" è pari a quella di un core attivo. Dopo un rapido calcolo, si scopre, che il consumo è superiore di circa 20W. In sostanza, quei core in più raddoppiano di fatto il consumo energetico.

in pratica 1) e 2) permettono a BD di risparmiare circa 25W: ma aspetta un attimo! un FX8150 a 4GHz non consumava circa 25W in più secondo tom's?
Praticamente AMD BD guadagna 11%

3) Le prestazioni di un core BD decadono quando viene utilizzato il secondo core. Sappiamo che il CMT di BD offre prestazioni pari al 73% di un dual core CMP. Ergo un core rende l'86%, che si traducono in prestazioni superiori del 16%.

4) includiamo anche una piccola perdita nell'efficienza dello scaling del 5% tra 6 e 8 core.

Risultato. Se cpu BD 8 core va forte nel MT quanto una soluzione esacore k10:
Le prestazioni per core sono pari a circa, per la 4), al 26%.

Ma nel ST per la 1) 2) e la 3), le prestazioni salgono del 29%.

Questo significa che un octa-core che è pari ad una soluzione esa-core nel MT, può essere più veloce della soluzione con meno core nel ST...

Ovviamente l'analisi non è completa, ma di suo ricordiamo che l'architettura FO4, 17 vs 22, può girare a frequenze del 25% più elevate. In pratica BD odvrebbe avere un andamento più favorevole nel rapporto (delta frequenza)/(delta consumo)

infatti sempre nelle slide di AMD, si parlavano di prestazioni nel ST le più elevate tra le architetture in circolazione: Conroe e k10.



Guarda che llano e Zambesi hanno subito lo stesso tragico destino. Entrambi sono stati posticipati di 7mesi, e sono usciti a poco distanza uno dall'altro. Questo è indice del fatto che AMD ha lavorato duramente per raggiungere quelle (scarse) prestazioni su k10. Anche perchè il lavoro per migliorare la resa dei 32nm per certi versi è indipendente dal tipo di architettura.
O pensi che il Tick/Tock siano soldi buttati? Prima migliori il silicio, poi ci stampi su una nuova architettura, senza temere di rifare buona parte del lavoro daccapo. Visti che solo per un piccolo (ma con perdite delle prestazioni del 30%) bug al design B1 di BD, llano e Zambesi non sono usciti a meno di un mese di distanza.

Paragrafando Paolo.oliva: Se (il tick tock) lo fa Intel tutto bene, se lo fa AMD è il male assoluto.



A ridaglie un ipotetico a8-3870k da 80W è meglio di un a10-6700 da 65W?
A 65W, llano a8-3800 viaggiava a 2,4GHz....un +11% offerto dal RCM non lo rende di certo migliore di un a10-6700 (3,7GHZ, +54% di frequenza base, certo tutto merito del RCM....).
E a 3,6GHz invece di consumare 180W ne avesse consumato 150W cosa sarebbe cambiato? Perchè alla fine il consumo a 4GHz di un FX è sceso da 152 a 125W, nulla di così eclatante.

C'è un altro punto che non si è preso in considerazione tra K10 e BD.
BD ha un consumo superiore anche dovuto a L2 superiore. Nell'atto pratico, un Thuban oltre 1 TH a core perde efficienza, mentre un BD non mostra alcuna perdita anche con 3TH a modulo, che nell'effettivo porta un K10 X6 a 6TH contro un BD che ne può elaborare contemporaneamente il doppio ma anche il triplo.
Infatti io avevo un Thuban fortunello che potevo tenere @4,2/4,3GHz in DU, e l'8150 di più ma non di molto, credo 4,4GHz, ma avevo preferito l'8150 perché a contrario del Thuban, potevo avviare qualsiasi cosa indipendentemente dal carico già attivo come se fosse libero, contrariamente al Thuban. Poi è ovvio che chi cercava l'ST massimo l'8150 fosse una ciofeca. Ma il punto è tutto lì, perché già con Pile il divario ST si era azzerato a vantaggio di un MT ben superiore e apprezzabile, in MT, il carico maggiore.
Un Steamroller ed Excavator avrebbero dato un'enorme spinta ST con ancor più guadagnò in MT.

Il cambio architetturale lo si farebbe per aumentare le prestazioni, ma siccome il divario lo si ha causa silicio, ho i miei dubbi in primis sull'effettiva disponibilità silicio idoneo di GF, ma rimango della convinzione che che se sto silicio arrivasse,l'efficienza BD non sarebbe da meno di quella con Zen.

[paolo.oliva2]

@Paolo: si dicono tante cose nel thread non solo che K10, o almeno quel K10 con Igpu abbia limite di frequenza fermo su 2.900 sul 32nm, penso che la più importante sia il fatto che BD come architettura ha prestazioni scarse a parità di frequenza, semplice e Vero.
Poi può salire fino a 10 Ghz per essere la più potente cpu dell'universo ma per far questo dipende almeno al 50% (ma a salire) dal solo silicio, di suo offre ben poco.
Questo è obbiettivamente un dato di fatto.
Per questo motivo non hai avuto il tuo "10 cores" o più che andrebbe più correttamente chiamato penta-core.


Il 32 nm non porta a consumi alti ma semplicemente non li fa scendere rispetto al 45 nm che è ben diverso.
Si ma tu continui sempre a valutare IPC, ma il VERO parametro è IPC x frequenza, BD non deve girare a 6GHz per ottenere potenza inquadrato su Piledriver, ad un Ex basterebbero già 5GHz per uguagliare Intel, e se Intel arriva a 4GHz, l'architettura BD avrebbe un TDP inferiore tale da permettere ALMENO 500MHz in più. È ovvio che se GF offre un silicio che già ha TDP superiori a frequenze inferiori di quelle Intel, può considerarsi un problema BD?

Perché ribatti sempre tra BD 32nm e Thuban 45nm?
Se Intel tra il 22nm ed il 14nm non guadagna in TDP, è prb dell'architettura?
AMD aveva realizzato un prototipo BD sul 45nm e aveva un consumo/prestazioni MIGLIORE, e su questo e per questo l'ha realizzato sul 32nm. Se poi il 32nm ha disatteso le aspettative, è colpa di BD?
Se fosse come tu dici, 32nm ottimo, avrebbe avuto senso il passaggio da SOI a Bulk con tutti i problemi per 4nm? Avrebbero fatto BD o K10?
Può un'architettura meno efficiente portare prestazioni simili ad un Llano con 1/3 dei consumi?

P.S.
Abbiamo dati ufficiali che il modulo consuma meno rispetto a 2 core e che per lFO4 il rapporto prestazioni/consumo dovrebbe essere migliore.
Un 8150 riflette ciò rispetto ad un Thuban?
Perché vogliamo continuare una farsa stile studio IBM FO4 idioti, AMD masochusta e GF migliore FAB al mondo?

[davo30]

La necessità delle frequenze straelevate dovute all'architettura, portano a consumi elevati. Anche con un silicio perfetto, BD avrebbe necessitato di ALMENO i 5ghz per essere all'altezza. E penso che manco Intel sarebbe stata capace di tirare fuori un processo che permettesse un x8 a quelle frequenze in 125w

Inviato dal mio XT1092 utilizzando Tapatalk

[george_p]

@Paolo: Ho sempre letto sui libri che l'IPC è il numero di Istruzioni per Clock dove clock è la frequenza. Solo nei tuoi post leggo questa novità.
Quindi continuo a valutare numero di istruzioni per ciclo di clock. Se a te piace reinterpretarlo a modo tuo libero di farlo.
BD elabora circa la metà di istruzioni rispetto alla concorrenza per ogni ciclo (chiamalo Hertz così ti aiuta a capire meglio), PUNTO.

Ecco perché BD ha bisogno di girare a 5 GHz rispetto la concorrenza alla quale ne bastano quasi la metà, poi però quando le cpu intel arrivano a 5 GHz BD dove deve arrivare?
Cos'altro vuoi aggiungere a questo?
Penso non serva altro per capire il punto debole dell'architettura che non sta nemmeno nel cmt solamente.

Per il resto oltre i dati di fatto rimangono solo idee e speculazioni con calcoli mirabolanti che lasciano il tempo che trovano, anche se derivano da dati e slides ufficiali.

P.s.:
Abbiamo dati ufficiali che il modulo consuma meno rispetto a 2 core e che per lFO4 il rapporto prestazioni/consumo dovrebbe essere migliore.
I dati ufficiali se non corrispondono alla realtà valgono meno di zero. Anche tu scrivi "dovrebbe" che è un bel condizionale, quindi molto lontano da "è" migliore".

Perché vogliamo continuare una farsa stile studio IBM FO4 idioti, AMD masochusta e GF migliore FAB al mondo?
Queste son parole tue, però gli studi ibm non hanno aiutato amd e questo è un dato di fatto, amd masochista no perché dal 2002 ha vissuto di rendita grazie alle tecnologie sviluppate fino ad allora dal K7 al K8 dai quali hanno tratto i processori fino al K10, poi è nato bull e hanno stravolto il concetto dove amd aveva maggiore forza, l'elaborazione di più ISTRUZIONI per ciclo di clock.
Secondo me dai un interpretazione tutta tua ai miei post, dove scrivo tutto questo?
Water-glofo la migliore al mondo? :sbonk:

[Grizlod®]

non ci vedo nulla di male nel saluto di keller da AMD, ha sempre fatto così e in un anno all'epoca dello sviluppo dei k8 ci rimase anche meno, e sappiamo tutti cosa venne dopo...
uno come lui che rimane a fare dopo aver sviluppato su carta l'architettura? andrà a progettarne un altra chissà dove ricoperto d'oro, beato lui.

i tempi sono maturi per il 2016, c'è un intero anno di tempo, tape-out già effettuato e sono alla fase di debug che va dai 6 ai 12 mesi prima della commercializzazione, tutto sta a vedere come verrà su silicio

ps. se non andrà già in pensione magari lo rivedremo in AMD nel 2020...

Se dovesse tornare in AMD, significherebbe che "i giovani", non hanno capito un c###o. IMO non avevano nemmeno in progetto di richiamarlo questa volta...sono stati costretti dalla loro inettitudine ;)

[Mister D]

@Paolo: Ho sempre letto sui libri che l'IPC è il numero di Istruzioni per Clock dove clock è la frequenza. Solo nei tuoi post leggo questa novità.
Quindi continuo a valutare numero di istruzioni per ciclo di clock. Se a te piace reinterpretarlo a modo tuo libero di farlo.
BD elabora circa la metà di istruzioni rispetto alla concorrenza per ogni ciclo (chiamalo Hertz così ti aiuta a capire meglio), PUNTO.

Ecco perché BD ha bisogno di girare a 5 GHz rispetto la concorrenza alla quale ne bastano quasi la metà, poi però quando le cpu intel arrivano a 5 GHz BD dove deve arrivare?
Cos'altro vuoi aggiungere a questo?
Penso non serva altro per capire il punto debole dell'architettura che non sta nemmeno nel cmt solamente.

Per il resto oltre i dati di fatto rimangono solo idee e speculazioni con calcoli mirabolanti che lasciano il tempo che trovano, anche se derivano da dati e slides ufficiali.

P.s.:

I dati ufficiali se non corrispondono alla realtà valgono meno di zero. Anche tu scrivi "dovrebbe" che è un bel condizionale, quindi molto lontano da "è" migliore".


Queste son parole tue, però gli studi ibm non hanno aiutato amd e questo è un dato di fatto, amd masochista no perché dal 2002 ha vissuto di rendita grazie alle tecnologie sviluppate fino ad allora dal K7 al K8 dai quali hanno tratto i processori fino al K10, poi è nato bull e hanno stravolto il concetto dove amd aveva maggiore forza, l'elaborazione di più ISTRUZIONI per ciclo di clock.
Secondo me dai un interpretazione tutta tua ai miei post, dove scrivo tutto questo?
Water-glofo la migliore al mondo? :sbonk:

Basta leggere da wiki:
https://en.wikipedia.org/wiki/Instructions_per_cycle
In computer architecture, instructions per clock (instruction per cycle or IPC) is one aspect of a processor's performance: the average number of instructions executed for each clock cycle. It is the multiplicative inverse of cycles per instruction.

Tradotto: è il numero medio di istruzioni eseguiti in ogni ciclo di clock. e' anche l'inverso moltiplicativo dei cicli per istruzioni.
In matematica "per" va inteso con il diviso. Metri al secondo o metri per secondo sono la stessa cosa. Per sapere i metri devi moltiplicare per i secondi. Idem per l'IPC: per sapere le istruzioni al secondo devi moltiplicare l'ipc per la frequenza. Infatti nel secondo periodo:
The number of instructions per second and floating point operations per second for a processor can be derived by multiplying the instructions per cycle and the clock speed (measured in cycles per second or Hertz) of the processor in question. The number of instructions per second is an approximate indicator of the likely performance of the processor.

[davo30]

http://www.tomshw.it/news/amd-le-nostre-apu-combattono-l-aumento-dei-gas-serra-70235

Questi hanno dei problemi forti, ma mentali!
Zen risolverà la fame nel mondo!!!
Inviato dal mio XT1092 utilizzando Tapatalk

[george_p]

Basta leggere da wiki:
https://en.wikipedia.org/wiki/Instructions_per_cycle
In computer architecture, instructions per clock (instruction per cycle or IPC) is one aspect of a processor's performance: the average number of instructions executed for each clock cycle. It is the multiplicative inverse of cycles per instruction.

Tradotto: è il numero medio di istruzioni eseguiti in ogni ciclo di clock. e' anche l'inverso moltiplicativo dei cicli per istruzioni.
In matematica "per" va inteso con il diviso. Metri al secondo o metri per secondo sono la stessa cosa. Per sapere i metri devi moltiplicare per i secondi. Idem per l'IPC: per sapere le istruzioni al secondo devi moltiplicare l'ipc per la frequenza. Infatti nel secondo periodo:
The number of instructions per second and floating point operations per second for a processor can be derived by multiplying the instructions per cycle and the clock speed (measured in cycles per second or Hertz) of the processor in question. The number of instructions per second is an approximate indicator of the likely performance of the processor.

Si, dipende da quanti cicli occorre al processore per elaborare le istruzioni. Dividi la frequenza per quel numero e ottieni le istruzioni elaborate.
Mi viene più spontaneo guardare il numero di istruzioni elaborate per ogni ciclo di clock. Il clock è la frequenza, supponiamo=100 i cicli sono 4 e ottengo un IPC uguale a 25. Poi ci son le pipeline che eseguono istruzioni in parallelo a parità di clock ma subentrano diversi problemi ecc ecc

Personalmente guardo sempre l'ipc, e se pure non posso sapere esattamente quale sia quello di un processore vedo l'andamento attraverso benchmark e programmi reali collimando esperienze dirette dove possibile o indirette per la maggior parte, quindi se vedo che una cpu intel, rispetto a quella amd, esegue più velocemente programmi di rendering a parità di frequenza ho un processore in grado, con tutta la sua architettura, di elaborare molte più istruzioni rispetto a quello amd.
Poi guardare nello specifico tutto l'ipc incluse le pipeline con sistemi di predizione risulta troppo tecnico e inutile.

Semplifichiamo così, BD per avere a parità di core (!!!!!!!) l'ipc di un ivy bridge ha bisogno di quasi il doppio della frequenza. Non serve sapere altro.

Non parlo di Zen perché quel 40% di ipc non ci sta dicendo tutta la verità su come sia fatta quella architettura e perché su strada non abbiamo ancora niente da verificare.

[Mister D]

Si, dipende da quanti cicli occorre al processore per elaborare le istruzioni. Dividi la frequenza per quel numero e ottieni le istruzioni elaborate.
Mi viene più spontaneo guardare il numero di istruzioni elaborate per ogni ciclo di clock. Il clock è la frequenza, supponiamo=100 i cicli sono 4 e ottengo un IPC uguale a 25. Poi ci son le pipeline che eseguono istruzioni in parallelo a parità di clock ma subentrano diversi problemi ecc ecc

Personalmente guardo sempre l'ipc, e se pure non posso sapere esattamente quale sia quello di un processore vedo l'andamento attraverso benchmark e programmi reali collimando esperienze dirette dove possibile o indirette per la maggior parte, quindi se vedo che una cpu intel, rispetto a quella amd, esegue più velocemente programmi di rendering a parità di frequenza ho un processore in grado, con tutta la sua architettura, di elaborare molte più istruzioni rispetto a quello amd.
Poi guardare nello specifico tutto l'ipc incluse le pipeline con sistemi di predizione risulta troppo tecnico e inutile.

Semplifichiamo così, BD per avere a parità di core (!!!!!!!) l'ipc di un ivy bridge ha bisogno di quasi il doppio della frequenza. Non serve sapere altro.

Non parlo di Zen perché quel 40% di ipc non ci sta dicendo tutta la verità su come sia fatta quella architettura e perché su strada non abbiamo ancora niente da verificare.

Guarda che ti stai confondendo.
Parti dal SI. 1 Hertz è l'inverso del tempo 1/sec o sec ^-1 vuol dire semplicemente le rivoluzioni, cicli, giri di qualcosa in un secondo. Quindi 3 hZ sono 3 clicli al secondo. 4 GHz sono 4 miliardi di cicli al secondo.
L'IPC non contiene l'Hertz perché sono istruzioni al ciclo (detto anche istruzioni per ciclo). IPC=Istruzioni/ciclo quindi una cpu con IPC 100 vuol dire che processa 100 istruzioni in un ciclo cioè 100 istruzioni/ciclo o 100 istruzioni 'al' ciclo o anche 100 istruzioni 'per' ciclo.
Detto questo se tu prendi la frequenza cioè i cicli al secondo e divi per l'ipc cosa ottieni? L'Analisi dimensionale occorre in nostro aiuto. (cicli/sec) / (istruzioni/ciclo) che equivale a (cicli/sec) * ciclo/istruzioni= (cicli^2/sec)/istruzioni o anche Hz*ciclo/istruzioni. Che ti serve????

Per ottenere le istruzioni elaborate in un secondo devi se mai moltiplicare le istruzioni al cliclo per la frequenza: IPC*(cicli/sec). Infatti (istruzioni/ciclo)*(cicli/sec), cicli si elidono perché uguali e ti rimangono le famose IPS istruzioni per secondo o detto meglio le istruzioni al secondo.
Se poi vuoi sapere in 5 minuti quante elaborazioni svolge una determinata cpu basta moltiplicare gli IPS e i 5 minuti (in seccondi).
Es IPC 100 , frequenza 100 HZ Quanti IPS ha la cpu e in 30 minuti quante istruzioni elabora?
100*100= 1000 istruzioni/sec (IPS). 30*60= 1800 sec. 1000*1800=1800000 istruzioni elaborate.
Spero di essere stato esaustivo.;)
Quindi Paolo non sbaglia quando dice che la Potenza elaborativa di una cpu è il prodotto tra l'IPC e la frequenza e aggiungo io, si ottengono gli IPS (Istruction per second)

[capitan_crasy]

http://www.tomshw.it/news/amd-le-nostre-apu-combattono-l-aumento-dei-gas-serra-70235

Questi hanno dei problemi forti, ma mentali!
Zen risolverà la fame nel mondo!!!
Inviato dal mio XT1092 utilizzando Tapatalk

http://i.imgur.com/GgAXwLF.jpg

[george_p]

@ MisterD: Aspetta, ciò che scrivi è esatto.
Quando però io ho scritto che se un istruzione richiede 4 cicli, come esempio per semplificare, quindi 4 hertz è ovvio che se ho una frequenza di 100 hertz divido 100 per 4 e ottengo il numero di istruzioni elaborate che è 25.
Che alla fine è il numero di istruzione per clock/frequenza, 25. Il fattore tempo non l'ho minimamente cercato. Ma è sottinteso che 25 istruzioni sono elaborate in un secondo.

Spiego meglio:
la cpu blu mi elabora una istruzione ogni 2 cicli (ogni 2 hertz)
La cpu rossa mi elabora la stessa istruzione ogni 4 cicli (ogni 4 hertz)
A parità di frequenza, mettiamo 100 hertz per semplificare al massimo quale ipc è più alto?


P.s.: errata corrige del precedente post, l'IPC è 1/4 (cicli) quindi 0,25 mentre 25 è il numero totale di istruzioni elaborate (al secondo), o potenza se vogliamo come scrive Paolo.

[davo30]

http://i.imgur.com/GgAXwLF.jpg

Dai, seriamente, che sparata è "ridurremo i gas serra attraverso le nostre APU"?

[george_p]

Dai, seriamente, che sparata è "ridurremo i gas serra attraverso le nostre APU"?

Ma seriamente, pensi anche sia il caso di stare a ragionare su certi commenti? Van presi per quel che sono. Spazzatura mentale.

[paolo.oliva2]

@Paolo: Ho sempre letto sui libri che l'IPC è il numero di Istruzioni per Clock dove clock è la frequenza. Solo nei tuoi post leggo questa novità.
Quindi continuo a valutare numero di istruzioni per ciclo di clock. Se a te piace reinterpretarlo a modo tuo libero di farlo.

IPC è istruzioni per ciclo di clock ed è comparabile con UGUALE clock.
Siccome a seconda delle architetture il clock È DIVERSO, nome una MIA interpretazione, ma esclusivamente la tua, visto che BD a parità di consumo permette frequenze più elevate

BD elabora circa la metà di istruzioni rispetto alla concorrenza per ogni ciclo (chiamalo Hertz così ti aiuta a capire meglio), PUNTO.

Mi sembri Tom's quando a suo tempo per comparare Intel ad AMD, o overcliccava Intel o downcloccava AMD

Ecco perché BD ha bisogno di girare a 5 GHz rispetto la concorrenza alla quale ne bastano quasi la metà, poi però quando le cpu intel arrivano a 5 GHz BD dove deve arrivare?
Cos'altro vuoi aggiungere a questo?

Che siccome il limite architetturale di Intel quale? 5GHz? Le CPU Intel a 5GHz non le vedrai mai, visto che se ci arrivano è a azoto, mentre AMD ha benchato a 7,6GHz, mi pare più che evidente che il silicio di Intel concede di sfruttare quasi al massimo l'architettura, mentre BD invece non permette manco di sfruttarla per quello che può fare

Penso non serva altro per capire il punto debole dell'architettura che non sta nemmeno nel cmt solamente.

Se tu non vuoi capire i problemi che ci sono nel silicio, è inutile discutere

Per il resto oltre i dati di fatto rimangono solo idee e speculazioni con calcoli mirabolanti che lasciano il tempo che trovano, anche se derivano da dati e slides ufficiali.

P.s.:

I dati ufficiali se non corrispondono alla realtà valgono meno di zero. Anche tu scrivi "dovrebbe" che è un bel condizionale, quindi molto lontano da "è" migliore".

Se per te non valgono manco i dati ufficiali del flop 32nm SOI, visto che dipenderebbe tutto dall'architettura


Queste son parole tue, però gli studi ibm non hanno aiutato amd e questo è un dato di fatto, amd masochista no perché dal 2002 ha vissuto di rendita grazie alle tecnologie sviluppate fino ad allora dal K7 al K8 dai quali hanno tratto i processori fino al K10, poi è nato bull e hanno stravolto il concetto dove amd aveva maggiore forza, l'elaborazione di più ISTRUZIONI per ciclo di clock.
Secondo me dai un interpretazione tutta tua ai miei post, dove scrivo tutto questo?
Water-glofo la migliore al mondo? :sbonk:
Ricapitolo

Studi IBM FO4 = BD con pipeline = Minor IPC ma > frequenza per un minor TDP a uguale potenza

Questo cozza con il tuo discorso IPC indipendente dalla frequenza, o no?

AMD implementa il CMT al discorso sopra per diminuire del 25% il TDP con una perdita di potenza inferiore rispetto al guadagno TDP.

GF fa il silicio, manda a puttane l'FO4 di IBM ed il CMT di AMD.

Per te il problema è tutto nell'architettura ed il silicio non conta una mazza.

È così o non è così? O sono io che interpreto male quelli che scrivi?

P.S.
È così o non è così che tu ancora continui a valutare che Intel ha il doppio di IPC (a me risultava il 50%, poi magari sono rimasto indietro), e porti un confronto architetturale ignorando EXcavator? Magari ci metti una toppa riportando X commerciale" ma è o non è a causa del silicio?

[george_p]

piuttosto

http://www.bitsandchips.it/9-hardware/6065-il-team-di-austin-e-fiducioso-su-zen-e-sul-futuro-di-amd

@george

comunque non te ne fai nulla del solo numero di IPC se poi non lo moltiplichi per la frequenza o i core in caso di software scritti per il multicore, allora a che lo si fa a fare OC o a che si prendono a fare cpu multicore :D

Si si, lo so è che comunque a parità di frequenza un ipc alto lo preferirei anche e a maggior ragione se aumentando la prima aumento di conseguenza la quantità di istruzioni elaborate.
Poi ok, OC è anche una semplice passione per l'estremo alla quale io non sono interessato.


IPC è istruzioni per ciclo di clock ed è comparabile con UGUALE clock.
Siccome a seconda delle architetture il clock È DIVERSO, nome una MIA interpretazione, ma esclusivamente la tua, visto che BD a parità di consumo permette frequenze più elevate

Mi sembri Tom's quando a suo tempo per comparare Intel ad AMD, o overcliccava Intel o downcloccava AMD

Che siccome il limite architetturale di Intel quale? 5GHz? Le CPU Intel a 5GHz non le vedrai mai, visto che se ci arrivano è a azoto, mentre AMD ha benchato a 7,6GHz, mi pare più che evidente che il silicio di Intel concede di sfruttare quasi al massimo l'architettura, mentre BD invece non permette manco di sfruttarla per quello che può fare

Se tu non vuoi capire i problemi che ci sono nel silicio, è inutile discutere

Se per te non valgono manco i dati ufficiali del flop 32nm SOI, visto che dipenderebbe tutto dall'architettura


Ricapitolo

Studi IBM FO4 = BD con pipeline = Minor IPC ma > frequenza per un minor TDP a uguale potenza

Questo cozza con il tuo discorso IPC indipendente dalla frequenza, o no?

AMD implementa il CMT al discorso sopra per diminuire del 25% il TDP con una perdita di potenza inferiore rispetto al guadagno TDP.

GF fa il silicio, manda a puttane l'FO4 di IBM ed il CMT di AMD.

Per te il problema è tutto nell'architettura ed il silicio non conta una mazza.

È così o non è così? O sono io che interpreto male quelli che scrivi?

P.S.
È così o non è così che tu ancora continui a valutare che Intel ha il doppio di IPC (a me risultava il 50%, poi magari sono rimasto indietro), e porti un confronto architetturale ignorando EXcavator? Magari ci metti una toppa riportando X commerciale" ma è o non è a causa del silicio?




Ho sempre scritto che il silicio fa pena ma anche l'architettura non scherza. E che BD aveva e ha necessità di un silicio troppo avanzato per non consumare eccessivamente.
Trova tutti i miei messaggi in questa discussione, ci sono sempre.

Mi sembri Tom's quando a suo tempo per comparare Intel ad AMD, o overcliccava Intel o downcloccava AMD

Ma quale tom's per favore. Intel ha un ipc superiore e lo sappiamo da sempre, pure tu lo scrivi.
Poi non sarà il doppio ma il 70% in più, e poco non mi pare proprio.
E l'IPC è Istruzioni elaborate per ogni ciclo/Hertz come specificava anche MisterD, quindi per ottenere stesse prestazioni (intese come istruzioni elaborate in un secondo) di un intel hai bisogno di molta più frequenza. Elementare.
E' così o non è così?

[paolo.oliva2]

Facciamo un passo indietro.
Intel ha una architettura efficiente, un silicio che la sfrutta al 100%, ed è un prodotto di certo ottimo.
BD doveva essere CERTAMENTE migliore del K10 e lo è. Per essere competitivo con Intel doveva avere ALMENO un silicio alla pari sia in miniaturizzazione che in bontà PP.

Ci siamo fino a qui?

Tu dai ad AMD la stessa architettura Intel ed una bontà PP silicio uguale a quella Intel, potrebbe a 32nm o a 28nm realizzare un 5960X o un 6700K? Mi pare ovvio che no.
Se poi analizzi che il 45nm SOI è stato uno dei migliori processi se non il migliore e che il 32nm SOI sicuramente il più deludente nel deludere l'aspettativa, il risultato è che Intel ci può mettere 2,6miliardi di transistor nei 140W per un clock di 3,2GHz (5960X Xeon), mentre AMD si ferma a 2,8GHz con 200milioni di transistor in meno.
Tradotto, -200.000 di transistor, -400MHz, su una architettura che con 50% in meno di IPC doveva consumare comunque meno, fanno una differenza MOSTRUOSA

Con 200.000 transistor, ci scapperebbero 2 moduli? Allora già sarebbe un BD X20. Excavator con +20/25% di IPC ci starebbe visto che Intel ha più IPC, e parlo di stessi consumi. Da 2,8GHz passiamo a 3,2GHz, visto che BD può raggiungere frequenze più elevate.

Ora, +15% di frequenza, +20/25% di IPC, e +25% di core. Questa sarebbe la differenza CONSERVATIVA dovuta al silicio.

Che poi uno voglia più IPC e quant'altro, benissimo, ma a me sembra che il procio sopra sarebbe competitivo e non di certo un flop BD/CMT almeno in ambito Server e in ambito desktop MT.

Cerca di capirmi.Non ti pare che il silicio abbia determinato che un FX lotti in MT con un X4+4 Intel anziché con un i7 X6?

[tuttodigitale]

Ok, siamo arrivati a calcolare la frequenza di un "octa-core" BD sui 45 nm, ma spiegami meglio, "amd pensava di riuscire a far girare un SAMPLE bulldozer ad almeno 3,3 ghz" è lungi dall'averlo fatto.


Scusami in italiano, e non in arabo queste due frasi sono del tutto equivalenti:
1) i 32nm permettono fino al 50% di clock in più a pari condizioni rispetto ai 45nm.
2) i 45nm permettono ALMENO il 66,6% del clock dei 32nm.
Quindi si, se AMD pensava di far girare a 5 GHz BD [NB], perchè aveva dati praticamente certi (il 45nm lo conosceva alla perfezione) di poter costruire un BD da almeno 3,3GHz.

NB su questo spero che non ci sia alcun dubbio: la slide anticipava quella che era la data di presentazione, di soli 4-5 mesi. E' davvero poco credibile che AMD abbia cannato l'ipc su test specifici, figurarsi del 40%.

Mah, chiaro o non chiaro io vedo che 4 moduli BD, sempre dai tuoi dati, consumano quanto un 6 core thuban e col 33% di core in più BD va quanto l'esacore... t

PS da nessuna parte ho fatto un confronto diretto, se non che era possibile fare un FX da 3,3 GHz con un turbo core molto più spinto (3,8 *30% =5GHz sulla carta) da 125W, e solo da qui fare un ipotetico confronto:
http://anandtech.com/bench/product/1340?vs=203
i miglioramenti nel MT (l'unico che hanno un senso nel test sopra), soprattutto considerando anche l'aumento di ipc dovuto a PD, non è esaltante (mai detto il contrario)

nel ST si doveva avere una situazione del tipo (vedere solo test nel ST)
http://anandtech.com/bench/product/1289?vs=203
dove BD/PD (mi pare di ricordare che le prestazioni nel ST siano praticamente identiche) mostrerebbe un +17% su K10 (3,8 vs 5GHz, che poi è il probabile turbo core su 45nm).

Ho detto che a parità di prestazioni nel MT, un BD dovrebbe garantire prestazioni nel ST superiore, nonostante ad un analisi superficiale questo sembra contraddittorio.
E in fin dei conti era li dove doveva migliorare k10, visto che era estremamente competitivo con Nehalem.

troppo poco per definire BD una buona architettura ma per te vale il contrario perché tanto "sale" in frequenza... e si è visto quanto sale.
OMG, tu pensi che l'impiego di RCM faccia guadagnare ad un a8-3800, 1300MHz da 2400 iniziali?

Su questo dato AMD, ci ha preso alla grande: BD a parità di core, consumi e PP permette un buon 30% di frequenza in più (anche questo è dato sparato a caso?).


Ma cmq con gli FX 9590 amd ha raggiunto i 4,8 ghz ottenendo prestazioni quasi pari al quadcore intel ivy bridge... facciamo finta che i 32 nm funzionino e togliamo il 50% di tdp, otteniamo 225/2=112,5 w.
Cosa manca all'architettura amd? Ad oggi quanto avrebbe dato in più? Consideriamo che ha anche l'RCM dalla sua.
Mi sfugge se ivy bridge abbia l'igpu o meno.

AMD aveva previsto un deca-core...una soluzione cheavrebbe avuto senso solo se la frequenza di clock si manteneva nell'ordine dei 4,6GHz+. In questo caso PD avrebbe retto il confronto con 3960x, il modello di punta di allora.
Infatti un solo modello octa-core doveva avere il tdp da 125W.

PS quel -50% dove l'hai preso? Sai per certo che il 32nm sia peggio il doppio di quanto preventivato? :confused: Non era un dato riferito ai 45nm? :rolleyes:
Eppure a me sembra che il 32nm sia peggio dei 45nm lk.
se togliamo quel 50% all'ipotetico (ma realistico, poichè si fonda su dati pubblicati) FX da 3,3 con turbo core 5GHz su 45nm, abbiamo:
125/2 =62,5W...oggettivamente sembra molto realistico (con questi dati) ipotizzare deca-core molto prossimi ai 5GHz.


Ma scusa, se amd prevedeva (e prevedeva è diverso da aveva realizzato, quindi CERTEZZA ASSOLUTA) un octa-core e sottolineo OCTA=OTTO CORE a 3,6 ghz sui 45 nm con 125 w di tdp da contrapporre all'esacore thuban sempre con 125 w di tdp ...mi spieghi quanto migliore sia una architettura del genere, definita NUOVA, rispetto al K10?
margini di miglioramento molto più ampi. un +7% e +14%, nella seconda e terza revisione, sono risultati notevoli..Intel dopo SB, si è dovuta accontentare di miglioramenti minimi. Chissà quanti sono stati concessi dal silicio...


Ecco l'esempio che facevo sempre io... sullo stesso silicio.
Dove sono i consumi ridottissimi di BD nei 45 nm?
Ahhh si, ha due cores in più... e per un octacore 4 FPU in meno... ah ma le hanno potenziate... e menomale se no che prestazioni offriva allora? Tutta questa potenza non ce la vedo rispetto all'esacore thuban.
Consideralo allora un Quad.Core potenziato e ragioniamo meglio ma continuo a non vedere questo consumo così tanto ridotto come lo descrivi tu, sia sui 45 nm sia sui 32 nm.

sulla carta tra aumenti di throughput a parità di clock (+50%? non ricordo) e frequenze più elevate (+30%), una FPu BD, vale quanto 2 FPu K10 :vedi cinebench 6800k vs 3870K: 3.56 vs 3.5 (ora dirai che c'è il rcm in mezzo, ma questo non toglie che la FPu di BD renda praticamente quanto 2 di k10).

Per un octa-core, i consumi sono assai ridotti (anche le prestazioni, ma nessuno ha mai detto il contrario).

[el-mejo]

IMHO Zen, visti i trascorsi di silicio sfigato, il futuro sempre sul silicio non proprio roseo ed il fatto che Amd è una realtà fabless in balia delle offerte delle varie fonderie, sarà stato progettato da Keller per avere il più altro IPC possibile, anche e soprattutto a scapito delle frequenze massime, strettamente legate al PP utilizzato.

Questo aprirebbe ad Amd la possibilità, all'occorrenza, di utilizzare per chip desktop e server PP non otimizzati per le alte prestazioni, come lo è il 28nm bulk delle apu.

@ Paolo

Ecco perchè per Amd era assolutamente necessario ripartire da zero con l'architettura e non continuare con excavator ed eventuali evoluzioni future, pur eventualmente scontando problemi di gioventù dell'architettura.

Imho il top di gamma Zen, se effettivamente sarà un x8+8, non avrà frequanze superiori ai 3ghz ed avrà un ipc simile ad Haswell.

Ah, un altra cosa che non teniamo mai in conto ma invece è fondamentale è la densità dei transistor e quindi la resa dei wafer e il numero massimo di core: Zen potrebbe essere stato ottimizzato su questo piuttosto che sulla potenza bruta, o comunque aver trovato un compromesso.

[isomen]

IMHO Zen, visti i trascorsi di silicio sfigato, il futuro sempre sul silicio non proprio roseo ed il fatto che Amd è una realtà fabless in balia delle offerte delle varie fonderie, sarà stato progettato da Keller per avere il più altro IPC possibile, anche e soprattutto a scapito delle frequenze massime, strettamente legate al PP utilizzato.

Questo aprirebbe ad Amd la possibilità, all'occorrenza, di utilizzare per chip desktop e server PP non otimizzati per le alte prestazioni, come lo è il 28nm bulk delle apu.

@ Paolo

Ecco perchè per Amd era assolutamente necessario ripartire da zero con l'architettura e non continuare con excavator ed eventuali evoluzioni future, pur eventualmente scontando problemi di gioventù dell'architettura.

Imho il top di gamma Zen, se effettivamente sarà un x8+8, non avrà frequanze superiori ai 3ghz ed avrà un ipc simile ad Haswell.

Ah, un altra cosa che non teniamo mai in conto ma invece è fondamentale è la densità dei transistor e quindi la resa dei wafer e il numero massimo di core: Zen potrebbe essere stato ottimizzato su questo piuttosto che sulla potenza bruta, o comunque aver trovato un compromesso.

Anche secondo me la nuova architettura dovrà avere un IPC alto per dipendere il meno possibile dal silicio... ma dubito che a 2016 inoltrato potrebbe essere competitiva su un 28nm, credo che un buon PP sia fondamentale ugualmente.

;) ciauz

[jok3r87]

IMHO Zen, visti i trascorsi di silicio sfigato, il futuro sempre sul silicio non proprio roseo ed il fatto che Amd è una realtà fabless in balia delle offerte delle varie fonderie, sarà stato progettato da Keller per avere il più altro IPC possibile, anche e soprattutto a scapito delle frequenze massime, strettamente legate al PP utilizzato.

Questo aprirebbe ad Amd la possibilità, all'occorrenza, di utilizzare per chip desktop e server PP non otimizzati per le alte prestazioni, come lo è il 28nm bulk delle apu.

@ Paolo

Ecco perchè per Amd era assolutamente necessario ripartire da zero con l'architettura e non continuare con excavator ed eventuali evoluzioni future, pur eventualmente scontando problemi di gioventù dell'architettura.

Imho il top di gamma Zen, se effettivamente sarà un x8+8, non avrà frequanze superiori ai 3ghz ed avrà un ipc simile ad Haswell.

Ah, un altra cosa che non teniamo mai in conto ma invece è fondamentale è la densità dei transistor e quindi la resa dei wafer e il numero massimo di core: Zen potrebbe essere stato ottimizzato su questo piuttosto che sulla potenza bruta, o comunque aver trovato un compromesso.

Un'architettura con alto IPC che però non consente frequenze elevate non ti mette al riparo da un PP scadente, rispetto ad un'architettura con minor IPC e maggior frequenza. In entrambi i casi devi avere un PP all'altezza, altrimenti rischi di fallire.

[Mister D]

@ MisterD: Aspetta, ciò che scrivi è esatto.
Quando però io ho scritto (ora mi è chiaro l'esempio precedente) che se un istruzione richiede 4 cicli, come esempio per semplificare, quindi 4 hertz (questo è sbagliato perché a priori non puoi sapere che 4 cicli corrispondono a 4 Hz. Questo perché 4 cicli puoi compierli in un secondo, 4/1=4 Hz o cicli al secondo, ma puoi metterci anche 4 secondi e quindi 4/4 avere una frequenza di 1 Hz. Il ticchettio del tuo orologio che frequenza ha? 1Hz semplice. Compie un ciclo, cioè il ripetersi di un secondo, in un secondo. I cicli sono un numero adimensionale, non hanno una misura. Sono il numero di volte che si ripete un qualsiasi evento.) è ovvio che se ho una frequenza di 100 hertz divido 100 per 4 e ottengo il numero di istruzioni elaborate al secondo che è 25.
Che alla fine è il numero di istruzioni al secondo (IPS) 25. Il fattore tempo non l'ho minimamente cercato. Ma è sottinteso che 25 istruzioni sono elaborate in un secondo. (attenzione che non è vero che è sottinteso in quanto appare evidente che dividere la frequenza per il numero di cicli per compiere una istruzione ottieni il numero di istruzioni compiute in un secondo. Proprio perché gli Hertz contengono l'informazione tempo non essendo altro che il tempo elevato alla -1. Analisi dimensionale per controprova del tuo esempio: 100 Hz / 4 cicli/istruzione= 100 cicli/sec * 1/4 istruzioni/cicli. I cicli si elidono e ti rimane al denominatore i secondi e al numeratore le istruzioni elaborate ergo gli IPS istruzini al secondo CVD)

Spiego meglio:
la cpu blu mi elabora una istruzione ogni 2 cicli (ogni 2 hertz no! semai IPC 1/2 istruzioni per ciclo)
La cpu rossa mi elabora la stessa istruzione ogni 4 cicli (IPC 1/4 istruzioni per ciclo)
A parità di frequenza, mettiamo 100 hertz per semplificare al massimo quale ipc è più alto?
La risposta è nella domanda chiaramente la prima cpu con 0,5 istruzioni al ciclo e non c'è bisogno di dire la frequenza per sapere quale ha IPC più alto


P.s.: errata corrige del precedente post, l'IPC è 1/4 (istruzioni/cicli) quindi 0,25 mentre 25 è il numero totale di istruzioni elaborate (al secondo), o potenza se vogliamo come scrive Paolo.

Ti ho corretto le parti in grassetto e commentato in corsivo. Scusami ma così spero comprenderai bene qual'è l'unità di misura dell'IPC. L'IPC NON sono solo i cicli ma sono le istruzioni elaborate in un ciclo. Il numero delle istruzioni è un numero adimensionale così come lo il numero dei cicli e infatti la divisione di due numeri adimensionali fanno ancora un numero adimensionale (non ha unità di misura fisica quindi) e per questo l'IPC da solo dice poco. Ci vuole la frequenza perché introduce un'unità di misura fisica fondamentale, il tempo.
La frequenza viene definita come l'inverso del tempo perché misura quante volte accadono gli eventi ripetibili/periodici nell'unità di tempo, per es le rotazioni intorno ad un asse di una cerchio, i giri di un auto su un circuito, i giri dell'albero motore (che solo per comodità nostra sono in RPM ovvero revolutions per minutes, rivoluzioni per minuto 6000 rpm corrispondono in 100 Hz) e così via.
Per questo moltiplicando al IPC la frequenza ottieni gli IPS e anche, come hai fatto tu senza sapere, dividendo la frequenza per l'inverso del IPC (i cicli cui viene elaborata una istruzione) si ottiene ancora l'IPS. Lo so, fa venire il mal di testa.
Spero che quotando te ho finalmente reso un pubblico servizio per tutti quelli che ci leggono e che ogni tanto assistono a snocciolamenti di ipotesi con numeri su IPC, frequenze e chi ne ha più ne metta :D

[el-mejo]

Anche secondo me la nuova architettura dovrà avere un IPC alto per dipendere il meno possibile dal silicio... ma dubito che a 2016 inoltrato potrebbe essere competitiva su un 28nm, credo che un buon PP sia fondamentale ugualmente.

;) ciauz

Prendevo il 28nm come esempio, ovvio che non possono fare uscire zen su un PP tra poco superato.

[Mister D]

Un'architettura con alto IPC che però non consente frequenze elevate non ti mette al riparo da un PP scadente, rispetto ad un'architettura con minor IPC e maggior frequenza. In entrambi i casi devi avere un PP all'altezza, altrimenti rischi di fallire.

QUOTO!!! ed ecco perché Tuttodigitale insiste così tanto nel dire che alla fine della fiera il maggiore responsabile del fail del progetto BD e susseguenti evoluzioni è il silicio. Chiaro se fossero riusciti a partire da un core integer con maggiore IPC allora sicuramente il silicio scadente e il fatto di aver introdotto il CMT avrebbero fatto perdere di meno. AMD nelle simulazioni (qua la colpa è di GF e chissà che ca@@o di dati ha fornito ad AMD) sulle frequenze sicuramente si aspettava di far girare il primo BD sopra i 4,5 GHz. Ora tutti a dire: a ma anche fosse stato così chissà che consumi. Errata prospettiva. Se il silicio fosse stato quello che si aspettavano il TDP non aumentava e i >4,5 GHz si sarebbe ottenuto sempre in 125 watt. All'epoca in cinebench R11 si sarebbe avuto un 1,02*1,25 in ST pari quindi a 1,27 e in MT ben 5,99*1,25=7,48 punti (ho preso i valori da anandtech e poi moltiplicato per il rapporto tra 4,5 e 3,6). Sì rispetto ad intel in single thread sarebbe stata dietro ma era una scelta di progetto di amd per recuperare in multithread grazie al CMT senza dover aver un die size enorme.
Chiaro che se avessero avuto cache migliori, preditori migliori e forse pipeline un pelo più corte avrebbero avuto migliori risultati ma con quale costo e con quale potenze? Avere più IPC vuol dire avere anche più TDP, da qualche parte l'energia la devi prendere per avere più istruzioni elaborate in un ciclo o no? Loro vedendo le simulazioni del 32 SOI rispetto all'es su 45 hanno pensato che le frequenze più alte potevano supplire l'allungamento delle pipeline e l'introduzione del CMT.
Il CMT ti da l'unita integer in più con poco spazio, peccato che questo sia vero con un pp che in un salto di nodo abbassi veramente le dimensioni del transistor. Cosa che grazie ai merdosi 32 nm di gf non è avvenuta.

Ora con Zen ammesso e non concesso che quel 40% di IPC sia vero, il problema maggiore sarà avere un silicio che permetta un'architettura ad elevato IPC senza perdere troppo in frequenza se no saremo punto a capo perché immaginate se ZEN avesse per colpa del silicio ancora una volta scarso solo 2,8 GHz in 125 watt. Basta fare due conti e scoprire che rispetto ad un FX8350 andrebbe solo il 10% in più ah ah e poi voglio vedere quelli che dicono che era giusto puntare su una architettura ad alto IPC. 2,8/4= 0,7 cioè -30% ecco che il +40% di IPC, l'IPS sarebbe simile a fovore di un modestissimo +10% rispetto all'attuale FX8350. Io mi auguro che non sia così ovviamente ma attenzione a dare la maggior parte della colpa all'architettura. Il silicio è anche ovvio che sia il principale fattore di una cpu. Ma scusate ha delle ripercussioni enormi. Un pessimo silicio ti fa stipare pochi transistor a parità di area e quindi meno IPC e poi il singolo transitor commuterà meno velocemente per cui meno frequenza o a parità di frequenza maggiori consumi che non ti fanno stipare i transistor che volevi e ottenere l'IPC che volevi.
Alla fine non so quanto sia vero dire: a ma una arch ad alto ipc ti mette al riparo da pessimi silici. Ni dipende da che frequenza/TDP avrà.:D

[tuttodigitale]

IMHO Zen, visti i trascorsi di silicio sfigato, il futuro sempre sul silicio non proprio roseo ed il fatto che Amd è una realtà fabless in balia delle offerte delle varie fonderie, sarà stato progettato da Keller per avere il più altro IPC possibile, anche e soprattutto a scapito delle frequenze massime, strettamente legate al PP utilizzato.
come detto da Isomen, una architettura con FO4 basso avrà sempre vantaggi più o meno ampi a livelli di frequenza.
AMD aveva previsto un vantaggio di circa il 30% a livello di frequenza tra BD e k10 a parità di condizioni (silicio e TDP e numero di core). Cosa che è avvenuta nel 32nm SOI. Quindi l'inadeguatezza del TDP si è fatta sentire in maniera del tutto simile sia con un architettura con basso ipc che con una a medio ipc.
Se consideriamo che il FO4 di SB è di 24 (più elevato di k10) si può solo provare a immaginare quanto basso poteva essere il clock sul 32nm SOI (o in maniera più diretta, AMD ha prodotto phenom 2 da 3,7 GHZ mentre Intel si è fermata a 3,3GHz) .

Quindi le prestazioni del silicio, condizionano pesantemente le prestazioni, ed è impensabile su due piedi dire quale architettura ne soffrirà in maniera maggiore, basandosi esclusivamente sul ipc.

Poi non possiamo far finta di trascurare che Stars non è k10, ma una sua evoluzione visto che secondo AMD in full load la "nuova" architettura permette di risparmiare il 16% in full load normalizzando il processo produttivo.
In pratica se sostituissimo i core k10 con i core Stars potremmo avere un phenom x8 da 3,3 GHz da 143W su 45nm... con l'uso di RCM tale soluzione rientrerebbe tranquillamente nei 125 di TDP

Che poi uno voglia più IPC e quant'altro, benissimo, ma a me sembra che il procio sopra sarebbe competitivo e non di certo un flop BD/CMT almeno in ambito Server e in ambito desktop MT.
concordo, ma aggiungo che l'architettura BD/PD (tanto è uguale in questo caso), rispetto a k10 (richland vs llano) fa la differenza proprio nel ST: +25% . Differenza non colmabile con RCM.
Anzi, se ci pensate la differenza nel ST, tra i modelli di punta k10 e Nehalem era proprio del 25% in cinebench. Quindi sulla carta AMD con BD, anche se con l'aiuto di RCM, avrebbe raggiunto Nehalem. Quindi BD starebbe a un -20% da Haswell. In pratica oggi a livello di architettura il gap nel ST (haswell vs steamroller), si sarebbe ridotto del 40%.

E ancora una volta è utile ripetere che le differenze esistenti tra Stars e PD con RCM sono circa equivalenti a quelle esistenti tra k10 e PD senza RCM (errore di approssimazione del 3%)

[Free Gordon]

piuttosto

http://www.bitsandchips.it/9-hardware/6065-il-team-di-austin-e-fiducioso-su-zen-e-sul-futuro-di-amd


Forza Keller!!! :cincin: :winner: :yeah:

[george_p]

Un'architettura con alto IPC che però non consente frequenze elevate non ti mette al riparo da un PP scadente, rispetto ad un'architettura con minor IPC e maggior frequenza. In entrambi i casi devi avere un PP all'altezza, altrimenti rischi di fallire.

Questo è decisamente un altro scenario che definirei estremo alla parte opposta.



Ti ho corretto le parti in grassetto e commentato in corsivo. Scusami ma così spero comprenderai bene qual'è l'unità di misura dell'IPC. L'IPC NON sono solo i cicli ma sono le istruzioni elaborate in un ciclo. Il numero delle istruzioni è un numero adimensionale così come lo il numero dei cicli e infatti la divisione di due numeri adimensionali fanno ancora un numero adimensionale (non ha unità di misura fisica quindi) e per questo l'IPC da solo dice poco. Ci vuole la frequenza perché introduce un'unità di misura fisica fondamentale, il tempo.
La frequenza viene definita come l'inverso del tempo perché misura quante volte accadono gli eventi ripetibili/periodici nell'unità di tempo, per es le rotazioni intorno ad un asse di una cerchio, i giri di un auto su un circuito, i giri dell'albero motore (che solo per comodità nostra sono in RPM ovvero revolutions per minutes, rivoluzioni per minuto 6000 rpm corrispondono in 100 Hz) e così via.
Per questo moltiplicando al IPC la frequenza ottieni gli IPS e anche, come hai fatto tu senza sapere, dividendo la frequenza per l'inverso del IPC (i cicli cui viene elaborata una istruzione) si ottiene ancora l'IPS. Lo so, fa venire il mal di testa.
Spero che quotando te ho finalmente reso un pubblico servizio per tutti quelli che ci leggono e che ogni tanto assistono a snocciolamenti di ipotesi con numeri su IPC, frequenze e chi ne ha più ne metta :D

Si, sei decisamente molto più preparato e tecnico di me ma è stato uno scambio molto interessante anche perché mi ha dato l'opportunità di riprendere i ragionamenti sul funzionamento di questa parte del processore, che sebbene possa importare poco da un punto di vista più "pratico" a me piace conoscere almeno in minima parte.
Però trovo lo stesso dire "elabora una istruzione ogni 2 cicli" e "1/2 istruzioni per ciclo"?
In un mio libro vecchio di almeno 14 anni spiega che una istruzione poteva impiegare più cicli di clock (si parla di 14 anni fa e quindi processori di riferimento molto più "semplici" e lenti rispetto a oggi) e questo naturalmente per il periodo era un pò limitante.
Penso risolta con l'introduzione delle pipeline per elaborazione parallela.

Intanto grazie perché è servito anche a me :D

[shellx]

https://www.youtube.com/watch?v=SOTFE7sJY-Q

[george_p]

@tuttodigitale:
Per il -50% di tdp mi riferivo al 32 nm funzionante non al 45 nm ma vado a memoria e potrei sbagliarmi.

Infine per rispondere anche a MisterD nel suo ultimo post dove ti "supporta" più di me (non me ne volere, è il mio pensiero) personalmente mi metto più dalla parte di AMD che dalla parte di water-glofo dove quest'ultima la vedo totalmente incapace di tirar fuori un silicio decente, ne ha azzeccato uno per sbaglio con il 45 nm e basta.

Mettendomi dal punto di vista di amd lavorerei meglio sull'efficienza di una architettura così da renderla flessibile e migliorabile nel tempo ma un minimo meno dipendente dal tipo di miniaturizzazione, quest'ultima cosa non è cosa assai assoluta ma ribadisco una migliore progettazione architetturale.

Io ritengo che una nuova architettura sullo stesso 45 nm debba in parte consumare meno della precedente architettura e a parità di frequenza avere almeno (mi rovino) lo stesso IPC (a core naturalmente) se non più alto.

In BD hanno potenziato si le FPU ma diamine dai, lo hai visto pure tu che in cinebench ad es dove viene sfruttato proprio quella parte non va più del vecchio K10.
Nei forum che bazzico e bazzicavo anni addietro, relativi a grafica 3D non si cagano proprio più le cpu amd e nel 99% si usa la fascia altissima.

[Mister D]

Questo è decisamente un altro scenario che definirei estremo alla parte opposta.





Si, sei decisamente molto più preparato e tecnico di me ma è stato uno scambio molto interessante anche perché mi ha dato l'opportunità di riprendere i ragionamenti sul funzionamento di questa parte del processore, che sebbene possa importare poco da un punto di vista più "pratico" a me piace conoscere almeno in minima parte.
Però trovo lo stesso dire "elabora una istruzione ogni 2 cicli" e "1/2 istruzioni per ciclo"?
In un mio libro vecchio di almeno 14 anni spiega che una istruzione poteva impiegare più cicli di clock (si parla di 14 anni fa e quindi processori di riferimento molto più "semplici" e lenti rispetto a oggi) e questo naturalmente per il periodo era un pò limitante.
Penso risolta con l'introduzione delle pipeline per elaborazione parallela.

Intanto grazie perché è servito anche a me :D

Intanto ti ringrazio per avermi fatto quel complimento. (semplicemente sono più afferrato in matematica e fisica e per cui districarmi tra unità di misura e analisi dimensionali per me è più semplice).
Alla tua domanda è sì. Ovviamente in quanto, come ti ho scritto prima, tu hai fatto l'inverso del IPC. Invertire un rapporto è sempre possibile e il significato è il medesimo. Cambia ovviamente solo il numero che rappresenta tale rapporto. E il libro di 14 anni fa non è mica superato. Ovviamente una cpu che processa una istruzione impiegando 4 cicli invece che 2 è più lenta e per verificare basta fare l'inverso di cicli/istruzione per ottenere il famoso IPC. 4/1-> 1/4=0,25 e l'altra 2/1-> 1/2=0,5 e chiaramente 0,5>0,25. CVD.
A me ha fatto solo piacere rispolverare qualche (banale per me) calcolo;)
L'elaborazione parallela chiaramente permette di elaborare più istruzioni contemporaneamente ma altrettanto chiaramente l'IPC rimane uguale e questo nei benchmark viene fuori. Un dual core va il doppio di un single core su stessa architettura in presenza di software dove si può parallelizzare il calcolo altrimenti se non si può l'ipc sarà il medesimo e il risultato sarà identico (qualche lieve differenza nella realtà ci sarà a favore del dual core solo perché il secondo core potrà elaborare altri processi in backgruond che nel single core ricadono cmq su di lui). Tutto torna, non ti pare?;)

[george_p]

https://www.youtube.com/watch?v=SOTFE7sJY-Q

Speravo fosse nuova e relativa alla fine del suo contratto.

[george_p]

Intanto ti ringrazio per avermi fatto quel complimento. (semplicemente sono più afferrato in matematica e fisica e per cui districarmi tra unità di misura e analisi dimensionali per me è più semplice).
Alla tua domanda è sì. Ovviamente in quanto, come ti ho scritto prima, tu hai fatto l'inverso del IPC. Invertire un rapporto è sempre possibile e il significato è il medesimo. Cambia ovviamente solo il numero che rappresenta tale rapporto. E il libro di 14 anni fa non è mica superato. Ovviamente una cpu che processa una istruzione impiegando 4 cicli invece che 2 è più lenta e per verificare basta fare l'inverso di cicli/istruzione per ottenere il famoso IPC. 4/1-> 1/4=0,25 e l'altra 2/1-> 1/2=0,5 e chiaramente 0,5>0,25. CVD.
A me ha fatto solo piacere rispolverare qualche (banale per me) calcolo;)
L'elaborazione parallela chiaramente permette di elaborare più istruzioni contemporaneamente ma altrettanto chiaramente l'IPC rimane uguale e questo nei benchmark viene fuori. Un dual core va il doppio di un single core su stessa architettura in presenza di software dove si può parallelizzare il calcolo altrimenti se non si può l'ipc sarà il medesimo e il risultato sarà identico (qualche lieve differenza nella realtà ci sarà a favore del dual core solo perché il secondo core potrà elaborare altri processi in backgruond che nel single core ricadono cmq su di lui). Tutto torna, non ti pare?;)

Scusa, per elaborazione parallela intendevo riferito all'istruzione con l'uso delle pipeline.
Comunque mi stavo disintegrando nell'etere quando ho letto inizialmente la parola adimensionale, causa cottura a un certo punto avevo bisogno di una pipeline anche io con tutti questi calcoli :D

P.s.: Possiamo non parlare di ipc per un pò?? :D

[Mister D]

@tuttodigitale:
Per il -50% di tdp mi riferivo al 32 nm funzionante non al 45 nm ma vado a memoria e potrei sbagliarmi.

Infine per rispondere anche a MisterD nel suo ultimo post dove ti "supporta" più di me (non me ne volere, è il mio pensiero) personalmente mi metto più dalla parte di AMD che dalla parte di water-glofo dove quest'ultima la vedo totalmente incapace di tirar fuori un silicio decente, ne ha azzeccato uno per sbaglio con il 45 nm e basta.

Mettendomi dal punto di vista di amd lavorerei meglio sull'efficienza di una architettura così da renderla flessibile e migliorabile nel tempo ma un minimo meno dipendente dal tipo di miniaturizzazione, quest'ultima cosa non è cosa assai assoluta ma ribadisco una migliore progettazione architetturale.

Io ritengo che una nuova architettura sullo stesso 45 nm debba in parte consumare meno della precedente architettura e a parità di frequenza avere almeno (mi rovino) lo stesso IPC (a core naturalmente) se non più alto.

In BD hanno potenziato si le FPU ma diamine dai, lo hai visto pure tu che in cinebench ad es dove viene sfruttato proprio quella parte non va più del vecchio K10.
Nei forum che bazzico e bazzicavo anni addietro, relativi a grafica 3D non si cagano proprio più le cpu amd e nel 99% si usa la fascia altissima.

Ti quoto perché hai ragione che si dovrebbe far così, ma dove casca l'asino? semplicemente perché anche progettando la miglior architettura (più ipc a parità di frequenza, minori consumi a parità di frequenza, minor die size, ecc) il silicio scarso potrebbe non permettere tali caratteristiche. Mi spiego meglio riprendendo l'altro post quote di un altro utente.
Se ZEN sarà tanto superiore ma avrà un silicio scarso saremo nelle stesse condizioni perché quello guadagnato in IPC lo perderà in frequenza rispetto agli FX e alla fine il prodotto IPC*freq (IPS) sarà il medesimo.
Non c'è un ergo deduttivo del tipo basso IPC ->scarso silicio e alto IPC -> ottimo silicio. Può capitare anche orientandosi su una architettura ad alto ipc di beccare il silicio pessimo che si mangi le varie migliore. è già succceso. I 65 nm vs 90 nm e gli athlon 64 x2 a 90 vs athlon 64 x2 a 65 nm. E lì era una architettura ad alto IPC.
Intel solo oggi mostra i primi semi-fail perché nonostante il progressivo aumento di IPC (chiaramente a piccoli passi e solo in alcuni casi a passi più grandi) se lo mangia perché gli ultimi silici non sono venuti bene quanto i 45 e i 32.
Keller cmq non sbaglia a puntare su un'aumento di IPC perché finché non verranno cambiati i metodi produttivi del silicio (nuovi materiali o nuovi metodi litografici) il progressivo scendere di nodi sarà sempre più difficile, costoso e non è detto che assicuri i benefici sperati (vedi i 14 finfet di intel);) Tanto vale puntare da subito su quello di cui posso avere controllo, l'IPC (architettura) e poi sperare che la frequenza e in misura minore l'IPC possano essere adeguati a quanto progettato (silicio).

[Mister D]

Scusa, per elaborazione parallela intendevo riferito all'istruzione con l'uso delle pipeline.
Comunque mi stavo disintegrando nell'etere quando ho letto inizialmente la parola adimensionale, causa cottura a un certo punto avevo bisogno di una pipeline anche io con tutti questi calcoli :D

P.s.: Possiamo non parlare di ipc per un pò?? :D

Lo sapevo che la parola adimensionale avrebbe fatto stallare la pipeline. Dai vorrà dire che la prossima volta userai una architettura SMT :sofico:
Ok togliamo l'IPC e parliamo di potenza elaborativa in via generale e vaffa:sofico:
Ops sei arrivato tardi perché nel post dopo IPC è largamente usato. Direi che in questo thread di IPC si fa un uso generoso (o forse no? ah ah ah:sofico: )

[Mister D]

Speravo fosse nuova e relativa alla fine del suo contratto.

Una battuta per ridere: ma hai visto keller come è bello palestrato? Cioè mi aspettavo un nerdissimo con gli occhiali fondo di bottiglia e invece no :sofico:
Chissà che non sia questo il segreto delle sue cpu! Tutta forza bruta e muscoli ah ah ah ah ah:D :sofico:

[george_p]

Lo sapevo che la parola adimensionale avrebbe fatto stallare la pipeline. Dai vorrà dire che la prossima volta userai una architettura SMT :sofico:
Ok togliamo l'IPC e parliamo di potenza elaborativa in via generale e vaffa:sofico:
Ops sei arrivato tardi perché nel post dopo IPC è largamente usato. Direi che in questo thread di IPC si fa un uso generoso (o forse no? ah ah ah:sofico: )

Ok, uso l'opzione SMT e SMeTto tutte le funzioni vitali per oggi, domani riavvio il SO :D
Andrei in crash totale diversamente ;)

[george_p]

Una battuta per ridere: ma hai visto keller come è bello palestrato? Cioè mi aspettavo un nerdissimo con gli occhiali fondo di bottiglia e invece no :sofico:
Chissà che non sia questo il segreto delle sue cpu! Tutta forza bruta e muscoli ah ah ah ah ah:D :sofico:

Si l'ho notato mesi fa in quel video postato prima da Shellx. Fa bene a coltivare anche il fisico assieme ai neuroni se no scoppia come una lampadina con tutto quello che ha in testa :cool:

[davo30]

Keller cmq non sbaglia a puntare su un'aumento di IPC perché finché non verranno cambiati i metodi produttivi del silicio (nuovi materiali o nuovi metodi litografici) il progressivo scendere di nodi sarà sempre più difficile, costoso e non è detto che assicuri i benefici sperati (vedi i 14 finfet di intel);) Tanto vale puntare da subito su quello di cui posso avere controllo, l'IPC (architettura) e poi sperare che la frequenza e in misura minore l'IPC possano essere adeguati a quanto progettato (silicio).

Straquoto. Per me è proprio questo il punto e il problema di BD. Tanto per capire, non è un segreto che intel abbia avuto enormi problemi con i 14nm, basta vedere le frequenze def di un 6400 per rendersene conto. Avendo pero un'architettura competitiva a priori, puo permettersi utilizzare processi mediocri quali i 14nm. Questo pero AMD non poteva e non doveva permetterselo per 2 motivi: a) AMD non ha piu il diretto controllo delle fonderie b) non ha i soldi per permettersi rimandi e cambi in corsa stile broadwell e haswell-refresh. Speriamo che con Zen abbia capito e non commetta piu l'errore di "sperare" in processi super-perfetti da parte delle fonderie.

[Mister D]

Si l'ho notato mesi fa in quel video postato prima da Shellx. Fa bene a coltivare anche il fisico assieme ai neuroni se no scoppia come una lampadina con tutto quello che ha in testa :cool:

Come dicevano i latini: Mens sana in corpore sano:D Lui li ha tutte e due e fa bene, non c'è dubbio:cool:

[tuttodigitale]

Questo è decisamente un altro scenario che definirei estremo alla parte opposta.

sono due estremi che non si autoescludono. In alcuni casi architetture molto diverse tra loro possono riscontrare talvolta le stesse limitazioni a livello di prestazione, altre no. E' fondamentale quando si progetta un'architettura conoscere le possibilità e limiti del processo produttivo. E qui nascono i problemi: un'architettura viene concepita almeno un paio d'anni prima che effettivamente il silicio sia pronto. Si tratta di fare previsioni, e come tali possono portare risultati aberranti .

AMD ha pianificato BD con l'intento di produrre la migliore architettura per i 32nm i 28nm FD-soi, con i 45nm come silicio di transizione (vantaggi minimi). E possa piacere o no, hanno trovato nella condivisione delle risorse e in bulldozer una buona soluzione, sulla carta ovviamente.
Se AMD avesse avuto informazioni più veritiere sulle caratteristiche del 32nm SOI probabilmente avrebbe prodotto altro (uso il condizionale, perchè nessuno ad oggi può escludere il fatto che BD/PD siano architetture ottime per questo 32nm).

A proposito di silicio e architettura. Un parametro a dir poco fondamentale, il FO4, viene scelto proprio in base al silicio. Il FO4 determina in maniera diretta la complessità del singolo stadio all'interno di una pipeline, il motivo banale, sta proprio nel poco tempo dato a disposizione (in fase di progetto) al singolo stadio di fare i propri "comodi".
Sulla carta, BD ha limiti di clock superiori del 40% rispetto a SB. Visto che nello studio IBM è uscito proprio il FO4 usato da AMD per BD (non è un caso) vuol dire che si pensava che effettivamente certe frequenze potevano essere raggiunte, quantomeno in turbo mode (sennò che senso avrebbe scomporre le pipeline in un numero maggior di stadi?).
Probabilmente i 5,5GHz erano il target per quanto riguarda la frequenza turbo.

PS faccio notare che numero di stadi e FO4 non siano necessariamente correlati con una relazione di proporzionalità inversa.


Però trovo lo stesso dire "elabora una istruzione ogni 2 cicli" e "1/2 istruzioni per ciclo"?
In un mio libro vecchio di almeno 14 anni spiega che una istruzione poteva impiegare più cicli di clock (si parla di 14 anni fa e quindi processori di riferimento molto più "semplici" e lenti rispetto a oggi) e questo naturalmente per il periodo era un pò limitante.
Penso risolta con l'introduzione delle pipeline per elaborazione parallela.

Aspetta nelle cpu a ciclo unico, le istruzione più complesse impiegano lo stesso tempo di quelle più veloci. E' con le pipeline che le istruzioni hanno un diverso peso in termini di cicli.
Risolta? Non credo proprio :D

PS usualmente si dice che una istruzione impiega tot cicli. Anche perchè 1/2 istruzione di per sé è un concetto privo di significato.

[tuttodigitale]

Si l'ho notato mesi fa in quel video postato prima da Shellx. Fa bene a coltivare anche il fisico assieme ai neuroni se no scoppia come una lampadina con tutto quello che ha in testa :cool:
E no, deve pensare solo a fare LA cpu. Me lo aspettavo deperito. Invece è sempre più in forma :eek:
Che ZEN sia una cpu MUSCOLOSA?

Speravo fosse nuova e relativa alla fine del suo contratto.

Bene bene. C'è speranza che abbia dedicato notte e giorno a Zen. :D

[el-mejo]

però se posso aggiungere un passaggio, un silicio scarso non comporta soltanto una bassa frequenza, ma può portare anch'esso ad un basso IPC o simile a quello dell'architettura precedente.

come mi sembra abbiano detto @Paolo e/o @Mister D, Intel riesce a stipare più transistor per ogni mmq o comunque avendo una miniaturizzazione più spinta più transistor a parità di area occupata (il che vuol dire maggior IPC detto terra terra).

si progetta la cpu ma si deve già sapere a grandi linee a che livello di integrazione si può arrivare a mmq per aumentarne l'IPC e che incidenza esso avrà nel TDP e nella richiesta di energia.

perché è stato modificato il core di SR slittando di 6 mesi i tempi per produrlo sul 28nm?
perché la bassa integrazione di transistor rispetto alle previsioni non permetteva l'aumento di IPC corposo senza aumentarne l'area occupata
perché solo come APU?
perché le basse frequenze per competere contro l'8350 a 4ghz l'avrebbero penalizzato vanificando il tutto
perché non è stato fatto Ex sul 32/28nm?
perché il 32/28nm non permetteva un aumento di IPC se non con un aumento dell'area occupata o che a parità di mmq occupato non riesci ad aumentarne i transistor, con il conseguente aumento ulteriore del TDP
perché è stato fatto Ex sul 28nm ma solo a basso TDP?
perché le HDL si possono utilizzare entro determinate frequenze e TDP di esercizio

In linea di massimo hai ragione, ma ricorda che Carizzo ha la metà di cache l2, pur avendo un buon aumento di ipc rispetto a Piledrive.
A volte l'affinamento di un architettura si effettua proprio ottimizzando la stessa, come con l'ultima generazione di gpu.

La verità è molto più semplice: non c'erano più soldi!:(

[davo30]

La verità è molto più semplice: non c'erano più soldi!:(

In realtà non penso sia stato quello il problema principale, ma quelli detti da grid. Ti assicuro che non presentando nessun FX negli ultimi 3 anni AMD ha perso veramente tanti soldi

[paolo.oliva2]

Un'architettura con alto IPC che però non consente frequenze elevate non ti mette al riparo da un PP scadente, rispetto ad un'architettura con minor IPC e maggior frequenza. In entrambi i casi devi avere un PP all'altezza, altrimenti rischi di fallire.

Quoto.

Il silicio ha 3 caratteristiche:
Frequenza massima in rapporto ai consumi
Leakage o perdita di corrente in rapporto al numero di transistor
Costo del wafer in rapporto al numero dei die e al numero dei fallati.

Nessuno obbietta che all'aumentare della frequenza qualsiasi silicio diminuisca l'efficienza, però è anche vero che ogni architettura ha una sua efficienza in base al TDP creato che è simile nel limite alla frequenza.
Infatti Steamroller ne è l'esempio, al 10% di incremento IPC si è segato il 10% di frequenza, probabilmente perché il silicio ha un limite TDP simile all'aumento dei consumi in base alla frequenza (aumentare l'IPC aumenta le istruzioni al secondo e quindi più transistor che cambiano stato).
Secondo me, il Leakage forse diminuisce all'aumentare della miniaturizzazione, e se così fosse si avrebbe tipo un effetto simile a quando si è passati dal monofore a più core.

Comunque attenzione, ad una cosa: se già oggi fosse possibile un FX con base Excavator, non sarebbe poi richiesta chissà quale frequenza.
Oggi siamo a 100 AMD e 175 Intel (prendo per buono quanto postato), ma con un Excavator FX avremmo +20/25% di IPC, quindi:

120 AMD +80% CMT 2°TH = 216
175 Intel +30% SMT = 227,5

Se AMD ricevesse un silicio con un PP degno, lbasterebbe riuscire ad ottenere un numeto di moduli uguale al numero di core + SMT, e non necessiterebbe dii frequenze superiori per ottenere un MT decente. Poi sarei dell'opinione che con BD (e potrebbe essere anche Zen con core Excavator), si potrebbe scroccare un po' la frequenza turbo per ottenere almeno 500MHz in più di Intel per arrivare a circa 30% di forza bruta inferiore ad Intel.

[el-mejo]

In realtà non penso sia stato quello il problema principale, ma quelli detti da grid. Ti assicuro che non presentando nessun FX negli ultimi 3 anni AMD ha perso veramente tanti soldi

Ma anche no perchè il 28nm bulk non permetterà frequenze superiori rispetto al 32nm SOI ( che poi a breve uscirà una apu a 4,1ghz, quindi anche quello non è del tutto vero), ma ha una densità di transistor superiore, basta vedere trinity vs kaveri, oltre che un tdp leggermente inferiore a parità di prestazioni.

Avrebbe fatto schifo un ipotetico fx 8550 @ 3,7ghz @ 110w tdp, il tutto con una superfice di die inferiori e quindi maggiori margini per AMD o a scelta una politica dei prezzi più aggressiva, il tutto con la possibilità di produrre un eventuale 6 moduli, sulla falsa riga dei vecchi Phenom II x6 Thuban, capace di ridare ossigeno al mercato server e soprattutto a dare credibilità all'azienda per il futuro ditorno di Zen nella fascia alta server?

Oltre che alle poche finanze, mi viene da pensare al timore di fare castronerie con un nuovo PP bulk, dopo anni di esperienza sul SOI: forse è questo il vero motivo.

[george_p]

Ti quoto perché hai ragione che si dovrebbe far così, ma dove casca l'asino? semplicemente perché anche progettando la miglior architettura (più ipc a parità di frequenza, minori consumi a parità di frequenza, minor die size, ecc) il silicio scarso potrebbe non permettere tali caratteristiche. Mi spiego meglio riprendendo l'altro post quote di un altro utente.
Se ZEN sarà tanto superiore ma avrà un silicio scarso saremo nelle stesse condizioni perché quello guadagnato in IPC lo perderà in frequenza rispetto agli FX e alla fine il prodotto IPC*freq (IPS) sarà il medesimo.
Non c'è un ergo deduttivo del tipo basso IPC ->scarso silicio e alto IPC -> ottimo silicio. Può capitare anche orientandosi su una architettura ad alto ipc di beccare il silicio pessimo che si mangi le varie migliore. è già succceso. I 65 nm vs 90 nm e gli athlon 64 x2 a 90 vs athlon 64 x2 a 65 nm. E lì era una architettura ad alto IPC.
Intel solo oggi mostra i primi semi-fail perché nonostante il progressivo aumento di IPC (chiaramente a piccoli passi e solo in alcuni casi a passi più grandi) se lo mangia perché gli ultimi silici non sono venuti bene quanto i 45 e i 32.
Keller cmq non sbaglia a puntare su un'aumento di IPC perché finché non verranno cambiati i metodi produttivi del silicio (nuovi materiali o nuovi metodi litografici) il progressivo scendere di nodi sarà sempre più difficile, costoso e non è detto che assicuri i benefici sperati (vedi i 14 finfet di intel);) Tanto vale puntare da subito su quello di cui posso avere controllo, l'IPC (architettura) e poi sperare che la frequenza e in misura minore l'IPC possano essere adeguati a quanto progettato (silicio).

Questa frase in neretto racchiude proprio il mio pensiero per le discussioni degli ultimi post.
In aggiunta AMD pensi a staccarsi da water-glofo e andare al miglior offerente di silicio.

[george_p]

sono due estremi che non si autoescludono. In alcuni casi architetture molto diverse tra loro possono riscontrare talvolta le stesse limitazioni a livello di prestazione, altre no. E' fondamentale quando si progetta un'architettura conoscere le possibilità e limiti del processo produttivo. E qui nascono i problemi: un'architettura viene concepita almeno un paio d'anni prima che effettivamente il silicio sia pronto. Si tratta di fare previsioni, e come tali possono portare risultati aberranti .

AMD ha pianificato BD con l'intento di produrre la migliore architettura per i 32nm i 28nm FD-soi, con i 45nm come silicio di transizione (vantaggi minimi). E possa piacere o no, hanno trovato nella condivisione delle risorse e in bulldozer una buona soluzione, sulla carta ovviamente.
Se AMD avesse avuto informazioni più veritiere sulle caratteristiche del 32nm SOI probabilmente avrebbe prodotto altro (uso il condizionale, perchè nessuno ad oggi può escludere il fatto che BD/PD siano architetture ottime per questo 32nm).

A proposito di silicio e architettura. Un parametro a dir poco fondamentale, il FO4, viene scelto proprio in base al silicio. Il FO4 determina in maniera diretta la complessità del singolo stadio all'interno di una pipeline, il motivo banale, sta proprio nel poco tempo dato a disposizione (in fase di progetto) al singolo stadio di fare i propri "comodi".
Sulla carta, BD ha limiti di clock superiori del 40% rispetto a SB. Visto che nello studio IBM è uscito proprio il FO4 usato da AMD per BD (non è un caso) vuol dire che si pensava che effettivamente certe frequenze potevano essere raggiunte, quantomeno in turbo mode (sennò che senso avrebbe scomporre le pipeline in un numero maggior di stadi?).
Probabilmente i 5,5GHz erano il target per quanto riguarda la frequenza turbo.

PS faccio notare che numero di stadi e FO4 non siano necessariamente correlati con una relazione di proporzionalità inversa.


Aspetta nelle cpu a ciclo unico, le istruzione più complesse impiegano lo stesso tempo di quelle più veloci. E' con le pipeline che le istruzioni hanno un diverso peso in termini di cicli.
Risolta? Non credo proprio :D



Anche per quello penso da tempo che sia utile progettare una cpu poco dipendente dal silicio. E soprattutto da quello di water-glofo.



PS usualmente si dice che una istruzione impiega tot cicli. Anche perchè 1/2 istruzione di per sé è un concetto privo di significato.

Effettivamente :doh:
:D

[george_p]

E no, deve pensare solo a fare LA cpu. Me lo aspettavo deperito. Invece è sempre più in forma :eek:
Che ZEN sia una cpu MUSCOLOSA?



Bene bene. C'è speranza che abbia dedicato notte e giorno a Zen. :D

Una cosa interessante è l'articolo sull'intervista del team di Austin pubblicato da B&C.
Hanno lavorato duro ma completamente con carta bianca dove probabilmente Keller e soci hanno potuto dare il meglio di sé senza vincoli e limitazioni di alcun tipo. Unicamente per sfornare il meglio del top.

Poi saremo noi i collaudatori e critici :D

[paolo.oliva2]

Posso chiedere un parete?

Zen dovrebbe avere un IPC superiore del 40% rispetto a EX, quindi per facilità inquadrerei un +40% di TDP rispetto ad EX.

Il modulo EX 100 a core e 25% per il CMT darebbe 150.
Zen darebbe 140 a cui si aggiungerebbe tutta la parte SMT.

Dove sarebbe il guadagno FI minor consumo (ipotizzando nuovo silicio su cui realizzare EX o Zen?.

2 core Zen sarebbero 280 + tutta la parte SMT vs un EX che sarebbe 300 e comunque più potente in MT.

[epimerasi]

Ti quoto perché hai ragione che si dovrebbe far così, ma dove casca l'asino? semplicemente perché anche progettando la miglior architettura (più ipc a parità di frequenza, minori consumi a parità di frequenza, minor die size, ecc) il silicio scarso potrebbe non permettere tali caratteristiche. Mi spiego meglio riprendendo l'altro post quote di un altro utente.
Se ZEN sarà tanto superiore ma avrà un silicio scarso saremo nelle stesse condizioni perché quello guadagnato in IPC lo perderà in frequenza rispetto agli FX e alla fine il prodotto IPC*freq (IPS) sarà il medesimo.
Non c'è un ergo deduttivo del tipo basso IPC ->scarso silicio e alto IPC -> ottimo silicio. Può capitare anche orientandosi su una architettura ad alto ipc di beccare il silicio pessimo che si mangi le varie migliore. è già succceso. I 65 nm vs 90 nm e gli athlon 64 x2 a 90 vs athlon 64 x2 a 65 nm. E lì era una architettura ad alto IPC.
Intel solo oggi mostra i primi semi-fail perché nonostante il progressivo aumento di IPC (chiaramente a piccoli passi e solo in alcuni casi a passi più grandi) se lo mangia perché gli ultimi silici non sono venuti bene quanto i 45 e i 32.
Keller cmq non sbaglia a puntare su un'aumento di IPC perché finché non verranno cambiati i metodi produttivi del silicio (nuovi materiali o nuovi metodi litografici) il progressivo scendere di nodi sarà sempre più difficile, costoso e non è detto che assicuri i benefici sperati (vedi i 14 finfet di intel);) Tanto vale puntare da subito su quello di cui posso avere controllo, l'IPC (architettura) e poi sperare che la frequenza e in misura minore l'IPC possano essere adeguati a quanto progettato (silicio).

e` una conseguenza del finfet una diminuizione delle frequenze massime raggiungibili
ed e` u problema che dovra` affrontare anche ZEN visto che dalle ultime dovrebbe un processo finfet

[Mister D]

e` una conseguenza del finfet una diminuizione delle frequenze massime raggiungibili
ed e` u problema che dovra` affrontare anche ZEN visto che dalle ultime dovrebbe un processo finfet

Ciao,
è una tua ipotesi oppure lo hai letto da qualche parte perché mi sono salvato una presentazione in powerpoint di IBM sui tipi di finfet (noi conosciamo solo la versione semplice in cui si hanno 3 superfici che fanno da gate ma esistono altre versioni veramente esotiche xd) che spiega come l'introduzione del finfet abbassa il leakage e quindi a parità di TPD si ottiene maggiore frequenza o a parità di frequenza minor TDP, in pratica una curva frequenza/tensione spostata equivalente ad un seminodo. Ora non mi ricordo se era il finfet su SOI o su bulk. Se in privato mi dai una mail te al invio, molto interessante. Ovvio è tutto in inglese:D

[tuttodigitale]

@MisterD non è proprio vero che i 14nm e i 22nm di Intel non hanno portato miglioramenti, o meglio questo sarebbe vero se nell'analisi, non consideriamo il livello di integrazione raggiunto (se non sbaglio la parte x86 di un quad core Haswell misura solo 70 mmq), le prestazioni, inteso come riduzione del TDP, da 3GHz in giù.
Prendiamo come esempio le cpu low voltage:
32 nm 1,8 - 2,9 (17W)
22 nm 1,8 - 3,2GHz (-12% di TDP, +10% turbo)
14nm 2,2-3,2GHz (+22% base)
i miglioramenti ci sono, è innegabile.
Anche in OC, skylake non si comporta affato male.

XEON
32 nm SB 8 core a 2,9 GHz 135W
22nm IB 10 core a 3 GHz 130W
efficienza +35%, senza considerare l'aumento di ipc.
o ancora 12 core a 2,7 GHz sempre a 130W.

o
32 nm SB 8 core 3,1 GHz 150W
22nm IB 15 core 2,8GHz 155W

i miglioramenti son netti.

[Mister D]

@MisterD non è proprio vero che i 14nm di Intel no hanno portato miglioramenti, o meglio questo sarebbe vero se nell'analisi, non consideriamo il livello di integrazione raggiunto (se non sbaglio la parte x86 di un quad core Haswell misura solo 70 mmq), le prestazioni, inteso come riduzione del TDP, da 3GHz in giù.
Prendiamo come esempio le cpu low voltage:
32 nm 1,8 - 2,9 (17W)
22 nm 1,8 - 3,2GHz (-12% di TDP, +10% turbo)
14nm 2,2-3,2GHz (+22% base)
i miglioramenti ci sono, è innegabile.
Anche in OC, skylake non si comporta affato male.

XEON
32 nm SB 8 core a 2,9 GHz 135W
22nm IB 10 core a 3 GHz 130W
efficienza +35%, senza considerare l'aumento di ipc.

Ciao,
allora per le cpu low-voltage è innegabile che abbia portato dei miglioramenti (un po' come il 28 bulk di GF per carizzo e amd lì ci ha messo del suo per aumentare l'efficienza) ma non sulle frequenze desktop.
Ti linko un mio post sul thread di skylake in cui ho fatto vedere il confronto dell'oc prendendo la recensione di anandtech su haswell refresh e skylake e vedrai che skylake si comporta uguale se non peggio di haswell refresh:
http://www.hwupgrade.it/forum/showpost.php?p=42744167&postcount=132
Basta che ti guardi le tabelle contenute nei due articoli di anand per vedere che lo scaling è uguale o peggiore per skylake.
A parte questo, le recensioni di anand le trovo complete e mettono in luce l'andamento dell'IPC e i vari guadagni in frequenza dai sandybridge in poi. Una delle recensioni più complete che abbia mai visto.;)

[FazzoMetal]

Posso chiedere un parete?

Zen dovrebbe avere un IPC superiore del 40% rispetto a EX, quindi per facilità inquadrerei un +40% di TDP rispetto ad EX.

Il modulo EX 100 a core e 25% per il CMT darebbe 150.
Zen darebbe 140 a cui si aggiungerebbe tutta la parte SMT.

Dove sarebbe il guadagno FI minor consumo (ipotizzando nuovo silicio su cui realizzare EX o Zen?.


Come avevo già scritto non c'è nessuna legge che dice che IPC e TDP sono proporzionali, per cui non ha senso dire che IPC +40% --> TDP +40% a parità di condizioni. A parità di silicio (e a parità di frequenza) 2 architetture differenti possono offrire 2 IPC completamente diversi con lo stesso TDP. E' qui che fa la differenza il progettista architetturale.

[Dre@mwe@ver]

Come avevo già scritto non c'è nessuna legge che dice che IPC e TDP sono proporzionali, per cui non ha senso dire che IPC +40% --> TDP +40% a parità di condizioni. A parità di silicio (e a parità di frequenza) 2 architetture differenti possono offrire 2 IPC completamente diversi con lo stesso TDP. E' qui che fa la differenza il progettista architetturale.

Infatti, secondo il ragionamento di Paolo i processori Intel dovrebbero avere un TDP stratosferico. Per fortuna non é così e spero che Zen se la giochi alla grande (ho un Phenom II 955 che aspetta un degno successore). IMHO un'architettura classica SMT ad alto IPC é preferibile, soprattutto per AMD, dato che é un approccio più collaudato.

[davo30]

Infatti, secondo il ragionamento di Paolo i processori Intel dovrebbero avere un TDP stratosferico. Per fortuna non é così e spero che Zen se la giochi alla grande (ho un Phenom II 955 che aspetta un degno successore). IMHO un'architettura classica SMT ad alto IPC é preferibile, soprattutto per AMD, dato che é un approccio più collaudato.
E soprattutto meno dipendente dalla bontà del silicio. Cosa fondamentale per AMD (e water-glofo)

Inviato dal mio XT1092 utilizzando Tapatalk

[paolo.oliva2]

Come avevo già scritto non c'è nessuna legge che dice che IPC e TDP sono proporzionali, per cui non ha senso dire che IPC +40% --> TDP +40% a parità di condizioni. A parità di silicio (e a parità di frequenza) 2 architetture differenti possono offrire 2 IPC completamente diversi con lo stesso TDP. E' qui che fa la differenza il progettista architetturale.

Quello che dici è più che giusto, però trovo strano abbandonare il CMT che a parità di qualsiasi silicio porterebbe un +5% di vantaggio TDP.
Il punto debole di BD è l'IPC iniziale, che ha inficiato la forza bruta ed anche la forza MT del modulo. Una volta che Ex o Zen aumentano l'IPC iniziale, si sarebbe risolto il problema.
A ciò aggiungici che a quel punto, o riapplichi il CMT per guadagnare un 5% di TDP con svantaggio in ST e vantaggio in MT (ma comunque con più potenza MT a parità di TDP e fattore non da poco se applicato ad un procio Opteron), o infili l'SMT al buio dove ci vorrebbero anni per raggiungere efficienza sia nei confronti di BD che di Intel.

Intel ha un IPC che è frutto di evoluzioni dal core-duo, con predizione,cache,pipeline e quant'altro, ed il tutto si poggia su FAB proprie che Intel sfrutta fino a raggiungere un livello di PP senza limite di dinero.
Ma questo PP non riguarda solo il TDP finale, ma idoneo per le latenze delle cache, per la densità, per frequenza/TDP, per affinamento, oltretutto a seconda del silicio intervenire sulla lunghezza pipeline.
Un conto è fare tutto ciò con le tue FAB, tutt'altro farlo su dichiarazioni e aspettative.
Nessuna FAB al mondo può garantire questo ad AMD, è fantascienza che AMD possa commercializzare un'architettura che equivalga Intel.
La vera lotta considerando la logica Opteron nei server, sarebbe per me quella di riuscire ad ottenere un IPC non troppo basso rispetto ad Intel (che Zen lo garantirebbe), e implementando il CMT si risparmierebbe quel 5% di TDP, utilizzabile in frequenza def e/o in numero di core.

[el-mejo]

Quello che dici è più che giusto, però trovo strano abbandonare il CMT che a parità di qualsiasi silicio porterebbe un +5% di vantaggio TDP.
Il punto debole di BD è l'IPC iniziale, che ha inficiato la forza bruta ed anche la forza MT del modulo. Una volta che Ex o Zen aumentano l'IPC iniziale, si sarebbe risolto il problema.
A ciò aggiungici che a quel punto, o riapplichi il CMT per guadagnare un 5% di TDP con svantaggio in ST e vantaggio in MT (ma comunque con più potenza MT a parità di TDP e fattore non da poco se applicato ad un procio Opteron), o infili l'SMT al buio dove ci vorrebbero anni per raggiungere efficienza sia nei confronti di BD che di Intel.

Intel ha un IPC che è frutto di evoluzioni dal core-duo, con predizione,cache,pipeline e quant'altro, ed il tutto si poggia su FAB proprie che Intel sfrutta fino a raggiungere un livello di PP senza limite di dinero.
Ma questo PP non riguarda solo il TDP finale, ma idoneo per le latenze delle cache, per la densità, per frequenza/TDP, per affinamento, oltretutto a seconda del silicio intervenire sulla lunghezza pipeline.
Un conto è fare tutto ciò con le tue FAB, tutt'altro farlo su dichiarazioni e aspettative.
Nessuna FAB al mondo può garantire questo ad AMD, è fantascienza che AMD possa commercializzare un'architettura che equivalga Intel.
La vera lotta considerando la logica Opteron nei server, sarebbe per me quella di riuscire ad ottenere un IPC non troppo basso rispetto ad Intel (che Zen lo garantirebbe), e implementando il CMT si risparmierebbe quel 5% di TDP, utilizzabile in frequenza def e/o in numero di core.

Forse il basso ipc è proprio causato dall'implementazione del CMT, che rsulterebbe vano nel caso si utilizzasse core complessi e dall'alto ipc?

Riguardo a Zen, ci ha lavorato sopra Keller per 3 anni, quelloche ha progettato k10 in circa un anno, e sono certo che il target dell'architettura, oltre che avere prestazioni decenti (ma imho non superiori ad Intel), sarà quella di potersi adattare a qualsiasi silicio disponibile al momento, proprio per evitare il ripertersi dei problemi attuali.
Questo permetterebbe grande flessibilità con i fornitori di silicio, parerebbe il didietro ad amd in caso di PP non all'altezza dlle previsioni e lascierebbe aperta la porta al mercato mobile, con i PP ULP.

[davo30]

Non ricordo chi me lo chiedeva, i 16nm TSMC ipotetici per zen si chiamano finfet plus turbo (16nm FF++).
Oltre a B&C, ne parlano anche su altri siti

[Grizlod®]

Non ricordo chi me lo chiedeva, i 16nm TSMC ipotetici per zen si chiamano finfet plus turbo (16nm FF++).
Oltre a B&C, ne parlano anche su altri siti
Ero io forse :) Sicuro TSMC ha più esperienza di Samsung sul produrre chips ad alte frequenze, cmq c'è da aspettarsi un impegno massimale da parte di GF sulla licenza che ha sui 14nm FF ...vedremo ...c'è un altro annetto da attendere :sperem:
Di sicuro se gli "scappasse" AMD, sarebbe un bello smacco per GF :lamer:

Potrebbe forse uscire una prima versione sui 22nm lissssi :sofico: :rolleyes:

[FazzoMetal]

Quello che dici è più che giusto, però trovo strano abbandonare il CMT che a parità di qualsiasi silicio porterebbe un +5% di vantaggio TDP.
Il punto debole di BD è l'IPC iniziale, che ha inficiato la forza bruta ed anche la forza MT del modulo. Una volta che Ex o Zen aumentano l'IPC iniziale, si sarebbe risolto il problema.
A ciò aggiungici che a quel punto, o riapplichi il CMT per guadagnare un 5% di TDP con svantaggio in ST e vantaggio in MT (ma comunque con più potenza MT a parità di TDP e fattore non da poco se applicato ad un procio Opteron), o infili l'SMT al buio dove ci vorrebbero anni per raggiungere efficienza sia nei confronti di BD che di Intel.

Intel ha un IPC che è frutto di evoluzioni dal core-duo, con predizione,cache,pipeline e quant'altro, ed il tutto si poggia su FAB proprie che Intel sfrutta fino a raggiungere un livello di PP senza limite di dinero.
Ma questo PP non riguarda solo il TDP finale, ma idoneo per le latenze delle cache, per la densità, per frequenza/TDP, per affinamento, oltretutto a seconda del silicio intervenire sulla lunghezza pipeline.
Un conto è fare tutto ciò con le tue FAB, tutt'altro farlo su dichiarazioni e aspettative.
Nessuna FAB al mondo può garantire questo ad AMD, è fantascienza che AMD possa commercializzare un'architettura che equivalga Intel.
La vera lotta considerando la logica Opteron nei server, sarebbe per me quella di riuscire ad ottenere un IPC non troppo basso rispetto ad Intel (che Zen lo garantirebbe), e implementando il CMT si risparmierebbe quel 5% di TDP, utilizzabile in frequenza def e/o in numero di core.

Non puoi stimare che il CMT "a parità di qualsiasi silicio porterebbe un +5% di vantaggio TDP" perchè il TDP dipende dall'architettura: il CMT è un approccio al multithreading, lo si può usare su architetture diverse con risultati diversi. E' come parlare di Hyper Threading, lo hanno applicato al PIV e ai processori Core con risultati del tutto differenti su qualsiasi parametro.

Il CMT porta a un incremento prestazionale superiore rispetto all'SMT quando si passa da 1 thread a 2 thread ma bisogna considerare a che prezzo: un modulo che implementa il CMT paga un overhead in termini di numero di transistor molto maggiore rispetto a un core che viene concepito per implementare l'SMT. Senza contare che il CMT si è via via snaturato man mano che BD si è evoluto e le risorse condivise sono diventate sempre di meno (vedi gli scheduler).

AMD deve puntare a realizzare un'architettura fortemente modulare (e questo lo sa già fare bene) con un buon IPC (entro un 20% di scostamento dal top di gamma Intel 2016 direi) e che usi path interni al processore non troppo lunghi in modo tale da lavorare con bassi Vcore senza penalizzare le frequenze.

Io non mi preoccuperei dei consumi, quelli si conterranno grazie ai FinFet e utilizzando tecniche quali pipelining e raddoppio del datapath. Il drawback più grosso delle tecniche di ottimizzazione low-power/high-speed è l'aumento dell'area del die che incide sul costo finale con la quarta potenza. Più che delle performance o del TDP io mi preoccuperei dei costi delle nuove CPU ZEN. Almeno per i primi mesi potrebbero non essere a buon mercato.

[paolo.oliva2]

Forse il basso ipc è proprio causato dall'implementazione del CMT, che rsulterebbe vano nel caso si utilizzasse core complessi e dall'alto ipc?

Riguardo a Zen, ci ha lavorato sopra Keller per 3 anni, quelloche ha progettato k10 in circa un anno, e sono certo che il target dell'architettura, oltre che avere prestazioni decenti (ma imho non superiori ad Intel), sarà quella di potersi adattare a qualsiasi silicio disponibile al momento, proprio per evitare il ripertersi dei problemi attuali.
Questo permetterebbe grande flessibilità con i fornitori di silicio, parerebbe il didietro ad amd in caso di PP non all'altezza dlle previsioni e lascierebbe aperta la porta al mercato mobile, con i PP ULP.

I dati di AMD a prescindere da BD, parlano di un -20% in ST a fronte di un +50% di MT (SMT +30% vs CMT + 80%) ma anche con un TDP del 25% in meno rispetto a 2 core tradizionali, che ridotto in pratica equivarrebbe ad un X12 anziché X10.

Riguardo al k8, non è frutto intero di Keller, perché proviene dall'EV6, Keller al più l'ha adattato al desktop. Ma il problema è che K8 andava bene sul 90nm k8 in k10 cesso nel 65nm k10 sul 45nm liscio o solo con low-k ottimo, k10 sul 32nm conHKMG j ULK cesso.

Per la grande flessibilità, dato da più IPC, ho dubbi, perché Steamroller con +10,5% di IPC non ha risolto nulla, mentre Carrizo ha risolto molto di più con interventi mirati ad abbassare il TDP che con l'aumento di per sé dellcIPC anche se portato a 10/15% in più di Steamroller, visto che la frequenza è aumentata in percentuale maggiore.

Il punto è che c'è una eguaglianza tra IPC maggiore e frequenze maggiori a seconda delle caratteristiche silicio, ma se vogliamo l'unica cosa che può andare sempre bene è l'abbassamento del TDP, perché permetterebbe sia frequenze maggiori che IPC superiori (vedi Carrizo). Il CMT quindi sarebbe valido sempre, a patto che l'IPC iniziale permetta la perdita in ST tanto da soddisfare, a fronte di un MT comunque maggiore della perdita in ST. BD rappresenta un flop non del CMT, quanto invece una partenza di IPC bassa di core, unito ad un silicio che ancor più l'ha castrato in frequenze e TDP e sviluppi, ora se ci metti il silicio con un più che corposo aumento di IPC, la situazione certo cambierebbe e non di poco.

[paolo.oliva2]

Non puoi stimare che il CMT "a parità di qualsiasi silicio porterebbe un +5% di vantaggio TDP" perchè il TDP dipende dall'architettura: il CMT è un approccio al multithreading, lo si può usare su architetture diverse con risultati diversi. E' come parlare di Hyper Threading, lo hanno applicato al PIV e ai processori Core con risultati del tutto differenti su qualsiasi parametro.

Il CMT porta a un incremento prestazionale superiore rispetto all'SMT quando si passa da 1 thread a 2 thread ma bisogna considerare a che prezzo: un modulo che implementa il CMT paga un overhead in termini di numero di transistor molto maggiore rispetto a un core che viene concepito per implementare l'SMT. Senza contare che il CMT si è via via snaturato man mano che BD si è evoluto e le risorse condivise sono diventate sempre di meno (vedi gli scheduler).

AMD deve puntare a realizzare un'architettura fortemente modulare (e questo lo sa già fare bene) con un buon IPC (entro un 20% di scostamento dal top di gamma Intel 2016 direi) e che usi path interni al processore non troppo lunghi in modo tale da lavorare con bassi Vcore senza penalizzare le frequenze.

Io non mi preoccuperei dei consumi, quelli si conterranno grazie ai FinFet e utilizzando tecniche quali pipelining e raddoppio del datapath. Il drawback più grosso delle tecniche di ottimizzazione low-power/high-speed è l'aumento dell'area del die che incide sul costo finale con la quarta potenza. Più che delle performance o del TDP io mi preoccuperei dei costi delle nuove CPU ZEN. Almeno per i primi mesi potrebbero non essere a buon mercato.

Un momento.
Non mischiare architetture, io parto da un punto preciso;
Il core Ex ha un consumo suo a prescindere che dopo venga implementato in SMT o CMT.
Il CMT Xunisce" 2 core, per un risparmio transistor e quindi di TDP con i pro e i contro.
Quindi inquadrare un core EX o Zen con SMT o CMT pone una situazione ben diversa da inquadrare il core AMD + CMT vs core Intel con SMT, perché in questo caso la differenza la fa il silicio.

Io mica sono in disaccordo con te, però il core Intel ha dei consumi suoi ed anche con l'SMT disabilitato o assente addirittura, ha consumi/prestazioni migliori a BD, ma lo era anche con il K10 che non era CMT era lo stesso.
Io non è che voglio difendere il CMT, ma un core Intel senza SMT ed applicandovi il CMT avrebbe comunque una spanna di forza bruta in più e un 4 moduli starebbe perfino sopra ad un 8+8.

Il problema di banda e quant'altro non è a causa del CMT, nel senso che latenza cache, predizione e similari fanno parte del core in se, e non decadono per il CMT. Poi se il CMT castrasse la banda tra i moduli, si può potenziare, in fin dei conti BD l'aveva già affrontato e risolto con Steamroller, fino ad un certo punto, perché comunque visto l'IPC basso non era quello il problema anche perché le richieste erano comunque basse.

Come posso spiegarmi... Il flusso dati di NB di un BD è basso riportato ad Intel, ma enorme rispetto alle richieste dei moduli AMD, visto il fatto che con DDR3 1333 regge un OC del 30% senza alcun decadimento prestazionale. Intel la situazione è ben diversa perché il core ha una potenza enorme e sia per bravura ma anche per necessità, Intel l'ha dovuta potenziare ben più di AMD.

Insomma, se il core fa i 50 è inutile un fronte/end che arrivi a 200, ma è ovvio che se Intel arriva a 100 non puoi fargli un collo di bottiglia da 50.

Io credo che AMD abbia comunque progettato su misura in previsione di più potenze a modulo e con 5 moduli, per questo non c'è bisogno di OC, poi se la richiesta fosse stata maggiore, la si sarebbe potenziata, ma credo che si possa escludere che il CMT diventi un ostacolo.

[FazzoMetal]

sono d'accordo sulle prime 3 frasi, ma potresti riformulare l'ultima perché mi pare una supercazzola :stordita: nel senso che non ho capito nulla, a causa mia, ma non ho capito :D

Volevo dire che il TDP può essere contenuto e limitato a livelli accettabili in quanto esistono varie tecniche, indipendenti dal silicio, che permettono di ridurre sensibilmente i consumi lasciando inalterate le performance.

Quello che si paga quando si vuole un'architettura che sia contemporaneamente veloce e parca nei consumi è l'area occupata, ossia la dimensione del die. Intel è stata bravissima a impacchettare le sue ultime architettura in die di dimensione "contenuta".

AMD a questo giro non può accettare compromessi ne sulle performance assolute ne sul TDP (niente super proci da 220W). Gli scenari, quindi, sono 2:

1 - Sfruttando la grande libertà del team di sviluppo e il talento di Keller AMD realizzerà un "miracolo" con le nuove CPU FX che saranno potenti, efficienti e a prezzi concorrenziali

2 - Più realisticamente le nuove CPU faranno pesantemente ricorso a tecniche di ottimizzazione low-power/high-speed, offrendo alte performance, TDP ridotto ma notevole complessità e dimensione del die --> ZEN offrirà tanto ma il prezzo di lancio sarà elevato

Quando parlavo di dimensioni del die e costo della CPU dicevo che l'area del circuito integrato incide sul prezzo con la quarta potenza. Per fare un esempio, aumentando l'area del 10% il prezzo aumenta del 46%.

[FazzoMetal]

Un momento.
Non mischiare architetture, io parto da un punto preciso;
Il core Ex ha un consumo suo a prescindere che dopo venga implementato in SMT o CMT.
Il CMT Xunisce" 2 core, per un risparmio transistor e quindi di TDP con i pro e i contro.
Quindi inquadrare un core EX o Zen con SMT o CMT pone una situazione ben diversa da inquadrare il core AMD + CMT vs core Intel con SMT, perché in questo caso la differenza la fa il silicio.

Io mica sono in disaccordo con te, però il core Intel ha dei consumi suoi ed anche con l'SMT disabilitato o assente addirittura, ha consumi/prestazioni migliori a BD, ma lo era anche con il K10 che non era CMT era lo stesso.
Io non è che voglio difendere il CMT, ma un core Intel senza SMT ed applicandovi il CMT avrebbe comunque una spanna di forza bruta in più e un 4 moduli starebbe perfino sopra ad un 8+8.

Il core EX non ha un consumo "intrinseco" a prescindere dal tipo di implementazione del multi-threading. Un core EX (contenente tutto quello che serve all'esecuzione di 1 thread con istruzioni x86) ha un determinato consumo. Nel momento in cui si implementa il CMT modifichi pesantemente l'architettura andando a sdoppiare l'intera ALU, gli scheduler e altre risorse. Aumenti la potenza di calcolo parallelo ma aumenti il numero di transistor di una percentuale molto maggiore di quella che si avrebbe aggiungendo a un core EX il necessario per implementare l'HT.

Un core Intel applicandovi il CMT aumenterebbe di dimensione e complessità notevolmente, aumentando die size (e quindi il costo della CPU) e consumi.

[FazzoMetal]

ok chiaro :)

ah, 1.1^4 !
come mai elevare alla quarta?

Ovviamente è una prima approssimazione. Un fattore lineare c'è a causa del costo intrinseco del pezzo di silicio: 1 mm^2 --> tot €, 2 mm^2 --> 2*tot €.

La parte preponderante, invece, dipende dalla funzione che descrive la distribuzione delle imperfezioni sul disco di silicio dove si vanno a stampare litograficamente i die. Le imperfezioni si distribuiscono non proprio casualmente sul wafer e più aumenta l'area del die più aumenta il numero medio di imperfezioni/die. Garantire di non avere imperfezioni su un'area di 300 mm^2 è molto più "facile" che farlo su un die di 600 mm^2 (la resa cala drasticamente).

Infine ci sono i costi di testing e verifiche varie del die che crescono anch'essi con la complessità dello stesso.

I conti esatti non li conosco ma so che alla fine il contributo complessivo della dimensione del die sul costo della CPU è approssimabile come x^4.

[tuttodigitale]

E soprattutto meno dipendente dalla bontà del silicio. Cosa fondamentale per AMD (e water-glofo)

Spero solo che l'esempio di cpu non dipendente dal silicio non siano quelle basate sui derivati di Nehalem...
Le cpu Intel hanno un FO4 "enorme" di 24. Questo significa questa cpu ha la NECESSITA' di commutazioni veloci (delay off-on ridotto= maggiore Vcore). Velocità che non è stata in grado di fornire il SOI a Vcore decenti. E qui dove il FO4 basso fa la differenza. E in effetti PD dimostra questa qualità in tutta la sua potenza nei confronti di k10. Non c'è nessuna ragione per credere che Sandy bridge potesse raggiungere i 3 GHz sui 32nm SOI.
Come se non bastasse un FO4 basso permette un clock gating molto aggressivo
.
Qualcuno potrebbe dire che anche PD ha la necessità di commutazioni veloci. E infatti, il FO4 è un buon indice per conoscere la frequenza massima di una cpu con un determinato processo produttivo e Vcore. L'analisi del consumo effettivo è cosa diversa e dipende dall'implementazione, così come le prestazioni.

Credo che Intel debba necessariamente pensare ad un post-Nehalem per sfruttare a meglio le qualità del suo silicio anche nel ST.


se non erro l'SMT di Intel incide del +5% in termini di transistor a favore di un +30% di prestazioni, mentre il CMT di AMD incide del +25% in termini di transistor a favore di un +80% di prestazioni

in termini assoluti SMT ha un efficienza per transistor circa doppia rispetto al CMT
30/5 = 6x
80/25 = 3.2x
Le percentuali sono un pochino sbagliate (prendo per buono i tuoi numeri anche se AMD parla di +12% a livello di modulo e+5% a livello di die, il quantitativo di cache è esagerato):

SMT +24% (perf 130% tran 105%)
CMT +44% (perf 180% tran 125%)
chiaramente è il secondo ad essere più efficiente. Tuttavia utilizzando il primo tipo si può aumentare a parità di TDP la potenza nel ST (ma andrà meno nel MT) rispetto alla soluzione CMT. Come vedi non c'è un chiaro vincitore.

Un core Intel applicandovi il CMT aumenterebbe di dimensione e complessità notevolmente, aumentando die size (e quindi il costo della CPU) e consumi.
Ma andrebbe anche l'80% in più..
A parte gli scherzi un CMT+SMT potrebbe essere un ottima soluzione. Mi pare di ricordare che le CPU xeon con le istruzioni AVX si downcloccano pesantemente. Per il desktop anzichè avere un octa-core (16 thread) ci fosse un 6 moduli con 12 core+ HT (24 thread), sarebbe ancora meglio imho.

[paolo.oliva2]

Spero solo che l'esempio di cpu non dipendente dal silicio non siano quelle basate sui derivati di Nehalem...
Le cpu Intel hanno un FO4 "enorme" di 24. Questo significa questa cpu ha la NECESSITA' di commutazioni veloci (delay off-on ridotto= maggiore Vcore). Velocità che non è stata in grado di fornire il SOI a Vcore decenti. E qui dove il FO4 basso fa la differenza. E in effetti PD dimostra questa qualità in tutta la sua potenza nei confronti di k10. Non c'è nessuna ragione per credere che Sandy bridge potesse raggiungere i 3 GHz sui 32nm SOI.
Come se non bastasse un FO4 basso permette un clock gating molto aggressivo
.
Qualcuno potrebbe dire che anche PD ha la necessità di commutazioni veloci. E infatti, il FO4 è un buon indice per conoscere la frequenza massima di una cpu con un determinato processo produttivo e Vcore. L'analisi del consumo effettivo è cosa diversa e dipende dall'implementazione, così come le prestazioni.

Credo che Intel debba necessariamente pensare ad un post-Nehalem per sfruttare a meglio le qualità del suo silicio anche nel ST.



Le percentuali sono un pochino sbagliate (prendo per buono i tuoi numeri anche se AMD parla di +12% a livello di modulo e+5% a livello di die, il quantitativo di cache è esagerato):

SMT +24% (perf 130% tran 105%)
CMT +44% (perf 180% tran 125%)
chiaramente è il secondo ad essere più efficiente. Tuttavia utilizzando il primo tipo si può aumentare a parità di TDP la potenza nel ST (ma andrà meno nel MT) rispetto alla soluzione CMT. Come vedi non c'è un chiaro vincitore.


Ma andrebbe anche l'80% in più..
A parte gli scherzi un CMT+SMT potrebbe essere un ottima soluzione. Mi pare di ricordare che le CPU xeon con le istruzioni AVX si downcloccano pesantemente. Per il desktop anzichè avere un octa-core (16 thread) ci fosse un 6 moduli con 12 core+ HT (24 thread), sarebbe ancora meglio imho.

Come potrebbe essere un CMT + SMT?
Quel tizio di AMD aveva detto che Zen sarebbe sia CMT che SMT.
Ma che complessità avrebbe un core + SMT in CMT nel modulo?
Sarebbe disumano... Alla faccia della predizione e fella velocità cache.

[paolo.oliva2]

FazzoMetal

Per i costi non è come dici tu, nel senso che GF ha riportato che il 16nm costerebbe meno del 28nm bulk, quindi contando la miniaturizzazione e la relativa diminuzione dell'area del die, praticamente un procio sul 16nm potrebbe essere pure X8 ma costare meno di un X4 sul 28nm a parità di affinamento.
Conta che un 8350 ha circa lo stesso die size di un 5960X, ma ovviamente AMD non vende in negativo, come ovviamente Intel applica più un prezzo/prestazioni che un costo al mm2.

In ogni cado, senza polemica alcuna, il costo reale al mm2 del silicio è ben diverso dal costo commerciale, nel senso che chiaramente AMD applica un prezzo/prestazioni + un costo progetto (prodotto da 5 anni) che non può essere lo stesso di Intel.

Idem, il costo di un Zen implicherà enormemente sul die rispetto ad un passaggio di un ipotetico 8350 con modulo Excavator... Se poi a parità un FX fosse anche più grande di un Zen, costerebbe comunque molto meno.

[tuttodigitale]

Come potrebbe essere un CMT + SMT?
Quel tizio di AMD aveva detto che Zen sarebbe sia CMT che SMT.
Ma che complessità avrebbe un core + SMT in CMT nel modulo?
Sarebbe disumano... Alla faccia della predizione e fella velocità cache.

Se è disumano un CMT+SMT figurati un SMT 4
100% + 25% + 5% = 131% complessità
100% + 80% + 30%= 234% prestazioni

Efficienza teorica +78%

Come dicevo poco sopra, le CPU della concorrenza downcloccano quando le loro enormi FPu vengono usate a limite. Oggi, esattamente come a lancio di BD ha perfettamente senso usare la flexFP, che sarebbe comunque di dimensioni doppie rispetto a quella attuale.

E' ovvio che un SMT non ha senso se la cpu, come nel caso di BD, ha poche ALU a disposizione. Aldilà dei numeri ogni approccio deve essere contestualizzato.

[macellatore]

Il CMT non fa guadagnare di piu', semmai fa perdere di meno.

Se x sono le prestazioni single core,
con n core hai x*n*fattoreCMT oppure x*n*fattoreSMT,
dove fattoreCMT e fattoreSMT sono compresi tra 0 e 1,
e fattoreCMT > fattoreSMT.

Io vedo percentuali sommate che non hanno alcun senso.
Semmai con l'SMT sottrai il 50% (fattoreSMT=0.5), con il CMT sottrai il 20% (fattoreCMT=0.8).

Meditateci in relax. Pagine e pagine di thread con conti senza senso. YAWN

[capitan_crasy]

http://www.capitancrasy.com/images/BAN CLONE02.gif

[paolo.oliva2]

scusa, ma così stai valutando le prestazioni globali ed indubbiamente il CMT fa guadagnare di più in maniera relativa, però non il guadagno assoluto apportato della sola componente aggiuntiva al Core Reale(Intel) o Modulo con 1 solo Integer(AMD).

Intel, spendo 5 per guadagnare 30: ho un guadagno il 600% da quel 5 -> 6x
AMD, spendo 25 per guadagnare 80: ho un guadagno del 320% da quel 25 -> 3.2x

poi appunto non ricordo se sia +25% di transistor, magari è troppo; contiamo +15%:

AMD, spendo 15 per guadagnare 80: ho un guadagno del 530% da quel 15 -> 5.3x

il mio era un modo per evidenziare l'efficienza assoluta delle implementazioni e non le prestazioni relative.

Però ci sono altre cose da tenere in considerazione, non solamente il numero di transistor.
Intel ha cache più veloci di AMD, OK per l'IPC superiore, ma anche perché ovviamente la L1 deve essere svuotata velocemente per dare posto al 2° TH e poi per ritornare al 1°.

Non voglio contraddurti nel tuo discorso, ma ad esempio Carrizo ha 3.1 miliardi di transistor, ben 1/2 miliardo in più di un 5960X, ma non per questo il die ha prezzi proibitivi, come del resto il numero dei transistor è vero incide sui consumi, ma bisogna vedere quanti cambi di stato hanno 1000 transistor e quanti ipoteticamente 100 nella stessa unità di tempo. Facendo un esempio di quello che voglio dire... Il 5% in più che ha l'SMT Intel si poggia su latenze cache ben inferiori rispetto a quelle di AMD, quindi non sarebbe sbagliato supporre che quel 5% generi anche un TDP superiore rispetto al 20% del CMT di AMD.
Oggi come oggi il costo di un die è relativo, perché un procio veramente fallato da essere buttato via al 100% dovrebbe avere quantità minime, quindi anche se ad esempio un FX aumenta i transistor e quindi la possibilità di die fallato, alla fine può essere venduto come X6 e X4, con L3 4MB o assente, questo fa sì di diminuire drasticamente la reale perdita totale del die.

Tornando al tuo discorso, secondo me non si può giudicare il CMT e SMT sulle basi odierne semplicemente perché il CMT di AMD rappresenta un'implementazione povera, cioè si è puntato ad ottenere prestazioni semplicemente diminuendo il TDP.

Il confronto sul numero di transistor ci può stare, ma il 30% e 80% vanno valutati sempre sull'IPC nativo e di qui quello finale, ma occorre pure considerare che il core BD per quanto più flessibile del K10, AMD non ci ha speso una tozza in miglioramenti predizione, latenze cache e similari. In fin dei conti AMD con il modulo è ad un soffio con 2 TH rispetto ad Intel con il core + SMT spendendo 1/1000 rispetto a rivoluzionare completamente tutto (cache, predizione & C.

P.S.
Aggiungo, oltre al core in se per se, va anche valutato l'implicazione delle cache inclusive, che indubbiamente riducono i tempi nel ritrovare i dati, ma per contro a parità di capienza utile necessitano di capacità ben maggiori. Senza andare in polemiche inutili, un Opteron X16 vs un 8+8 Intel, dovrebbero avere capacità di carico TH simili, ma ammesso che il core + SMT richieda meno transistor, alla fine ci sono quasi il 20% in più di transistor a parità di TH con Intel e non il contrario. La differenza al più sarebbe nel TDP ma non al fatto di più transistor, o comunque non tanto dipendente dal CMT vs SMT

[paolo.oliva2]

Se è disumano un CMT+SMT figurati un SMT 4
100% + 25% + 5% = 131% complessità
100% + 80% + 30%= 234% prestazioni

Efficienza teorica +78%

Come dicevo poco sopra, le CPU della concorrenza downcloccano quando le loro enormi FPu vengono usate a limite. Oggi, esattamente come a lancio di BD ha perfettamente senso usare la flexFP, che sarebbe comunque di dimensioni doppie rispetto a quella attuale.

E' ovvio che un SMT non ha senso se la cpu, come nel caso di BD, ha poche ALU a disposizione. Aldilà dei numeri ogni approccio deve essere contestualizzato.

Si però non capisco il concetto.
Il CMT riduce il TDP condividendo i core ricercando un TDP più basso a potenza a scapito della forza bruta ma con 2 TH fisici.
L'SMT sfrutta il core riducendo si i transistor, ma non abbassa di certo il TDP, anzi lo aumenta (da verificare nel complesso per la stessa potenza quanto TDP genererebbe il CMT e quanto l'SMT con lo stesso silicio)

Come fai a inglobare nel modulo 2 soluzioni opposte?
Cioè, inglobi l'SMT per ottenere la potenza max e poi ci metti il CMT che castrerebbe l'SMT per diminuire il TDP? Che è, un power8 FX?

Se mi consenti, la vedrei meglio un modulo che implichi il CMT con 2 TH ma abbia la possibilità di annullare il CMT quando il carico fosse 1 TH. Io non mi so spiegare, ma il modulo BD come IPC dovrebbe essere comunque superiore a quello del K10 semplicemente purché ha un'FP del doppio più grande, INT più efficienti e un rapporto pipeline/frequenza non peggiore. Ma anche con 1 TH il CMT sega la potenza, forse potrebbe pure essere che AMD abbia segato un po il front-end per abbassare il TDP (o comunque con la nuova miniaturizzazione avrebbe il margine TDP per potenziarlo), ma nel caso di un core Zen con SMT e CMT nel modulo, io non ci raccapezzo il senso.

[-Maxx-]

http://www.capitancrasy.com/images/BAN CLONE02.gif

Mi sono cappottato dalle risate! :sbonk:

[batou83]

Per favore AMD, fà uscire presto sti benedetti zen FX , altrimenti questi qui dentro impazziscono nell'attesa :p

[AceGranger]

mi ricordo che il discorso del transistor-count e die-area era venuto fuori ai tempi dell'uscita del 8150, proprio perché ha un die-area del 50% superiore al 2600k con un tot di transistor in più ed anche se la commutazione dei transistor fosse la medesima indubbiamente questo comporta un consumo superiore ed una probabilità di die fallati superiore (minor introiti).
il CMT anche proprio per un fattore economico di azienda è una scelta infelice nel desktop dai margini risicati.

Carrizo è metà cpu e metà gpu, e se consideri che la componente gpu (aka 7750) conta 1,5 miliardi di transistor vedi che torna sotto rispetto al 5960x.
http://www.anandtech.com/show/5541/amd-radeon-hd-7750-radeon-hd-7770-ghz-edition-review

http://www.anandtech.com/show/8426/the-intel-haswell-e-cpu-review-core-i7-5960x-i7-5930k-i7-5820k-tested
http://wccftech.com/amd-carrizo-apu-isscc-2015-presentation-leaked-5-ipc-gain-x86-steamroller-die-consists-31-billion-transistors/

vishera 1.2B in 315 mmq a 32nm
kaveri 2.4B in 245mmq (-1.5B ~ igpu) 0.9B in 125mmq a 28nm (la igpu ha un di circa 120 mmq)
carrizo 3.1B in 245mmq (-1.5B ~ igpu) 1.6B in 125mmq a 28nm (la igpu ha un di circa 120 mmq)
sandybridge 4C 1B in 215mmq (-0.3B ~ igpu) 0.7B in ???mq a 32nm (non conosco i mmq della igpu)
sandybridge 6C 2.27B in 435mq a 32nm

non capisco come faccia carrizo ad avere così tanti transistor, sempre che il dato sia certo.

i 22nm non li considero perché non ha molto senso visto che da un nodo all'altro dimezzi l'area occupata e di conseguenza tagli dal 30 al 50% i consumi a pari prestazioni

occhio pero che nel SB 6C il numero dei transistor è quello totale del chip 8 core compresi i 2 disattivati.

come numero di transitor conviene prendere quelli di Ivy Bridge a 22nm, che varia di molto poco risepetto a SB nella parte X86, ed è un 6 core nativo e ne ha 1.86B.

[george_p]

http://www.capitancrasy.com/images/BAN CLONE02.gif

Questa gif è sempre mitica!!! :D

[tuttodigitale]

scusa, ma così stai valutando le prestazioni globali ed indubbiamente il CMT fa guadagnare di più in maniera relativa, però non il guadagno assoluto apportato della sola componente aggiuntiva al Core Reale(Intel) o Modulo con 1 solo Integer(AMD).

Intel, spendo 5 per guadagnare 30: ho un guadagno il 600% da quel 5 -> 6x
AMD, spendo 25 per guadagnare 80: ho un guadagno del 320% da quel 25 -> 3.2x

poi appunto non ricordo se sia +25% di transistor, magari è troppo; contiamo +15%:

AMD, spendo 15 per guadagnare 80: ho un guadagno del 530% da quel 15 -> 5.3x

il mio era un modo per evidenziare l'efficienza assoluta delle implementazioni e non le prestazioni relative.
Ma scusami: ti rendi conto che il tuo ragionamento è un pochino sballato?
Mi dici come fai a dire che l'efficienza assoluta aumenta del 600% con il SMT quando le prestazioni aumentano del 30% :rolleyes: :confused:

Io non parlavo di prestazioni ma di prestazioni/transistor. E di questo stavamo parlando o no?
CMP 100 transistor ottengo 100 di prestazioni (efficienza 100%)
SMT 105 transistor ottengo 130 di prestazioni (efficienza 124%)
CMT 125 transistor ottengo 180 di prestazioni (efficienza 144%)

Globalmente, e solo in teoria, un singolo transistor in una cpu con architettura CMT rende di più. Ed è questo quello che conta o sbaglio?

Forse ti può essere d'aiuo questo grafico
http://pc.watch.impress.co.jp/img/pcw/docs/408/107/03.jpg

Tuttavia voglio sottolineare che per avere il SMT devi avere un architettura progettata espressamente per il SMT. Quel +5% è bugiardo e non del tutto veritiero, perchè non considera che chi progetta una determinata architettura ha già previsto il SMT.
Ad esempio vi siete mai chiesti perchè Intel non usa il SMT4...Semplice, il core non è adatto. Il power 8 guadagna con il passaggio dal SMT2 a SMT4 più di quanto Intel faccia dal singolo Thread al SMT2....

Infatti secondo questi ragionamenti un modulo BD, secondo le slide dovrebbe essere superiore al 12% di un ipotetico BD senza dual core. Peccato che una cpu del genere farebbe a dir poco pena, visto che sarebbe comunque quasi grande quanto due core k10...Se si fa finta che le componenti comuni non siano sovradimensionate per il doppio thread (le cache come ha detto Paolo devono avere una maggior associavità per gestire al meglio il secondo thread, oltre che dimensioni maggiori), i guadagni sembrano enormi. In realtà sono assai più modesti. Tanto che Intel nel nome dell'efficienza, è passato da una cpu cone un'architettura SMT (atom) ad una che ne è priva

[tuttodigitale]

non capisco come faccia carrizo ad avere così tanti transistor, sempre che il dato sia certo.


1,4 miliardi sono solo di gpu.

[paolo.oliva2]

Aspetta, io sono d'accordo con te per il discorso core. Il discorso Kaveri e Carrizo è inficiato da supporto huma e HSA, non tanto nel core in sé per sé, e comunque l'IGP AMD è più potente.
Quello che volevo notare è che il modulo in quanto tale è lo stesso sia di un Opteron che di un APU, e di qui il numero di transistor e quant'altro, perché credo che per AMD risulti più conveniente realizzare un modulo unico che diverse varianti.
Intel ha sì lo stesso core, ma varia le cache in base al suo utilizzo e numero dei cote.

È ovvio che così se confronti il modulo con un 2600k , anche a parità di TH, dia un risultato differente che rispetto allo stesso nella forma Opteron 16TH ma riferito magari ad un 5960X, appunto perché in questo caso l'architettura deve reggere un determinato carico e assolvere compiti più gravosi.

Il problema è che se confronti un 5960X ad un 2600K non fai caso al numero in può di transistor semplicemente perché ha una potenza doppia in MT ed un carico maggiore.
Stona quando prendi un 8350 che più o meno è simile in potenza MT, ed allora il carico in più non lo si prende in considerazione.

Tolto questo che magari è una mia personale considerazione, il nocciolo vero sarebbe l'efficienza architetturale, che sia con più o meno transistor frega poco perché nessuno ci pensa, se non per il fatto che una potrebbe consumare di più e andare meno, ma di questo abbiamo un parametro diretto tra un 8350 con 1,2miliardi di transistor che consuma quasi quanto un 5960X con meta potenza e meno della metà dei transistor, ma questo mi sembra palese che sia dovuto ad un silicio della metà meno efficiente, non architetturale, altrimenti non potrebbe esistere la stessa architettura ma sul 28nm competitiva per consumo/prestazioni ad un 22nm Intel.

[paolo.oliva2]

Ma scusami: ti rendi conto che il tuo ragionamento è un pochino sballato?
Mi dici come fai a dire che l'efficienza assoluta aumenta del 600% con il SMT quando le prestazioni aumentano del 30% :rolleyes: :confused:

Io non parlavo di prestazioni ma di prestazioni/transistor. E di questo stavamo parlando o no?
CMP 100 transistor ottengo 100 di prestazioni (efficienza 100%)
SMT 105 transistor ottengo 130 di prestazioni (efficienza 124%)
CMT 125 transistor ottengo 180 di prestazioni (efficienza 144%)

Globalmente, e solo in teoria, un singolo transistor in una cpu con architettura CMT rende di più. Ed è questo quello che conta o sbaglio?

Forse ti può essere d'aiuo questo grafico
http://pc.watch.impress.co.jp/img/pcw/docs/408/107/03.jpg

Tuttavia voglio sottolineare che per avere il SMT devi avere un architettura progettata espressamente per il SMT. Quel +5% è bugiardo e non del tutto veritiero, perchè non considera che chi progetta una determinata architettura ha già previsto il SMT.
Ad esempio vi siete mai chiesti perchè Intel non usa il SMT4...Semplice, il core non è adatto. Il power 8 guadagna con il passaggio dal SMT2 a SMT4 più di quanto Intel faccia dal singolo Thread al SMT2....

Infatti secondo questi ragionamenti un modulo BD, secondo le slide dovrebbe essere superiore al 12% di un ipotetico BD senza dual core. Peccato che una cpu del genere farebbe a dir poco pena, visto che sarebbe comunque quasi grande quanto due core k10...Se si fa finta che le componenti comuni non siano sovradimensionate per il doppio thread (le cache come ha detto Paolo devono avere una maggior associavità per gestire al meglio il secondo thread, oltre che dimensioni maggiori), i guadagni sembrano enormi. In realtà sono assai più modesti. Tanto che Intel nel nome dell'efficienza, è passato da una cpu cone un'architettura SMT (atom) ad una che ne è priva

Quoto.

Io non ho le tue basi di elettronica... Per questo ti chiedo:
Escludendo BD con le sue pipeline lunghe, sarebbe corretto dire che il CMT punterebbe più nel risparmio TDP l'aumento di potenza a die mentre l'SMT ricerca l'efficienza nello sfruttamento totale del core?
Cioè, io credo che senza un silicio valido, comunque abbiamo la prova di cosa può fare il CMT, ma non possiamo sapere cosa sarebbe successo nel caso BD fosse stato SMT, ma io sarei dell'opinione che non sarebbe stato meglio di sicuro nell'MT, ma forse meglio nell'ST a patto di ridurre i core totali.

Ma nei prox silicio, è presumibile che il leakage comunque diminuisca?

Perché credo che a seconda della bontà silicio l'equilibrio sia tra numero di transistor, frequenza e leakage, ma se il leakage percentualmente diminuirebbe, sarebbe più conveniente ricercare un TDP migliore con più transistor ma meno esasperati che viceversa, contando anche il problema sempre maggiore di dissipazione del calore prodotto su una superficie sempre più minore.

[paolo.oliva2]

forse mi sono espresso male, quello che voglio sottolineare è l'efficienza della sola parte "aggiuntiva"
spendo il 5% del core e ne guadagno il 30% in prestazioni, spendo il 25% del core e ne guadagno l'80% in prestazioni.
guadagno meno come throughput indubbiamente, ma molto di più in:
efficienza, minor leakage
dimensioni totali del die
minor numero di transistor totali
minor numero di wafer da realizzare
minor numero di die da realizzare e incidenza minore di quelli non fallati
maggior guadagno dal singolo die venduto
...
di contro c'è che il design deve essere studiato alla perfezione, di sicuro una architettura SMT è più difficile da realizzare da una CMT o ancora nel caso migliore dalla CMP.

voglio sottolineare questo, che chi produce cpu dovrebbe valutare soprattutto questi fattori e per ultimo le prestazioni generali



si ma sono comunque 1.6~1.7! uno sproposito

Come dice Tuttodigitale , l'architettura BD è comunque creata a monte... Il problema non è nel numero dei transistor se più o meno, ma i pro e i contro in quel numero di transistor.
Prendi un i3 e confrontarlo con 2 moduli, e diresti che il numero maggiore di transistor di AMD è speso più che bene, diverso se prendi un i7 X4+4, mentre da X6+6 in su il CMT non richiederebbe più transistor dall'SMT. Il punto è che il confronto tra 8TH AMD e Intel è basato tra un procio server per AMD ed un procio non server come sopporto carico Intel, con tutte le differenze, ma un procio Intel che offre più potenza sia ST che MT per me non dovuta all'architettura, ma ad un insieme di cose, efficienza cache, efficienza silicio, sfruttamento massimo tra minor numero di transistor e carico, e le macroscopiche pecche di AMD nell'implementazione CMT, tra frequenze più basse, impossibilitata ad aumentare l'IPC per il silicio e quant'altro.

Però prendere singolarmente il numero di transistor e da qui estrapolare che l'SMT è più efficiente del CMT è tutto un'altra cosa.

[paolo.oliva2]

ma di fatto ho confrontato cpu a parità di miniaturizzazione silicio, ed è comunque evidente dove a causa del CMT si abbiano die più grossi con più transistor e di conseguenza meno efficienti e tutto ciò che ne comporta a livello realizzativo e di spesa; poi certo il 32nm intel è migliore del 32/28nm GF.
ho sempre dato la colpa a 50 e 50 tra architettura e silicio

Partiamo da un punto:
Facciamo un confronto transistor e TH massimi architettura.
5960X 2,6b, AMD 2,4b. CMT meno efficiente?

Tieni presente che la potenza finale non c'entra nulla, perché comunque già 2 8350 sarebbero li in MT, figurati con 20/25% in più di IPC con Excavator.

Se poi invece estrapoliamo il core per giudicare più efficiente l'SMT ma confrontando 2 proci fondamentalmente diversi... Sarebbe come dire che un X4+4 è più efficiente di un X6+6 perchè l'X6 ha ben più del 50% di transistor??? Quindi l'SMT dell'X4 è più efficiente dell'SMT dell'X6? Sarebbe un paradosso, quindi mi pare ovvio che devi giudicate l'SMT nel l'interezza e di qui da 2TH al massimo di TH vs TH analoghi AMD, non 2600k vs 8350 e stop.

P.S.
Ma nessuno può negare che l'SMT 4+4 sia migliore dei 4m attuali. Però considera anche che un FX Excavator a 3m fornirebbe la stessa potenza di un attuale 4m, quindi sballerebbe comunque il tuo confronto.

[george_p]

Partiamo da un punto:
P.S.
Ma nessuno può negare che l'SMT 4+4 sia migliore dei 4m attuali. Però considera anche che un FX Excavator a 3m fornirebbe la stessa potenza di un attuale 4m, quindi sballerebbe comunque il tuo confronto.

Excavator passa per diverse evoluzioni del primo BD (e PD) che non sono semplici aggiunte di moduli senza contare che Carrizo è la prima evoluzione del core EX mentre ne avremo uno di seconda generazione nei desktop.

Quindi è proprio scontatissimo che che questi facciano il culetto ai primi.

[Grizlod®]

http://wccftech.com/amd-contracts-tsmc-produce-zen-16nm-woes-14nm-process-troubles-globalfoundries/

[tuttodigitale]

Quoto.

Io non ho le tue basi di elettronica...
le mie conoscenze di cpu sono a livello assai basico, giuro.


Escludendo BD con le sue pipeline lunghe, sarebbe corretto dire che il CMT punterebbe più nel risparmio TDP l'aumento di potenza a die mentre l'SMT ricerca l'efficienza nello sfruttamento totale del core?
E' proprio così
Come dicevo poco fa non è un segreto che la FPu è un componente affamato di energia. http://api.viglink.com/api/click?format=go&jsonp=vglnk_14432156541839&key=8a27173f1d0514db88df01b1c3d4a370&libId=if05c6i80101045j000DAjqqgss0i&loc=http%3A%2F%2Fwww.anandtech.com%2Fshow%2F8423%2Fintel-xeon-e5-version-3-up-to-18-haswell-ep-cores-%2F5&v=1&out=http%3A%2F%2Fimages.anandtech.com%2Fdoci%2F8423%2FHep_AVX_turbo.png&ref=https%3A%2F%2Fwww.google.it%2F&title=Power%20Optimizations%20-%20Intel%20Xeon%20E5%20Version%203%3A%20Up%20to%2018%20Haswell%20EP%20Cores&txt=%3Cimg%20alt%3D%22%22%20src%3D%22http%3A%2F%2Fimages.anandtech.com%2Fdoci%2F8423%2FHep_AVX_turbo_575px.png%22%3E

con le AVX il nuovo XEON abbassa la frequenza base di un abbondante 20%. Con la FPu con registri da 512 bit si ripresenta il fatto del sottoutilizzo di questa unità finchè non arriveranno software in grado di sfruttare le nuove istruzioni.

Oggi con meccanismi di clock gating e gestione del clock (vedi sopra)sempre più raffinati non so se effettivamente la strada delle risorse condivise porti tutti questi vantaggi.
Mi spiego meglio: il front end di BD è sovradimensionato per il singolo core (ecco perchè trovo ridicolo considerare il costo in termini di transistor di una soluzione CMT pari alla complessità del solo scheduler e core aggiuntivo). Nel momento in cui si esegue codice ST, oltre al core deve alimentare, a pieno regime, anche le risorse condivise che anche se sfruttate molto al di sotto delle proprie possibilità devono comunque funzionare.
Questo diciamo è la ragione principale per la quale è preferibile prima saturare i core di un modulo.
Ovviamente questo è un problema che si porta dietro anche la soluzione SMT. Cache e quant'altro sovradimensionato per gestire il secondo thread. Tuttavia in quel caso, in virtù dello scarso rendimento del HT (il secondo thread occupa unità esecutive che spetterebbero al primo thread) si preferisce comunque relegare ad un secondo core il thread aggiuntivo.

La FlexFPu è concepita per usare al meglio le AVX-128, le 256 praticamente sono gestite solo per mantenere la compatibilità. Non è da escludere che AMD impieghi di nuovo questa strategia...ovvero usare pipeline con registri più piccoli da 256 bit, quindi dare il meglio con il codice odierno, ma con la possibilità di combinarle per gestire le AVX512.
Faccio presente, che oggi la FlexFPu è a tutti gli effetti una unità SMT2. Praticamente modificando pochi dettagli già sarebbe pronta per ZEN.

Cioè, io credo che senza un silicio valido, comunque abbiamo la prova di cosa può fare il CMT, ma non possiamo sapere cosa sarebbe successo nel caso BD fosse stato SMT, ma io sarei dell'opinione che non sarebbe stato meglio di sicuro nell'MT, ma forse meglio nell'ST a patto di ridurre i core totali.
Come dicevo tempo fa non c'è nessuna ragione per pensare che BD non sia in grado di trarre beneficio dalla 3 pipeline int (magari dovrebbe avere la cache l1 di steamroller piuttosto quella di BD).
Nel ST non ho dubbi che sarebbe andato meglio. Nel MT a parità di thread certo che no. Direi che un buon +15-20% lo avrebbe garantito


Perché credo che a seconda della bontà silicio l'equilibrio sia tra numero di transistor, frequenza e leakage, ma se il leakage percentualmente diminuirebbe, sarebbe più conveniente ricercare un TDP migliore con più transistor ma meno esasperati che viceversa, contando anche il problema sempre maggiore di dissipazione del calore prodotto su una superficie sempre più minore.
Secondo me non dobbiamo ragionare in termini di frequenza che è un concetto di per sé privo di significato (la frequenza massima raggiungibile da un transistor singolo, raggiunge i 40GHz). Per carità un FO4 basso tenderà a consumare di più se si sfrutta appieno la maggior frequenza, ma non nei termini che noi tendiamo a pensare.
Faccio un esempio tanto per chiarire il concetto:
abbiamo 2 cpu 1,4V cpu_a 3 GHz cpu_b 5GHz.
il consumo sarebbe dato dalla media della somma dei singoli contributi dei transistor che compongono la cpu . Facciamo finta che siano uguali nella cpu.
cpu_a 95W cpu_b 158W
cpu_a a 5 GHz potrebbe non arrivarci, in compenso cpu_b a 3 GHz potrebbe significare 1,2V e quindi solo 70W.

Precisato questo, vedo che il finfet di Intel siano migliorati tanto dai 3GHz in giù, che per BD e derivati significherebbe circa 4,2GHz (attenzione non parlo in termini di consumi assoluti, ma relativi). :read:

A livello di architettura BD/PD compete con Nehalem nel ST, o almeno il confronto llano vs Richland fa presupporre questo. Imho, non è assolutamente un fallimento.

[Dimonios]

http://wccftech.com/amd-contracts-tsmc-produce-zen-16nm-woes-14nm-process-troubles-globalfoundries/

Fonte originale: http://www.bitsandchips.it/50-enterprise-business/6076-glofo-in-ritardo-con-i-14nm-vuole-risparmiare-sui-macchinari :D

[tuttodigitale]

ma di fatto ho confrontato cpu a parità di miniaturizzazione silicio, ed è comunque evidente dove a causa del CMT si abbiano die più grossi con più transistor e di conseguenza meno efficienti e tutto ciò che ne comporta a livello realizzativo e di spesa; poi certo il 32nm intel è migliore del 32/28nm GF.
ho sempre dato la colpa a 50 e 50 tra architettura e silicio
aveva detto in queste pagine che a livello di sezione x86 compresa le cache, non esistono praticamente differenze tra i 32 e 28nm. Mentre le differenze con i 32 nm Intel erano notevoli a dir poco.
In termini di transistor per due moduli steamroller comprese di cache l2 siamo a 450 milioni di transistor.
400 milioni dovrebbero servire per il MC (quad-channel), il nortbridge PCI express ecc.

su Carrizo:
https://www.google.it/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=0CAcQjRxqFQoTCLjyhsqsk8gCFcEDGgoddPEMWw&url=http%3A%2F%2Fwccftech.com%2Famd-carrizo-apu-architecture-hot-chips%2F&bvm=bv.103627116,d.d2s&psig=AFQjCNH4SrpHqHsdE9_pXpiZFWcMoB8aJQ&ust=1443310405831748
la parte sinistra sotto al MC e ai 2 moduli XV, è interamente occupata dal NB, SB, PCI-e.
Dati ufficiali parlano di 14,48mmq per modulo XV (dual core) e 102 milioni di transistor. Come volevasi dimostrare sono le cache che fanno lievitare il numero di transistor negli FX e la natura SoC di Carrizo (ed è sconvolgente che nonostante tutto quel ben di Dio integrato in cinebench giri a ben 2,3GHz, 200 MHz oltre alla frequenza base, con il TDP impostato a 15W).

comunque ecco la slide del costo del secondo core: 5% esattamente come il SMT (certo con 800 milioni di transistor dovuti alle cache, non è stato difficile mantenere il numero basso).
http://images.anandtech.com/reviews/cpu/amd/hotchips2010/bulldozerefficient.jpg
come ho detto più e più volte questo numero è una cavolata esattamente come lo è per il SMT...o almeno non penso proprio che spendendo solo un +5% di transistor, un core BD possa effettivamente andare il 30% in più. Sarebbe troppo facile.

Fonte originale: http://www.bitsandchips.it/50-enterprise-business/6076-glofo-in-ritardo-con-i-14nm-vuole-risparmiare-sui-macchinari :D
chissà se i finfet di TMSC siano quantomeno paragonabili a quelli Intel, dato i precedenti, temo che sia solo una scelta del tipo "questo o niente".

[Grizlod®]

Fonte originale: http://www.bitsandchips.it/50-enterprise-business/6076-glofo-in-ritardo-con-i-14nm-vuole-risparmiare-sui-macchinari :D
Già...probabile...e pensare che i propositi erano tutt'altri:
http://globalfoundries.com/newsroom/press-releases/2014/04/17/samsung-and-globalfoundries-forge-strategic-collaboration-to-deliver-multi-sourced-offering-of-14nm-finfet-semiconductor-technology

Cmq in TSMC si parla di 10, 7nm, ma di 16 FF++, neppure una virgola...
http://semimd.com/blog/2015/09/21/tsmc-moves-from-16nm-to-10nm-to-7nm/

[tuttodigitale]

Ho il sospetto, ma potrei sbagliare, che Zen userà le HDL. Questi processi produttivi non sembrano adatti alle librerie per alte prestazioni.

[Grizlod®]

Ho il sospetto, ma potrei sbagliare, che Zen userà le HDL. Questi processi produttivi non sembrano adatti alle librerie per alte prestazioni.Non è da escludere, tuttavia hanno ancora diversi mesi per lavorare su un eventuale 14 FFHP.

[paolo.oliva2]

BAH, se riescono ad avere un silicio discreto, manco buono, ci scapperebbe un FX Ex X8 in 65W, a frequenze ben più alte di un Carrizo 15W.
Se poi sfruttassero pienamente il TDP nel turbo, e se il silicio non fosse un cesso, vorrei vedere tipo 90W come X8 in MT e 90W in turbo come X4 che frequenze si potrebbero ottenere.

Il 28nm va benissimo sui 2/3GHz nei 15W, un 14nm a quel TDP se scalasse bene in frequenza andrebbe tranquillo almeno a 4GHz.

[principe Vlad]

Ciao Ragazzi, qualcuno mi può spiegare come mai oggi acquistare un FX 8350 mi costa circa 187€ quando più di un anno fa l'avevo pagato meno di 160€ ????????? lasciamo stare il discorso del cambio euro/dollaro, una cpu che ormai ha fatto il suo tempo forse dovrebbe costare un pochino meno ma credo che sia diventata un pezzo da collezione e quindi il costo sale, non ho parole..... scusatemi ma la cosa mi fa davvero incazzare... un cordialissimo saluto a tutti i partecipanti del forum, Vlad

[sgrinfia]

Ciao Ragazzi, qualcuno mi può spiegare come mai oggi acquistare un FX 8350 mi costa circa 187€ quando più di un anno fa l'avevo pagato meno di 160€ ????????? lasciamo stare il discorso del cambio euro/dollaro, una cpu che ormai ha fatto il suo tempo forse dovrebbe costare un pochino meno ma credo che sia diventata un pezzo da collezione e quindi il costo sale, non ho parole..... scusatemi ma la cosa mi fa davvero incazzare... un cordialissimo saluto a tutti i partecipanti del forum, Vlad

Già una cosa notata anche da me ,ma la causa rimane un xfiles.....:D

[george_p]

Ciao Ragazzi, qualcuno mi può spiegare come mai oggi acquistare un FX 8350 mi costa circa 187€ quando più di un anno fa l'avevo pagato meno di 160€ ????????? lasciamo stare il discorso del cambio euro/dollaro, una cpu che ormai ha fatto il suo tempo forse dovrebbe costare un pochino meno ma credo che sia diventata un pezzo da collezione e quindi il costo sale, non ho parole..... scusatemi ma la cosa mi fa davvero incazzare... un cordialissimo saluto a tutti i partecipanti del forum, Vlad

E' proprio quello il punto per cui è aumentato da 160 euro a 187, in ogni caso questa cpu dovrebbe scendere in dollari a 140/150 vista l'età.
Ma tanto si sa che qui in italia paghiamo di più a prescindere.

[isomen]

Ciao Ragazzi, qualcuno mi può spiegare come mai oggi acquistare un FX 8350 mi costa circa 187€ quando più di un anno fa l'avevo pagato meno di 160€ ????????? lasciamo stare il discorso del cambio euro/dollaro, una cpu che ormai ha fatto il suo tempo forse dovrebbe costare un pochino meno ma credo che sia diventata un pezzo da collezione e quindi il costo sale, non ho parole..... scusatemi ma la cosa mi fa davvero incazzare... un cordialissimo saluto a tutti i partecipanti del forum, Vlad

A 160€ lo trovo anche ora e l'8370E che pagai 179€ adesso si trova a 199€... ma anche un i5 4670/90 (che mi sembra costava sui 180/190) adesso si trova da 210€ in su.

;) ciauz

[paolo.oliva2]

Non è aumentata anche l'IVA? Io ho pagato gli HD 4TB 120€, ora stanno a 150€... Fortuna che sono usciti gli 8TB a 230€...

[capitan_crasy]

Clicca qui... (http://www.techpowerup.com/216361/globalfoundries-14-nm-lpp-finfet-node-taped-out-yields-good.html)

[paolo.oliva2]

@ShellX

Il discorso di puntare a Zen + SMT in ambito desktop, può essere condiviso semplicemente perché ad un aumento di forza bruta difficilmente con 95W AMD non potrà schierare + di 8TH, risultando comunque competitivo VS Intel.
Ma la stessa cosa avrebbe risvolti differenti nei server, dove magari una potenza ST migliore di Pile serve.
Però, Excavator comunque la alza e non di poco (20/25%), ma il CMT visto come Opteron e quindi con la massima potenza MT (frutto risparmio TDP), metterebbe comunque AMD sul sicuro.
A tutto questo aggiungici architettura rodata e basso TDP di un 16/14nm, a me sembra più azzardato Zen di quanto può essere Ex conservativo in termini di rischio silicio.

Analizza:

Zen +40% IPC su EX.
Però, io credo che ALMENO a parità di TDP Ex dovrebbe garantire 10% in più di frequenza, in un range che può essere 20% nel caso di frequenze Zen 3,5GHz e 5% nel caso Zen >4GHz.
Comunque un Zen a 3,5GHz vs un Ex a 4GHz, vedrebbe un Zen del 25% più potente in forza bruta, ma vedrebbe:
Zen 100 + 25% = 125 (ST) +30% = 167
EX 100 (ST) + 80% = 180

Condivido quello che dici che in ambito desktop l'MT abbia meno importanza, quindi fissando parametri di 4GHz è palese che un IPC forte abbia margine rispetto a frequenze di 5GHz, ma in ambito server, dove comunque le frequenze sono comunque basse per permettere un numero più alto di proci, non è difficile immaginare cosa potrebbe fare un Excavator, comparando i 2,4GHz e sopra i 3GHz in turbo ottenuti con Carrizo su un 28nm in 15W di cui almeno 7W per l'IGP.

Aggiungici che AMD ha già speso per Excavator e per Excavator II avrebbe già investito, personalmente io vedrei più logico le dicerie di un tizio AMD FI un CMT + SMT che un SMT nuovo sulle ceneri di un CMT.

Discussione a livello concettuale, di CMT con silicio idoneo e stesso silicio con SMT.

[davo30]

Clicca qui... (http://www.techpowerup.com/216361/globalfoundries-14-nm-lpp-finfet-node-taped-out-yields-good.html)

Low-Power. Un nome una garanzia!
Notizia casualmente uscita dopo che si era ventilata la possibilità che AMD lasciasse a causa dell'ennesima schifezza made in glofo. Credibilità di questa fonderia pari a zero!

[FroZen]

8350 1,375V, LLC High

4600 CPU e 4400 NB (voltaggi a def) raffreddato da un noctua doppia ventola...

Che ne dite di 722 punti al cinebench R15 come migliore run? :stordita: Ricordo che gli fx possono risultare stabili anche in carenza di voltaggio ma con punteggi "limitati" ovvero si ottiene lo stesso punteggio con 100mhz in meno ma con la birra giusta rispetto a un +100 ma con lo stesso voltaggio "insufficiente".....ricordo bene? :stordita:

Penso che ora lo lascerò così......su dishonored pare tutto stabile :stordita: ma vedendo i risultati di altri penso che se lancio un linx mi esplode tutto asdasd ma se è stabile nei giochi, per me è tutto grasso che cola....

[george_p]

pensavo, ma se paragonassimo Zen ad 1 Modulo Ex ma senza il secondo integer?
chi ha detto che Zen+HT è uguale ad 1 modulo totale? dopo tutto si ritorna ad una situazione di parità tra unità Int ed Fpu.
Premessa: Io ci credo poco, ma si dice che Zen dovrebbe uscire in 95watt con versione 8 core, e si intenderebbe 8 int + 8 fpu e 16 th totali, mentre l'ipotetico Ex di cui si fanno i confronti con 8 int + 4 fpu e 8 th.

Spiego: se prendessimo quel mero +40% esclusivamente paragonandolo a livello di core classico 1+1(int+fpu) senza considerare l'eventuale guadagnato apportato dal th logico?

tralasciamo turbo per semplificazione (4ghz def all_core):
Ex = 100 ST -> 720 MT , dato da 100*1.8*4, ovvero dal plus del secondo core e dai moduli
Zen = 140 ST -> 1120 MT, dato da 100*1.4*8, ovvero dal plus di IPC dichiarato e dai core totali senza considerare il plus del HT che in questo momento non si può nemmeno considerare, ed AMD non ne ha mai parlato chiaramente nelle slide come guadagno a parte indicare che l'architettura sarà SMT.

già così si parla di un +55% in MT considerando la frequenza simile, ma mettiamo che l'apporto di IPC renda i 4 ghz inarrivabili consideriamo 3.5 ghz def all_core, avremmo:
1120*3.5/4= 980 MT, ovvero il +36% in MT su di un ipotetico Ex 4 moduli

il tutto senza considerare l'apporto del SMT

ps. tenendo conto che Intel genera un +30% con HT, AMD anche solo con un +15% di HT sul MT arriverebbe a qualcosa come 1127 in MT ovvero il 56% in più di Ex.

tutto questo paolo per dire che se cambiano architettura secondo me non sono dei pazzi, avranno fatto tutti i conti del caso in fase di sviluppo primordiale 3 anni fa.

Bisogna vedere se amd ha cambiato denominazione per i suoi core nel frattempo.
All'uscita di BD si è ostinata a chiamare octacore una cpu che non è composta da 8 core completi e reali, palesemente per marketing soprattutto.

Personalmente penso che la versione di Carrizo non sia quella alla quale si riferiscono con il 40% di ipc in più dichiarato, poiché la versione prevista per l'apu desktop è di 7a generezione (quindi excavator 2 generation) contro Carrizo di 6a generazione.

Quel 40% potrebbe diventare una percentuale finale vicina al 70/80% in più rispetto a PD.

Poi beh, pensai inizialmente anche io il tuo stesso discorso e se così fosse... non vedo l'ora che passi un anno :D

[epimerasi]

Clicca qui... (http://www.techpowerup.com/216361/globalfoundries-14-nm-lpp-finfet-node-taped-out-yields-good.html)

Probabile lo utilizzeranno per le APU mobile col successore di excavator

[george_p]

@Grid: la seconda immagine, quella slide in arancione non mi risulta sia amd ma fake. Erano tutte postate nel forum dove amd è intervenuta smentendo tutto.

Comunque un core BD (o ex ecc) è, per forza, "formato" da un integer + la fpu condivisa.

Se il +40% fosse sul modulo intendendo il confronto con un core Zen (int+fpu) la performance finale sarebbe ancora più alta. Sempre escludendo l'SMT.

[george_p]

intendi la terza immagine quella della "unit"?

fosse sul modulo supererebbe di gran lunga un 8 core Intel, e lo vedo impossibile :sofico:
Ex base 100: 100*1.8*1.4*8=2016 in MT senza considerare l'HT, utopia :D

per tanto credo sia giusto considerare quanto detto prima, almeno io la penso così, altrimenti avrebbe ragione paolo a dire che è tutto uno spreco.
Non perchè non voglio dargli ragione a priori, ma perché sarebbe insensato fare un cambio di architettura se poi non hai un guadagno netto dopo che hai sviluppo una cpu da 0 come han detto loro stessi pochi giorni fa, che hanno avuto carta bianca :read:

Ma come minimo, se la nuova architettura non straccia la vecchia intesa come vecchia quella relativa all'ultima evoluzione (excavator) naturalmente non ha senso.
Amd sarebbe punto e a capo.

Per l'immagine intendo la seconda in basso delle due nel tuo ultimo post.

[shellx]

@ShellX
cut...

Condivido quello che dici che in ambito desktop l'MT abbia meno importanza, quindi fissando parametri di 4GHz è palese che un IPC forte abbia margine rispetto a frequenze di 5GHz, ma in ambito server, dove comunque le frequenze sono comunque basse per permettere un numero più alto di proci, non è difficile immaginare cosa potrebbe fare un Excavator, comparando i 2,4GHz e sopra i 3GHz in turbo ottenuti con Carrizo su un 28nm in 15W di cui almeno 7W per l'IGP.

Aggiungici che AMD ha già speso per Excavator e per Excavator II avrebbe già investito, personalmente io vedrei più logico le dicerie di un tizio AMD FI un CMT + SMT che un SMT nuovo sulle ceneri di un CMT.

Discussione a livello concettuale, di CMT con silicio idoneo e stesso silicio con SMT.

Ho capito Paolo, ma gli Xeon sono SMT e anche in ambito server sono nettamente superiori agli Opteron (e su questo aspetto te l'ho posso garantire io che ne monto e amministro ogni giorno). Tuttavia l'80% delle mie scelte per i clienti è sempre ricaduta su Opteron, ma per motivi differenti alle prestazioni, che mi pare di avere già spiegato giorni fa.

Ma la stessa cosa avrebbe risvolti differenti nei server, dove magari una potenza ST migliore di Pile serve.

Una potenza ST in ambito server datacenter per bigdata è quasi inutilizzata. Per calcolo database, richieste di accesso e di login in maniera frenetica, richieste di creazione nuovi record per nuovi clienti inseriti, tutto questo in una scenario frenetico per minuto, dove è possibile assistere a centinaia e centinaia di accessi al db da parte di utenti ogni minuto, la potenza MT è la chiave della efficienza per una azienda che produce questo tipo di servizi. Come abbiamo già parlato diverse volte invece caso contrario nel desktop tutto questo non avviene mai, ergo una potenza ST è preferita per il tipo di applicazioni che servono.


beh amd ha sempre parlato di Modulo prima di Zen, mentre ora parla di +40% sul Core Excavator e non sul Modulo e non rappresentando da nessuna parte il numero dei core totali in 95watt, a parte la slide dei 4 Core Zen affiancati che condividono gli 8 mb di Cache L3, o del plus di HT; per tanto rivedendo anche la mia precedente interpretazione penso che si debba valutare 1 Core Zen = 1 Modulo - 1 integer e quindi paragonare 8 core Zen ad 8 Moduli e non 4... a questo poi andrebbe aggiunto il plus di HT che da nessuna parte è comparso

Ecco perchè escludo l'approccio CMT. L'SMT come al CMP vede il core l'intero modulo elaborativo dove ogni core ha un solo cluster int 100 indipendente. In BD invece il modulo è il sarcofago di due cluster virtualmente parlando, ma concettualmente un solo int 100 diviso in due parti 50+50 (classico scenario ideale per i server). Inoltre AMD avendolo implementato male quel 50+50 che doveva essere, lo fece diventare 50+25/30.

[calabar]

Comunque un core BD (o ex ecc) è, per forza, "formato" da un integer + la fpu condivisa.
Due appunti.

Un core BD è solo il core INT. AMD ha dichiarato che si riferisce alla definizione storica di Core, che riguarda solo l'unità di calcolo per interi.

Un modulo BD è stato progettato per contrastare un core Intel con SMT. In pratica i due core fisici di BD (sebbene con alcuni stadi di logica condivisi) avrebbero dovuto far meglio dei due core logici di Intel.
La FPU rimane una per modulo, così come ce n'è una accoppiata al core Intel con SMT.

Ora, non so quanto questo possa fare chiarezza sulle prestazioni annunciate di Zen, però penso che anche in questo caso il core+SMT sia stato pensato per sostituire il modulo BD.
Un processore Zen con 8 core sarebbe quindi un bel coso grande e grosso. Non credo competa con un Intel a 8 core (l'IPC di Zen sembra simile a quello di Ivy Bridge o al più haswell, da quel che si sa), ma 8 core potrebbero dare un risultato comunque interessante, se davvero riusciranno a farceli stare in 95W (compresa almeno una piccola GPU, spero).

[paolo.oliva2]

@gridracedriver

Io supporrei che Excavator 2a release incrementi l'IPC su Excavator I, e credo irreale che AMD lavori contemporaneamente a Excavator e Zen se diversissimi.
Il +40% di IPC di Zen potrebbe essere un 20% per aver tolto il CMT e sommando l'incremento di IPC tea i 2 EX.

Tra l'altro... Io non mi intendo e non so spiegare, ma credo che il modulo come BD dia priorità al carico al posto della forza bruta, ma modificando il front-end, credo sia possibile modificare il modulo con priorità alla forza bruta a scapito del carico, magari semplicemente, come fa Intel con l'SMT, cioè fino a che ci sono core liberi, il TH viene passato all'altro core (e così potrebbe essere il modulo), salvo che poi in MT potrebbe ritornare la condivisione ma così sono 2TH su 2 core e non sempre sullo stesso come l'SMT.

Se vogliamo, io credo che se 8 core CMT consumino 100W, 8 core con 8 FP già consumerebbero un tot di più, e se a questo ci aggiungi un incremento di IPC del 40% (che non può dipendere unicamente dalla FP non più condivisa) e poi ci aggiungi l'SMT, che TDP si avrebbe?
Invece considerando il modulo come 1 super-core si avrebbe l'aumento di IPC, ed il CMT in realtà ci sarebbe con il 2° TH, ammesso e concesso che l'aumento dei transistor del modulo (e non core + SMT) sia vantaggioso in quel +50% con 2TH vs 30% dell'SMT.

@ShellX
Ma non è che mi devi convincere che Intel sia più prestante di AMD con gli Xeon.
Dico solo che fare la guerra ad Intel sull'IPC in sé per sé per me è una guerra persa in partenza.
Non voglio sollevare un vespaio, ma io ero e sono ancor più convinto che mai, che il modulo AMD era partito male (con IPC basso) e su un silicio che ha portato solamente svantaggi.
8o non conosco quanti transistor abbia un modulo Excavator vs Piledriver, ma visto che un 8+8 Intel avrebbe 400milioni di transistor di più di 8 moduli Piledriver con 2 MC e doppio I/O, dubito che un 8 moduli nativo (teorico) ne possa avere di più di più.
Il core Intel è potente, l'SMT l'aiuta, il silicio è sviluppato ad hoc, ma alla fine comunque Intel per permettere più core e contenere il TDP è costretta a segare le frequenze.
Cacchio, se AMD sul 28nm Bulk già in 140W riuscirebbe a metterci 10 moduli a 2,4GHz con 10 IGP (Carrizo 15W x 10), con tanto di Huma e HSA, che cacchio, già al posto di un 8m Piledriver a 2,8GHz ci sarebbero 4 core in più, 20/25% di IPC in più, ci togli l'HSA e Huma e IGP, in più passi dal 28nm al 14nm, che margine di clock/core avresti in più?

[george_p]

Due appunti.

Un core BD è solo il core INT. AMD ha dichiarato che si riferisce alla definizione storica di Core, che riguarda solo l'unità di calcolo per interi.

Un modulo BD è stato progettato per contrastare un core Intel con SMT. In pratica i due core fisici di BD (sebbene con alcuni stadi di logica condivisi) avrebbero dovuto far meglio dei due core logici di Intel.
La FPU rimane una per modulo, così come ce n'è una accoppiata al core Intel con SMT.

Ora, non so quanto questo possa fare chiarezza sulle prestazioni annunciate di Zen, però penso che anche in questo caso il core+SMT sia stato pensato per sostituire il modulo BD.
Un processore Zen con 8 core sarebbe quindi un bel coso grande e grosso. Non credo competa con un Intel a 8 core (l'IPC di Zen sembra simile a quello di Ivy Bridge o al più haswell, da quel che si sa), ma 8 core potrebbero dare un risultato comunque interessante, se davvero riusciranno a farceli stare in 95W (compresa almeno una piccola GPU, spero).

Si certo, amd può dire quello che vuole e lo ha fatto perché "otto cores" faceva più figo e "potente" di 6, 4 o 2.

Sta di fatto che un core completo non include solo l'integer.
Quindi personalmente non mi sento di considerare il suo octa una cpu a otto core veri.

[paolo.oliva2]

Clicca qui... (http://www.techpowerup.com/216361/globalfoundries-14-nm-lpp-finfet-node-taped-out-yields-good.html)

Il mio inglese non è eccelso, ma considerando che un silicio LPP non credo sia idoneo alla complessità di CPU/GPU, credo che GF (e di qui tutto il consorzio) sviluppi il 14nm finfet su presupposto HPP.

[vincenzo2008]

Ecco un gioco che sfrutta a pieno 8 thread
http://gamegpu.ru/images/remote/http--www.gamegpu.ru-images-stories-Test_GPU-Action-Tom_Clancys_Rainbow_Six_Siege_Beta-test-RainbowSix_proz.jpg
http://gamegpu.ru/images/remote/http--www.gamegpu.ru-images-stories-Test_GPU-Action-Tom_Clancys_Rainbow_Six_Siege_Beta-test-RainbowSix_intel.jpg
http://gamegpu.ru/images/remote/http--www.gamegpu.ru-images-stories-Test_GPU-Action-Tom_Clancys_Rainbow_Six_Siege_Beta-test-RainbowSix_amd.jpg

I nostri anzianotti resistono :D

[shellx]

@ShellX
cut...
Cacchio, se AMD sul 28nm Bulk già in 140W riuscirebbe a metterci 10 moduli a 2,4GHz con 10 IGP (Carrizo 15W x 10), con tanto di Huma e HSA, che cacchio, già al posto di un 8m Piledriver a 2,8GHz ci sarebbero 4 core in più, 20/25% di IPC in più, ci togli l'HSA e Huma e IGP, in più passi dal 28nm al 14nm, che margine di clock/core avresti in più?

se...

[calabar]

Si certo, amd può dire quello che vuole e lo ha fatto perché "otto cores" faceva più figo e "potente" di 6, 4 o 2.

Sta di fatto che un core completo non include solo l'integer.
Quindi personalmente non mi sento di considerare il suo octa una cpu a otto core veri.
Non è affatto una questione di "far figo", ma una questione prettamente tecnica. La definizione storica di "core" riguarda solo il cluster INT, il resto sono acceleratori e coprocessori. Poi certo, loro hanno deciso di mettere in risalto questa caratteristica.
Del resto è l'unica definizione che funziona, dato che come si è visto le architetture possono variare parecchio sull'argomento, e sarebbe difficile conteggiare i core altrimenti.

E non è neppure questione di "sentirsela", l'8 core AMD è proprio un 8 core perchè ha 8 unità di calcolo int indipendenti.
Che poi questi 8 core siano quel che sono e il loro target (non raggiunto :p ) sia un Intel 4c/8t è un altro discorso.

[Grizlod®]

Si certo, amd può dire quello che vuole e lo ha fatto perché "otto cores" faceva più figo e "potente" di 6, 4 o 2.

Sta di fatto che un core completo non include solo l'integer.
Quindi personalmente non mi sento di considerare il suo octa una cpu a otto core veri.
Mah...penso che a suo tempo AMD, quando era ancora 'culo e camicia' con IBM, poteva uscire( ancor prima di BD) con una microarchitettura simile al Power8 (chi non sognerebbe uno Zen x86, così :sofico: :oink: ):
http://www.hotchips.org/wp-content/uploads/hc_archives/hc25/HC25.20-Processors1-epub/HC25.26.210-POWER-Studecheli-IBM.pdf

Purtroppo sono stati fatti azzardi sbagliati IMO...:( :rolleyes:

Credo invece che Zen sarà impostato diversamente da quanto molti desktopisti s'immaginano. Ritengo molto plausibile una soluzione versatile e polivalente, orientata al cambiamento dei mercati; vuoi per risollevare SeaMicro, sia per i chips personalizzati semicustom, sia per altre applicazioni bivalenti ( vedi K12) e non...

Penso questo rumor sia verosimile e +/- corrispondente alla realtà:
http://www.tweaktown.com/news/46831/amd-teases-zen-powered-32-core-apu-hbm2-more/index.html

Perciò, reputo attendibile l'adozione di Zen con serigrafia @ 14nm (quanto HP, non lo so...), con HDL e relative basse frequenze di lavoro. :O

[george_p]

@calabar:
Si, indubbiamente è una scelta di amd ma io personalmente lo ritengo una via di mezzo tra un mezzo core e un tre quarti. La fpu serve per cinebench ad es e li ha perso molto, così si scriveva fino a 2 anni fa almeno.

@Grizlod:
Mah, se è vero che il progetto bulldozer è stato rivisto più volte nel corso degli anni... di azzardi ne son stati fatti anche troppi con quello finale.

Per quanto riguarda zen e quel progetto apu finché non esce almeno quello su desktop non possiamo fare altro che inventarci propri film su quanto sia bello e potente.

Personalmente mi auguro che l'architettura venga resa migliore sotto tanti punti di vista.

[isomen]

8350 1,375V, LLC High

4600 CPU e 4400 NB (voltaggi a def) raffreddato da un noctua doppia ventola...

Che ne dite di 722 punti al cinebench R15 come migliore run? :stordita: Ricordo che gli fx possono risultare stabili anche in carenza di voltaggio ma con punteggi "limitati" ovvero si ottiene lo stesso punteggio con 100mhz in meno ma con la birra giusta rispetto a un +100 ma con lo stesso voltaggio "insufficiente".....ricordo bene? :stordita:

Penso che ora lo lascerò così......su dishonored pare tutto stabile :stordita: ma vedendo i risultati di altri penso che se lancio un linx mi esplode tutto asdasd ma se è stabile nei giochi, per me è tutto grasso che cola....

Si, ricordi bene e secondo me potresti migliorare il risultato o trovare la completa stabilità (se adesso nn l'hai), con poco, forse con 1 o 2 step in più di vcore... ma probabilmente basterebbe alzare leggermente (1,2/1,25) il voltaggio del cpu/nb, io a 4,6ghz faccio 769 punti:

http://thumbnails113.imagebam.com/43832/e3c04b438313645.jpg (http://www.imagebam.com/image/e3c04b438313645)

;) ciauz

[tuttodigitale]

Si certo, amd può dire quello che vuole e lo ha fatto perché "otto cores" faceva più figo e "potente" di 6, 4 o 2.

Sta di fatto che un core completo non include solo l'integer.
Quindi personalmente non mi sento di considerare il suo octa una cpu a otto core veri.

@calabar:
Si, indubbiamente è una scelta di amd ma io personalmente lo ritengo una via di mezzo tra un mezzo core e un tre quarti. La fpu serve per cinebench ad es e li ha perso molto, così si scriveva fino a 2 anni fa almeno.


Vedi lo scaling in cinebench di un doppio modulo PD è di 3,24x, di SR 3,46x e di un i5 3,84x.

Secondo questo ragionamento, un FX8350 sarebbe un 6,7 core, un ipotetico SR x8 un 7,2...
Voglio sottolineare il fatto che in fin dei conti la FPU condivisa abbassa le prestazioni in maniera assai marginale. In PD sono i decoder condivisi ad abbassare ulteriormente lo scaling. Altre scelte, come la privazione della terza pipeline, cache con associatività bassa, e la relativa lentezza, hanno compromesso l'ipc (le prestazioni sono state compromesse dal silicio).

numero transistor di un modulo, senza cache l2
102 milioni excavator vs 86 milioni steamroller (+19%)

modulo con cache l2
BD 216 MTran vs SR 236Mtran
al netto della cache l2
66 milioni di transistor per BD (numeri da verificare).

[george_p]

Vedi lo scaling in cinebench di un doppio modulo PD è di 3,24x, di SR 3,46x e di un i5 3,84x.

Secondo questo ragionamento, un FX8350 sarebbe un 6,7 core, un ipotetico SR x8 un 7,2...
Voglio sottolineare il fatto che in fin dei conti la FPU condivisa abbassa le prestazioni in maniera assai marginale. In PD sono i decoder condivisi ad abbassare ulteriormente lo scaling. Altre scelte, come la privazione della terza pipeline, cache con associatività bassa, e la relativa lentezza, hanno compromesso l'ipc (le prestazioni sono state compromesse dal silicio).

numero transistor di un modulo, senza cache l2
102 milioni excavator vs 86 milioni steamroller (+19%)

modulo con cache l2
BD 216 MTran vs SR 236Mtran
al netto della cache l2
66 milioni di transistor per BD (numeri da verificare).

Doppio modulo PD e SR contro dual core I5?

[paolo.oliva2]

Ma è sempre la storia del cane che si mangia la coda.
Se fai il confronto Phenom II X6, e ritorni al tuo discorso IPC, il Thuban X6,per l'IPC superiore e per 6 core "reali" dovrebbe surclassare un FX 8350, invece è l'esatto contrario anzi, se esistesse un FX base Ex addirittura basterebbero 2 moduli per pareggiare un Thuban.
Se vogliamo, anche la definizione Intel di 2TH non sarebbe veritiera, perché in fin dei conti parlare di 2TH per me si intenderebbe contemporanei, mentre nel reale il core +SMT comunque processa 1 TH nell'unità di tempo.

La realtà è che il giudizio alla fine si basa unicamente dalle prestazioni finali che però dipendono da ben più fattori.
Se oggi esistesse un silicio in grado di commercializzare un Ex X8, non esisterebbe minimamente la discussione come è instaurata oggi, perché il modulo sarebbe del 20/25% più potente e ancor più nell'MT, quindi tutte le valutazioni e considerazioni tra CMT e SMT ivi incluso la considerazione del numero dei core avrebbe tutta un'altra aspetto.

Comparare 2 prodotti commerciali dove uno (Intel) può proseguire nello sviluppo architetturale e prodotto su un silicio realizzato per sopportare l'evoluzione architetturale vs AMD che non può commercializzare proprio per l'assenza di silicio un'architettura che già ha avuto 2 evoluzioni (intendo ambito FX), è irragionevole, no?
Sarebbe come prendere una vettura di F1, equipaggiarla con il telaio di 4 anni fa, idem con il motore di 4 anni fa, farla gareggiare e dire che il pilota è una mezza sega ed è per questo che non va, e che i progettisti delle altre auto l'hanno lungo.

[paolo.oliva2]

Da cellulare ho cercato video YouTube e c'è parecchia roba, probabilmente mondezza.

AMD_16_CORE_Zen_Processor_Leaked__720p.mp4
AMD_To_Release_32_Zen_Core_APU_With_32GB_HBM2_As_Well_As_Greenla
AMD_Zen_CPU_Information_DDR4_Support_14nm_Supports_New_Instructi
AMD_Zen_CPU_Quad_Core_Block_Revealed_Details_On_32_Core_Zen_Opte

[tuttodigitale]

Se vogliamo, anche la definizione Intel di 2TH non sarebbe veritiera, perché in fin dei conti parlare di 2TH per me si intenderebbe contemporanei, mentre nel reale il core +SMT comunque processa 1 TH nell'unità di tempo.
Non è così.
Il SMT usa le pipeline non utilizzate dal primo thread e le mette a disposizione del secondo, che viene elaborato SIMULTANEAMENTE, ovviamente con risorse a disposizione limitate (le pipeline libere)

[paolo.oliva2]

Vorrei fare delle supposizioni;

Zen aumenterebbe la forza bruta del core.
Il modulo di principio favorirebbe l'MT a scapito della forza bruta a core.

A prescindere dal silicio, in linea di massima Zen diminuirebbe il gap prestazionale a core, quindi AMD potrebbe commercializzare Zen con un numero di core proporzionato alla bontà del PP, ma sarebbe favorita nel confronto fascia Intel X4 semplicemente perché potrebbe comunque offrire + potenza MT maggiore rispetto al divario ST. Come dire... Il core Zen + SMT va il 20% in meno del core Intel, supponendo incrementi SMT simili, a quel punto un AMD X6 con +50% di core otterrebbe prestazioni MT di rilievo.

Fino a questo punto tutto OK, ma sarebbe sempre il silicio a decidere, in base al leakage, alternative. Zen con un IPC superiore comunque produrrebbe un TDP superiore a core, che invece il CMT riduce. Se il leakage fosse basso, il CMT concederebbe a parità di TDP un 25% di core, che invece un leakage alto segnerebbe.

Come cacchio fa AMD a produrre un procio su una base architetturale che non può essere definita a priori appunto perché si sarebbe sull'assurdo che toccherebbe all'architettura ottimizzare il silicio e non l'inverso?

[paolo.oliva2]

Non è così.
Il SMT usa le pipeline non utilizzate dal primo thread e le mette a disposizione del secondo, che viene elaborato SIMULTANEAMENTE, ovviamente con risorse a disposizione limitate (le pipeline libere)
Si, però la definizione 2TH contemporanei io la intendo come indipendenti e liberi di essere eseguiti. Se il 2° TH viene elaborato negli "spazi" vuoti lasciati dal primo, non credo rifletta la stessa finalità.
Se vogliamo il modulo è 2TH reali nella parte INT ma con l'FP fino a 128 bit sopporta 2TH, ma con 256 un TH deve aspettare la fine del precedente. Ma questo è un caso che nella pratica è raro, ma lo si critica come se tutte le istruzioni subissero loop.

In termini di concetto io criticherei più la definizione di 2TH fisici perché con l'FP sarebbe più un SMT, di quanto non lo sia quella di 2 core per modulo.

Io credo che per comodità tutti utilizzino definizioni a proprio comodo, come esempio frequenze def bello in grande e gnorri se poi superato un certo TDP/temp si abbassano, perché comunque sono giustificabili.
La cosa che mi ha sorpreso, ad esempio, è che il mio Trinity mobile ha effettivamente un P-state non dichiarato a 2,8GHz in turbo, mentre quello a 2,5GHz dichiarato all'equatore non entra quasi mai in funzione se non con carichi ben ridotti ma OK con tempo più alte. Ma nessun produttore lo stamperà sulla confezione.

Se andassimo a cercare il pelo nell'uovo secondo me non reggerebbe alcuna dichiarazione ufficiale. L'esempio lo è la vicenda della ditta tedesca, perché i trucchi per dichiarerà emissioni (e consumi) è considerata legale fino a che, vuoi con pneumatici più gonfi e quant'altro, la puoi comunque replicare anche se nell'effettivo collettivo no, ma illegale quando manco "loro" la possono replicare.

[george_p]

Ma è sempre la storia del cane che si mangia la coda.
Se fai il confronto Phenom II X6, e ritorni al tuo discorso IPC, il Thuban X6,per l'IPC superiore e per 6 core "reali" dovrebbe surclassare un FX 8350, invece è l'esatto contrario anzi, se esistesse un FX base Ex addirittura basterebbero 2 moduli per pareggiare un Thuban.
Se vogliamo, anche la definizione Intel di 2TH non sarebbe veritiera, perché in fin dei conti parlare di 2TH per me si intenderebbe contemporanei, mentre nel reale il core +SMT comunque processa 1 TH nell'unità di tempo.

La realtà è che il giudizio alla fine si basa unicamente dalle prestazioni finali che però dipendono da ben più fattori.
Se oggi esistesse un silicio in grado di commercializzare un Ex X8, non esisterebbe minimamente la discussione come è instaurata oggi, perché il modulo sarebbe del 20/25% più potente e ancor più nell'MT, quindi tutte le valutazioni e considerazioni tra CMT e SMT ivi incluso la considerazione del numero dei core avrebbe tutta un'altra aspetto.

Comparare 2 prodotti commerciali dove uno (Intel) può proseguire nello sviluppo architetturale e prodotto su un silicio realizzato per sopportare l'evoluzione architetturale vs AMD che non può commercializzare proprio per l'assenza di silicio un'architettura che già ha avuto 2 evoluzioni (intendo ambito FX), è irragionevole, no?
Sarebbe come prendere una vettura di F1, equipaggiarla con il telaio di 4 anni fa, idem con il motore di 4 anni fa, farla gareggiare e dire che il pilota è una mezza sega ed è per questo che non va, e che i progettisti delle altre auto l'hanno lungo.


Non è un caso che ritengo oggi un 4 moduli BD un superquad-core piuttosto che un octacore.
Le FPU in BD sono state potenziate e quindi almeno li mi aspetto che raggiunga il punteggio in Cinebench fatto da un esacore vero. Proprio come è realmente accaduto al quattro moduli BD.
Solo che appunto, quest'ultimo ha solo 4 FPU e non 6 o 8 oppure se vogliamo guardarlo dall'altra parte come ha fatto shellx ha due integer (o meglio una divisa due) per ogni FPU.

Veniamo a oggi: non sono sicuro se basterebbero due soli moduli EX (pure EX 2nd gen) per arrivare a equiparare un thuban perché il nuovo EX dovrebbe avere almeno il 50% di ipc in più, o se vuoi una potenza data da ipc+frequenza che arrivi a questa aggiunta rispetto al kaveri.
Se lo porti a 6 Ghz forse ci si arriva ma torniamo sempre nel campo delle speculazioni e ipotesi nostre personali, senza silicio soprattutto.

[tuttodigitale]

Si, però la definizione 2TH contemporanei io la intendo come indipendenti e liberi di essere eseguiti. Se il 2° TH viene elaborato negli "spazi" vuoti lasciati dal primo, non credo rifletta la stessa finalità.
Se vogliamo il modulo è 2TH reali nella parte INT ma con l'FP fino a 128 bit sopporta 2TH, ma con 256 un TH deve aspettare la fine del precedente. Ma questo è un caso che nella pratica è raro, ma lo si critica come se tutte le istruzioni subissero loop.

In termini di concetto io criticherei più la definizione di 2TH fisici perché con l'FP sarebbe più un SMT, di quanto non lo sia quella di 2 core per modulo.

Io credo che per comodità tutti utilizzino definizioni a proprio comodo, come esempio frequenze def bello in g
.
Le definizioni, vengono alterate a fine di marketing è inutile nasconderlo.
Tuttavia il SMT permette davvero di eseguire 2 thread contemporaneamente. Il fatto che eleva le prestazioni solo del 30%, significa grossolanamente che mediamente il ST in un i7 usa circa 2,3 pipeline su 3.

bulldozer e Piledriver sono caratterizzati da un frontend che utilizza il vertical multi threaded. Le istruzioni dei 2thread sono gestiti in diversi cicli di clock.

[Piedone1113]

Le definizioni, vengono alterate a fine di marketing è inutile nasconderlo.
Tuttavia il SMT permette davvero di eseguire 2 thread contemporaneamente. Il fatto che eleva le prestazioni solo del 30%, significa grossolanamente che mediamente il ST in un i7 usa circa 2,3 pipeline su 3.

bulldozer e Piledriver sono caratterizzati da un frontend che utilizza il vertical multi threaded. Le istruzioni dei 2thread sono gestiti in diversi cicli di clock.

A mia memoria:
L'SMT utilizza le parti di core non utilizzate dal primo th, ma se un th usa il 100% della cpu o il 50% è dovuto al codice e non certo all'architettura.

L'SMT può eseguire un th dello stesso processo eseguito dal core, ma non un secondo processo (almeno questo avveniva fino a poco tempo fa, adesso non sono certo che sia ancora così), di conseguenza se su un I7 vengono eseguiti 4 processi mono TH che impegnano il 100% del tempo CPU l' SMT non funge.
Il modulo invece è in grado di eseguire due processi indipendenti simultaneamente.
Da un lato abbiamo ottima possibilità di sfruttare il massimo della cpu (codice permettendo), dall'altra abbiamo un maggior carico supportabile ma con minor sfruttamento della capacità computazionale teorica.

[tuttodigitale]

A mia memoria:
L'SMT utilizza le parti di core non utilizzate dal primo th, ma se un th usa il 100% della cpu o il 50% è dovuto al codice e non certo all'architettura.

Non parliamo di cpu vliw. Il parallelismo a livello di istruzione è a carico della cpu, che poi il codice sia più o meno adatto è un altro paio di maniche.


L'SMT può eseguire un th dello stesso processo eseguito dal core, ma non un secondo processo (almeno questo avveniva fino a poco tempo fa, adesso non sono certo che sia ancora così), di conseguenza se su un I7 vengono eseguiti 4 processi mono TH che impegnano il 100% del tempo CPU l' SMT non funge.
Il modulo invece è in grado di eseguire due processi indipendenti simultaneamente.
mi sembra strano, a dir poco.


Da un lato abbiamo ottima possibilità di sfruttare il massimo della cpu (codice permettendo), dall'altra abbiamo un maggior carico supportabile ma con minor sfruttamento della capacità computazionale teorica.
può mettere i soggetti a quale cpu ti riferisci con
a) un lato abbiamo ottima possibilità di sfruttare il massimo della cpu
b) abbiamo un maggior carico supportabile ma con minor sfruttamento della capacità computazionale teorica

[tuttodigitale]

Non è un caso che ritengo oggi un 4 moduli BD un superquad-core piuttosto che un octacore.
Le FPU in BD sono state potenziate e quindi almeno li mi aspetto che raggiunga il punteggio in Cinebench fatto da un esacore vero. Proprio come è realmente accaduto al quattro moduli BD.
Solo che appunto, quest'ultimo ha solo 4 FPU e non 6 o 8 oppure se vogliamo guardarlo dall'altra parte come ha fatto shellx ha due integer (o meglio una divisa due) per ogni FPU.
Condivido il tuo punto di vista, e proprio per questo ti dico..perchè un super 4 core consuma 125W su 32nm, quando su 45nm amd era riuscita a far girare un esacore?
Il punto non è l'ipc, neanche le prestazioni nel caso del fx9590, ma il consumo. Quest'ultimo non doveva consumare 220 ma 95W, proprio in virtù che è un superquad core. :cool:

PS la fpu è si potenziata, ma quella di SB è ben più attrezzata avendo registri da 256 bit.

[Piedone1113]

Non parliamo di cpu vliw. Il parallelismo a livello di istruzione è a carico della cpu, che poi il codice sia più o meno adatto è un altro paio di maniche.


Non ho capito cosa vorresti dire, ma certamente la cpu non crea TH dal nulla.


mi sembra strano, a dir poco.

Invece è così, ed il nome stesso dato alla funzionalità lo dice, altrimenti invece di Thread avrebbero usato Process (SMP invece di SMT)
Se fosse diverso non si spiegherebbe affatto il maggior carico supportato da BD 4 moduli vs I7 4 Core.
Considera che i processi non sono affatto statici, ma saltellano da un core all'altro a causa del multitasking dell'os e che in un dato istante possono essere attivi solo 4 processi in un 4 core e 8 in un 8 core, poi dipende dalla capacità elaborativa della cpu chi esegue prima un determinato numero di processi.
Dato che Amd ha effettivamente 8 core (e dobbiamo considerare ai fini logici la fpu un coprocessore) la definizione 8 core data a bd 4 moduli è effettivamente corretta poiché a differenza di Intel i suoi 4 moduli possono eseguire 8 processi simultaneamente contro i 4 di 4 core con HT (che poi intel risolva i processi in 16 cicli totali mentre Amd in 20, p.e. , è ininfluente ai fini della discussione)

@Da Wikipedia
Il punto veramente debole della tecnologia Hyper-Threading, quando confrontata con un processore dual core vero e proprio, risiedeva nella capacità di tale tecnologia di gestire in parallelo solo thread e non processi; in altre parole, in un sistema dotato di processore con Hyper-Threading traggono vantaggio solo le applicazioni dotate di più thread, mentre in un sistema dotato di un processore dual core, possono essere eseguiti in parallelo sia i thread di un singolo programma (come avviene con la tecnologia Hyper-Threading), sia i thread appartenenti a processi diversi, che possono quindi essere eseguiti simultaneamente solo in quest'ultimo tipo di sistemi.


può mettere i soggetti a quale cpu ti riferisci con
a) un lato abbiamo ottima possibilità di sfruttare il massimo della cpu
b) abbiamo un maggior carico supportabile ma con minor sfruttamento della capacità computazionale teorica
a) SMT
B) CMT

[tuttodigitale]

Non ho capito cosa vorresti dire, ma certamente la cpu non crea TH dal nulla.

In una cpu superscalare, quale sono quelle x86, il thread viene esaminato dalla cpu in modo da consentire l'esecuzione parallela delle istruzioni su più pipeline di esecuzione.
Questo concetto viene chiamato anche ILP, parallelismo a livello di istruzione, e le cpu cercano di estrarre prestazioni dal thread il più possibile.


Invece è così, ed il nome stesso dato alla funzionalità lo dice, altrimenti invece di Thread avrebbero usato Process (SMP invece di SMT)
permettimi di dubitare. :D
A parte gli scherzi, secondo i documenti di Intel, Hyperthreading è in grado di gestire un thread aggiuntivo appartenente o non ad un determinato processo.
Per il sistema operativo è richiesta la sola compatibilità con sistemi SMP.

Hyper-Threading Technology uses the process- and thread-level parallelism found in contemporary operating systems and high-performance applications by implementing two logical processors on a single chip


Considera che i processi non sono affatto statici, ma saltellano da un core all'altro a causa del multitasking dell'os e che in un dato istante possono essere attivi solo 4 processi in un 4 core e 8 in un 8 core, poi dipende dalla capacità elaborativa della cpu chi esegue prima un determinato numero di processi.
come detto su. Questo è falso


Dato che Amd ha effettivamente 8 core (e dobbiamo considerare ai fini logici la fpu un coprocessore)
Aspetta, io sono il primo a dire che è un octa-core a tutti gli effetti. La FPu condivisa fa perdere circa il 10-15%, molto poco. Questo non toglie che è il singolo core ad avere poche (ma buone) unità a disposizione.

[digieffe]

Mah...penso che a suo tempo AMD, quando era ancora 'culo e camicia' con IBM, poteva uscire( ancor prima di BD) con una microarchitettura simile al Power8 (chi non sognerebbe uno Zen x86, così :sofico: :oink: ):
http://www.hotchips.org/wp-content/uploads/hc_archives/hc25/HC25.20-Processors1-epub/HC25.26.210-POWER-Studecheli-IBM.pdf

Purtroppo sono stati fatti azzardi sbagliati IMO...:( :rolleyes:

Credo invece che Zen sarà impostato diversamente da quanto molti desktopisti s'immaginano. Ritengo molto plausibile una soluzione versatile e polivalente, orientata al cambiamento dei mercati; vuoi per risollevare SeaMicro, sia per i chips personalizzati semicustom, sia per altre applicazioni bivalenti ( vedi K12) e non...

Penso questo rumor sia verosimile e +/- corrispondente alla realtà:
http://www.tweaktown.com/news/46831/amd-teases-zen-powered-32-core-apu-hbm2-more/index.html

Perciò, reputo attendibile l'adozione di Zen con serigrafia @ 14nm (quanto HP, non lo so...), con HDL e relative basse frequenze di lavoro. :O

+1

[Mister D]

@tuttodigitale:
Ciao,
guarda che la spiegazione di Piedone1113 è corretta sul SMT.
Per capire come funziona ti riporto un esempio che ti può essere utile:
Un processo può contenere più thread e tu puoi voler eseguire più processi contemporaneamente (multitasking).
Es word (composto da thw1 e thw2) ed execl (composto da the1 e the2).
Situazione 1:
single core
come fa il sistema operativo a far eseguire contemporaneamente word ed excel? Usa il multithreading temporale con la tecnica del time-slice switch. Alternativamente fa processare thread del processo word e del processo execl
thw1->the1->thw2->the2->thw2->the1
Questo scambio di thread di un processo e l'altro ci inganna e un single core può eseguire contemporaneamente 2 processi (bada bene 2 processi non 2 thread).
Situazione 2:
single core con SMT 2 vie (aka HT di intel)
unità fisica: thw1-pausa->the1-pausa->thw2->the1
unità logica: --------thw2->-------the2->thw1->the2
Come vedi la simultaneità sta nel fatto che mentre aspetta (perché stallato) che thw1 sia eseguito la prima volta dal core fisico fa eseguire il thread dello stesso processo all'unità logica. Non può far eseguire il thread di excel perché fa parte di un altro processo.
Situazione 3:
dual core
unità fisica core 1: thw1->the1->thw2->thw1
unità fisica core 2: thw2->the2->the1->the2
Come vede un vero dual core può fare eseguire in contemporanea sia thread appartenenti allo stesso processo (thw1 e thw2) come fa anche un single core + HT ma può anche far eseguire in contemporanea thread di processi differenti (thw2 nello stesso momento di the1).
Questa sottile differenza accade perché in una architettura SMT non tutte le parti del core integer vengono replicate come invece accade in un vero dual core.

Il CMT è una via di mezzo perché è un dual core a livello di modulo come unità integer mentre è un SMT a 2 vie per lo sola FPU che non a caso amd ha definito FlexFPU.


Spero di averti dato una mano a capire meglio il SMT di intel ma non solo di intel visto che IBM utilizza il SMT da lungo tempo.;)

[digieffe]

@tuttodigitale:
Ciao,
guarda che la spiegazione di Piedone1113 è corretta sul SMT.
Per capire come funziona ti riporto un esempio che ti può essere utile:
Un processo può contenere più thread e tu puoi voler eseguire più processi contemporaneamente (multitasking).
Es word (composto da thw1 e thw2) ed execl (composto da the1 e the2).
Situazione 1:
single core
come fa il sistema operativo a far eseguire contemporaneamente word ed excel? Usa il multithreading temporale con la tecnica del time-slice switch. Alternativamente fa processare thread del processo word e del processo execl
thw1->the1->thw2->the2->thw2->the1
Questo scambio di thread di un processo e l'altro ci inganna e un single core può eseguire contemporaneamente 2 processi (bada bene 2 processi non 2 thread).
Situazione 2:
single core con SMT 2 vie (aka HT di intel)
unità fisica: thw1-pausa->the1-pausa->thw2->the1
unità logica: --------thw2->-------the2->thw1->the2
Come vedi la simultaneità sta nel fatto che mentre aspetta (perché stallato) che thw1 sia eseguito la prima volta dal core fisico fa eseguire il thread dello stesso processo all'unità logica. Non può far eseguire il thread di excel perché fa parte di un altro processo.
Situazione 3:
dual core
unità fisica core 1: thw1->the1->thw2->thw1
unità fisica core 2: thw2->the2->the1->the2
Come vede un vero dual core può fare eseguire in contemporanea sia thread appartenenti allo stesso processo (thw1 e thw2) come fa anche un single core + HT ma può anche far eseguire in contemporanea thread di processi differenti (thw2 nello stesso momento di the1).
Questa sottile differenza accade perché in una architettura SMT non tutte le parti del core integer vengono replicate come invece accade in un vero dual core.

Il CMT è una via di mezzo perché è un dual core a livello di modulo come unità integer mentre è un SMT a 2 vie per lo sola FPU che non a caso amd ha definito FlexFPU.


Spero di averti dato una mano a capire meglio il SMT di intel ma non solo di intel visto che IBM utilizza il SMT da lungo tempo.;)

manca solo una precisazione: chi impedirebbe allo scheduler di far eseguire (nella pausa di un core fisico) un processo totalmente differente al core logico?
vorresti dirmi che l'intero set di registri non è duplicato per entrambi i core (fisico/logico) nel register file?

anche perché la differenza tra thread e processo è marcata solo in alcuni SO, in altri tipo linux può essere di fatto nulla, quando diedi un'occhiata agli scheduler su come allocavano le risorse sui vari tipi di core, c'era tutto un altro modo di inquadrare la cosa (partendo dal numa fino ad arrivare all'ht di intel) ma questa differenza non la ricordo (probabile colpa della mia memoria)

se trovo l'articolo lo posto.

[digieffe]

l'ho letto più di un paio di anni fa https://lwn.net/Articles/80911/, spero di ricordare cosa scrivo. Si utilizza task in generale e process per processo.

non posso rileggere riesco a stento seguire il thread, ma questa questione è da chiarire :). attendo conferme o smentite.


EDIT: mi sovvinene che a parte le informazioni scritte nelle tabelle acpi, che specificano la topologia dei core (compresi fisici logici) il SO, può ignorare tutto ed utilizzarli tutti come se fossero fisici, fatto salvo eventuali problemi prestazionali dati dall'esaurimento fisico delle risorse del core p.e. cache, ...

EDIT2: cattiva gestione che probabilemente avveniva con i primi scheduler che credevano di gestire 2 "cpu".

[Piedone1113]

l'ho letto più di un paio di anni fa https://lwn.net/Articles/80911/, spero di ricordare cosa scrivo. Si utilizza task in generale e process per processo.

non posso rileggere riesco a stento seguire il thread, ma questa questione è da chiarire :). attendo conferme o smentite.


EDIT: mi sovvinene che a parte le informazioni scritte nelle tabelle acpi, che specificano la topologia dei core (compresi fisici logici) il SO, può ignorare tutto ed utilizzarli tutti come se fossero fisici, fatto salvo eventuali problemi prestazionali dati dall'esaurimento fisico delle risorse del core p.e. cache, ...

EDIT2: cattiva gestione che probabilemente avveniva con i primi scheduler che credevano di gestire 2 "cpu".

Parlo da profano, ma:
L'os può inviare più processi contemporaneamente ai core con ht credendo (nei vecchi os, adesso l'smt è gestito molto meglio) che siano core reali.
Succede che un processo resti in attesa che il core fisico esegua i compiti assegnatoli per tempo cpu sul core 0 prima di eseguire il processo sul core virtuale 1.
Se ricordi proprio con la prima famiglia di i7 c'erano giochi che offrivano prestazioni superiori con ht disabilitato su xp perché l'os non distingueva core reali da virtuali ed assegnava i processi ad minchiam.
Sappiamo per certo che l'ht utilizza le parti di cpu in attesa e ci troviamo una situazione tipo:
processo 1 sul core 0 in esecuzione, processo 2 in attesa del core 1
Fine del tempo cpu sul core 0 del processo 1, caricamento dei dati nei registri del core1, pausa del processo 0 ed esecuzione del processo 2 sul core1 (che ha tutte le risorse del core 0 disponibili per l'esecuzione del processo 2 sul core1)
Effettivamente abbiamo il processo 1 eseguito sul core 0 ed il processo 2 eseguito sul core1, ma mai i due processi vengono eseguiti in contemporanea sui due core, ma in modo alternato.
Se fai caso anche alle assegnazioni dei processi sui core questi vengono assegnati prima ai core pari (0, 2, 4, 6) e solo in casi estremi l'os invia (stupidamente) processi ai core dispari (quelli virtuali) rallentando in alcuni casi l'esecuzione dei task.
Se così non fosse non avremmo un core reale con HT, ma due core distinti, con parti condivise che all'occorrenza possono unirsi e diventare un supercore.

[paolo.oliva2]

A suo tempo avevo fatto dei test sul vecchio 8150 e poi sull'8350, in cui riscontrano un aumento prestazionale nel caso di forte carico.
Non ho ben chiaro se la cosa dipendesse o meno da una errata valutazione dell'SO sul carico o che il modulo con più TH rendesse meglio.

Io utilizzato Freemaker per conversioni video, e i tempi migliori li riscontrano con 3 TH a modulo e 12 TH totali o 4 TH a modulo per 16 totali, che variavano a seconda se convettivo AVI o MKV o misti.
Praticamente sommando i tempi di ciascuna sessione programma, il tempo complessivo diminuiva. Onestamente, considerando che ad esempio con OCCT si ottengono le massime tempo del procio, con i miei carichi di lavoro riuscivo addirittura a ottenere temp superiori, di qui la mia interpretazione (personalissima) , che valutare un FX solamente sul bench secco su una singola applicazione non riflette al 100% le potenzialità del procio.

È possibile che architetturalmente BD con il CMT, dando priorità al carico, con 1 singolo processo non sfrutti totalmente il suo potenziale mentre con più TH le ALU vengano alimentate più efficacemente?

[tuttodigitale]

....
Cosa manca al SMT per non eseguire 2 processi, fermo restando che è INTEL, non wikipedia italiana ( quella inglese ho controllato e dice tutt'altro) a dire che il SMT aumenta il parallelismo a livello di processi?

IBM ha condotto addirittura uno studio (quindi si dà per scontato che il SMT porti dei vantaggi anche con i processi) http://researcher.watson.ibm.com/researcher/files/jp-INOUEHRS/IISWC2010_inoue_slides.pdf nella slide numero 7, c'è lo scaling per Nehalem ad occhio +22% per i processi e +31% per i thread.

[digieffe]

Parlo da profano, ma:
L'os può inviare più processi contemporaneamente ai core con ht credendo (nei vecchi os, adesso l'smt è gestito molto meglio) che siano core reali.
Succede che un processo resti in attesa che il core fisico esegua i compiti assegnatoli per tempo cpu sul core 0 prima di eseguire il processo sul core virtuale 1.
Se ricordi proprio con la prima famiglia di i7 c'erano giochi che offrivano prestazioni superiori con ht disabilitato su xp perché l'os non distingueva core reali da virtuali ed assegnava i processi ad minchiam.
Sappiamo per certo che l'ht utilizza le parti di cpu in attesa e ci troviamo una situazione tipo:
processo 1 sul core 0 in esecuzione, processo 2 in attesa del core 1
Fine del tempo cpu sul core 0 del processo 1, caricamento dei dati nei registri del core1, pausa del processo 0 ed esecuzione del processo 2 sul core1 (che ha tutte le risorse del core 0 disponibili per l'esecuzione del processo 2 sul core1)
Effettivamente abbiamo il processo 1 eseguito sul core 0 ed il processo 2 eseguito sul core1, ma mai i due processi vengono eseguiti in contemporanea sui due core, ma in modo alternato.
Se fai caso anche alle assegnazioni dei processi sui core questi vengono assegnati prima ai core pari (0, 2, 4, 6) e solo in casi estremi l'os invia (stupidamente) processi ai core dispari (quelli virtuali) rallentando in alcuni casi l'esecuzione dei task.
Se così non fosse non avremmo un core reale con HT, ma due core distinti, con parti condivise che all'occorrenza possono unirsi e diventare un supercore.

provo un attimo a riordinare:

- in realtà non esiste il core fisico e quello logico, ma due core logici all'interno dello stesso core fisico (vedi link preced.)
- scegliere il core logico 0 o 1 non fa differenza.
- entrambi i core logici hanno il set di registri come se ognuno fosse un core fisico
- l'assegnazione dei task/processi/thread ai core logici è totalmente indipendente
- assegnare un "task" ad un core logico vuol dire caricare i registri nello stesso
- i due core logici possono essere contemporaneamente (nel significato fisico ovvero allo stesso tempo) caricati con i tasks
- caricati i due core logici, sarà la circuiteria di controllo che determinerà come alternarne l'esecuzione senza che il SO intervenga.
- se vuole il SO può sostituire uno dei due "task" oppure mettere in idle uno o entrambi i core logici.

[digieffe]

aggiungo è normale che vengano caricati prima i core pari, in tal modo ogni core fisico dedicherà il massimo delle risorse al singlolo task.
caricando anche il secondo core logico ovviamente le prestazioni per task scenderanno, aumentando quelle globali.

es:
task 0 = 100
task 0 + 1 = 130 di media 65 a task.

se c'è una perdita di prestazioni questa è dovuta solo ad un sottodimensionamento del core fisico. il power8 con 8 task su un core fa 220 (rispetto a 100 single task).

[digieffe]

A suo tempo avevo fatto dei test sul vecchio 8150 e poi sull'8350, in cui riscontrano un aumento prestazionale nel caso di forte carico.
Non ho ben chiaro se la cosa dipendesse o meno da una errata valutazione dell'SO sul carico o che il modulo con più TH rendesse meglio.

Io utilizzato Freemaker per conversioni video, e i tempi migliori li riscontrano con 3 TH a modulo e 12 TH totali o 4 TH a modulo per 16 totali, che variavano a seconda se convettivo AVI o MKV o misti.
Praticamente sommando i tempi di ciascuna sessione programma, il tempo complessivo diminuiva. Onestamente, considerando che ad esempio con OCCT si ottengono le massime tempo del procio, con i miei carichi di lavoro riuscivo addirittura a ottenere temp superiori, di qui la mia interpretazione (personalissima) , che valutare un FX solamente sul bench secco su una singola applicazione non riflette al 100% le potenzialità del procio.

È possibile che architetturalmente BD con il CMT, dando priorità al carico, con 1 singolo processo non sfrutti totalmente il suo potenziale mentre con più TH le ALU vengano alimentate più efficacemente?

ripensando alla resistenza al carico di BD 8350 mi sovviene che questa sia dovuta alla dimensione delle caches:

8350 4x64 L1inst, 8x16 L1 data, 8m L2, 8M L3.

come reaggirebbe al carico un 3770 con 64+32 L1, 2Mx4 L2 e 8M L3 (esclusiva rispetto alla L2) di fatto 16M di cache?

[Piedone1113]

Cosa manca al SMT per non eseguire 2 processi, fermo restando che è INTEL, non wikipedia italiana ( quella inglese ho controllato e dice tutt'altro) a dire che il SMT aumenta il parallelismo a livello di processi?

IBM ha condotto addirittura uno studio (quindi si dà per scontato che il SMT porti dei vantaggi anche con i processi) http://researcher.watson.ibm.com/researcher/files/jp-INOUEHRS/IISWC2010_inoue_slides.pdf nella slide numero 7, c'è lo scaling per Nehalem ad occhio +22% per i processi e +31% per i thread.
Stiamo parlando di due cose completamente diverse.
Le performance sono una cosa, la capacità di eseguire più processi in contemporanea un'altra.
Ho anche specificato bene che Amd può eseguire 8 processi in contemporanea e risolverli in 20 cicli, mentre 4ht intel può eseguire 4 processi in contemporanea, ma al tempo stesso risolverne 8 in 16 cicli.
Se analizzi i risultati dello studio Abbiamo che a fronte di un aumento delle prestazioni in Multi Th del 32% abbiamo un aumento del solo 22% di performance sui processi e questo ti dovrebbe gia far riflettere sul fatto che th e processi non vengono eseguiti allo stesso modo (altrimenti se fosse possibile eseguire due processi contemporaneamente l'aumento sarebbe simile).
Facendo la prova del nove diciamo che core senza HT abbiamo 100% in 100 secondi
Core con ht attivo abbiamo 100% in 75,8 secondi
Ne consegue che abbiamo il 24,2% teorico, in realtà meno dovuto ai cicli per caricare i dati ed i registri, di aumento di performance sui processi, ma che sono dovuti non alla capacità di eseguire più processi contemporaneamente, ma al minor tempo usato per risolvere il singolo processo.

[Piedone1113]

ripensando alla resistenza al carico di BD 8350 mi sovviene che questa sia dovuta alla dimensione delle caches:

8350 4x64 L1inst, 8x16 L1 data, 8m L2, 8M L3.

come reaggirebbe al carico un 3770 con 64+32 L1, 2Mx4 L2 e 8M L3 (esclusiva rispetto alla L2) di fatto 16M di cache?
Male con perdite prestazionali prossime al 50% proprio a causa dell'ht che carica processi diversi in sequenza continua (parlando di cache di ampiezza e tipologia simile).
Al tempo stesso BD con cache inclusiva, ma più veloce perderebbe un buon 20% di prestazioni dovuta ai vari cache miss che lo affliggerebbero.

[digieffe]

Se analizzi i risultati dello studio Abbiamo che a fronte di un aumento delle prestazioni in Multi Th del 32% abbiamo un aumento del solo 22% di performance sui processi e questo ti dovrebbe gia far riflettere sul fatto che th e processi non vengono eseguiti allo stesso modo (altrimenti se fosse possibile eseguire due processi contemporaneamente l'aumento sarebbe simile).

thread e processi vengono eseguiti allo stesso modo, la cpu è non è consapevole di cosa sta eseguendo, per essa sono solo istruzioni.

allora perché c'è diffenza tra thread e processi?
perchè i thread hanno più dati in comune tra loro stessi e quindi generano meno cache miss.

[digieffe]

Male con perdite prestazionali prossime al 50% proprio a causa dell'ht che carica processi diversi in sequenza continua (parlando di cache di ampiezza e tipologia simile).
Al tempo stesso BD con cache inclusiva, ma più veloce perderebbe un buon 20% di prestazioni dovuta ai vari cache miss che lo affliggerebbero.

non voglio offendere nessuno ma secondo me non hai le idee ben chiare su quanto hai scritto nel post citato, purtroppo e me ne scuso in anticipo non ho assolutamente tempo per confutare, anzi sono andato ben oltre la mia disponibilità.
se hai voglia spiega da dove sono uscite quelle percentuali (50%, 20%) seguirò la tua spiegazione.

[tuttodigitale]

@digieffe
ti faccio i miei complimenti. :O

Per inciso il SMT duplica (non condivide) la logica per gestire i thread:
stato registi, renamed RSB, large page ITLB e altre sezioni sono partizionate staticamente : a tutti gli effetti per funzionare non è necessario che il SO conosca HT (ma son dolori assai quando si ha che fare con diversi core).
Visto che siamo in tema di definizioni, ricordo che un sistema operativo multithreaded, per definizione è in grado di gestire più thread e più processi. Se una delle sue condizioni non è vera si parla più propriamente si multitasking (che ha ulteriori definizioni ma ne vogliamo veramente parlare? :ciapet: )

Stiamo parlando di due cose completamente diverse.
Le performance sono una cosa, la capacità di eseguire più processi in contemporanea un'altra.
.
Dimmi che stai scherzando?
1) ti sei basato su wikipedia (per giunta in versione italiana)
2) è Intel a dire che HT aumenta le prestazioni a livello di processi.
3) nello studio IBM (slide 7) si può vedere come Nehalem beneficia comunque del secondo thread anche se questo è in un processo separato.

ti bastava vedere i test sul multitasking fatto con il pentium 4 HT.

Abbiamo che a fronte di un aumento delle prestazioni in Multi Th del 32% abbiamo un aumento del solo 22% di performance sui processi e questo ti dovrebbe gia far riflettere sul fatto che th e processi non vengono eseguiti allo stesso modo (altrimenti se fosse possibile eseguire due processi contemporaneamente l'aumento sarebbe simile).
scusami, ma come fa a guadagnare il 22% dal secondo thread, se non è in grado di usarlo nel caso in cui fa parte di un altro processo?


Se così non fosse non avremmo un core reale con HT, ma due core distinti, con parti condivise che all'occorrenza possono unirsi e diventare un supercore.
OMG, in questo thread non si capisce più niente :D
1) se AMD ha cluster int dedicati per singolo thread, è un super quadcore.
2) Intel che ha cluster int condivisi tra 2 thread, è un octa-core :eek:

Quanta fantasia :O
la cosa strana, che nessun punto di vista mi sembra errato.

thread e processi vengono eseguiti allo stesso modo, la cpu è non è consapevole di cosa sta eseguendo, per essa sono solo istruzioni.
esattamente.

[Mister D]

manca solo una precisazione: chi impedirebbe allo scheduler di far eseguire (nella pausa di un core fisico) un processo totalmente differente al core logico?
vorresti dirmi che l'intero set di registri non è duplicato per entrambi i core (fisico/logico) nel register file?

anche perché la differenza tra thread e processo è marcata solo in alcuni SO, in altri tipo linux può essere di fatto nulla, quando diedi un'occhiata agli scheduler su come allocavano le risorse sui vari tipi di core, c'era tutto un altro modo di inquadrare la cosa (partendo dal numa fino ad arrivare all'ht di intel) ma questa differenza non la ricordo (probabile colpa della mia memoria)

se trovo l'articolo lo posto.

Ciao,
ma scusate ragionateci un po'. Intel stessa ha sempre detto che il vantaggio dell'HT e del SMT è poter replicare parte di un core fisico (e in particolare replica solamente la parte detta in inglese Architectur State) per consumare poco die size (circa il +5) per avere un vantaggio quando le pipeline stallano. Ho sbagliato a scrivere PAUSA, avrei dovuto scrivere STALLO. In quel momento un processore senza HT/SMT non può caricare un altro thread ma spreca solo del tempo. L'idea geniale di intel e IBM è occupare quel tempo per allocare e far processare un'altro thread. Ma quale altro thread? Solo quello permesso dalle risorse condivise. Ma quali sono? Le risorse condivise sono in inglese le Processor Execution Resources. Queste risorse hanno tutte le informazioni dei thread da far eseguire appartenenti ad uno stesso processo. Quando stalla la pipeline, l'unità di fetch e lo scheluder immediatamente vedono gli altri thread in coda al primo thread stallato e fanno subito eseguire gli altri comandi perché esiste un secondo core virtuale composto dalle risorse dedicate (Architectur State) e dalle risorse condivise (Execution Resources). Non può andare a prendere un thread di un altro processo perché dovrebbe svuotare tutto per iniziare da capo.
Questo metodo è trasparente al OS che viene gabbato credendo di affidare sempre thread e processi ad unità complete e fisice.
Se hai tempo leggi questo documento di Intel:
http://www.diku.dk/OLD/undervisning/2004f/303/Hyper-Thread.pdf
In particolare guardate tutti cosa dice Intel della sua tecnologia:
Hyper-Threading Technology makes a single physical
processor appear as multiple logical processors [11, 12].
To do this, there is one copy of the architecture state for
each logical processor, and the logical processors share
a single set of physical execution resources. From a
software or architecture perspective, this means
operating systems and user programs can schedule
processes or threads to logical processors as they would
on conventional physical processors in a multiprocessor
system. From a microarchitecture
perspective, this means that instructions from logical
processors will persist and execute simultaneously on
shared execution resources.

Shared è la parolina che dovrebbe farvi capire che nel'HT e credo anche nel più generale SMT i thread affidati ai core virtuali/logici devono essere quelli condivisi con l'unità fisica.

Attenzione che il fatto che aumenti a livello di thread il throughput è perché una tradizionale archittettura multi core perde tempo negli stalli. Tutto qui.
Nella slide 7 di IBM postata da tuttudigitale si fa riferimento a due processori, Niagara e Nehalem di intel. Poi hanno fatto i test con SMT abilitato e SMT disabilitato facendo vedere lo scaling quando si aumentano i thread da processare e infatti il SMT guadagna. Mi pare chiaro perché guadagni. Se mi permette l'analogia nei motori endotermici, il turbo-compressore è un recupero di energia del motore a ciclo otto in cui si recupera l'energia termica dei gas combusti per aumentare la pressione di alimentazione. Energia che andrebbe persa. Il SMT fa la stessa cosa: consente ai processori di recuperare l'energia sprecata nei momenti di stallo.
Chiaro che un single core + ht (smt a 2 vie) e meno potente di un vero dual core perché il dual core ha le risorse duplicate per intero avendo due core integer fisici che possono processare thread di stessi processi o differenti processi.

Il fatto che un single core possa processare più processi contemporaneamente è uno perché i processori super scalari hanno più pipeline all'interno di un core integer e due perché usano la tecnica del multihread temporale:
https://en.wikipedia.org/wiki/Super-threading

Ora non so se intel nelle versione più moderna del suo iniziale HT (ora SMT) ha in qualche modo replicato anche altre risorse che gli consentano di processare anche thread che non sono dello stesso processo di cui il primo thread è stallato. Da quello che mi pare di capire da tuttodigitale dovrebbe essere sì. Se lo postate però mi piacerebbe leggerlo;)

[epimerasi]

Ciao,
ma scusate ragionateci un po'. ... From a
software or architecture perspective, this means
operating systems and user programs can schedule
processes or threads to logical processors as they would
on conventional physical processors in a multiprocessor
system. From a microarchitecture
perspective, this means that instructions from logical
processors will persist and execute simultaneously on
shared execution resources.
...

Eppure c'e` scritto questo proprio nel pezzo che hai riportato...

[epimerasi]

....
Il fatto che un single core possa processare più processi contemporaneamente è uno perché i processori super scalari hanno più pipeline all'interno di un core integer e due perché usano la tecnica del multihread temporale:
https://en.wikipedia.org/wiki/Super-threading
...

I processori single core pre hyper threading erano superscalari, ma comunque elaboravano un processo alla volta. La presenza di un'architettura superscalare e l'esecuzione out of order non c'entra niente con l'esecuzione di piu` processi, non nasce per questo motivo.

L'hyper-threading e` stato inventato successivamente per sfruttare gli stalli nell'esecuzione per esguire piu` task contemporaneamente, ma un task puo` essere talmente ottimizzato da non lasciare pipeline libere. (e infatti in quel caso l'hyper-threading non serve a niente).

[Mister D]

Altri documenti universitari sull'HT/SMT:
http://gec.di.uminho.pt/DISCIP/Minf/ac0607/FAQ-08.pdf
http://web.eecs.umich.edu/~tnm/trev_test/dissertationsPDF/debbieM.pdf
Tutti e due molto interessanti e si capisce benissimo che l'HT è un metodo di allocazione dinamica dei thread per recuperare i momenti di inattività dovuti a stalli della pipeline ma a causa della duplicazione solo di parte delle risorsi componenti un core integer questo può processare thread appartenenti allo stesso processo già preso in pasto dall'unità di esecuzione del core integer (che è condivisa). Nel primo articolo guardate la figura 4 che mette a confronto un dual core con un core + ht.;)

[Mister D]

Eppure c'e` scritto questo proprio nel pezzo che hai riportato...

Sì ma lì spiega che dalla parte del sistema operativo è trasparente l'adozione del SMT o HT. Lo scheluder da in pasto processi (che contengono più thread) e poi ci pensano le unità del processore a dividere bene i compiti allocando al core fisico + core ht diversi processi. Quando carica il primo processo e i quindi i diversi thread del processo, appena succede che il primo thread stalla interviene il core logico del ht a impegnare la pipeline con l'esecuzione di un secondo thread dello stesso processo. Io ho capito così e lo dice nella frase che ho evidenziato in grassetto che tradotta dovrebbe essere:
Dalla prospettiva della microarchitettura, ciò significa che le istruzioni dei processori logici persisteranno ed verranno eseguite simultaneamente all'interno delle risorse di esecuzione condivise.

Cioè thread facenti parte di uno stesso processo (chiaramente l'unità logica farà eseguire i thread di uno stesso processo che non hanno relazioni di dipendenza). Altrimenti come si spiega che un dual core (senza HT) è più veloce di un single core +ht nonostante gli stalli?

Io ho inteso così il discorso, però se sto sbagliando qualcosa ditemi e fatemi capire dove sbaglio nel ragionamento;)

[epimerasi]

Sì ma lì spiega che dalla parte del sistema operativo è trasparente l'adozione del SMT o HT. Lo scheluder da in pasto processi (che contengono più thread) e poi ci pensano le unità del processore a dividere bene i compiti allocando al core fisico + core ht diversi processi. Quando carica il primo processo e i quindi i diversi thread del processo, appena succede che il primo thread stalla interviene il core logico del ht a impegnare la pipeline con l'esecuzione di un secondo thread dello stesso processo. Io ho capito così e lo dice nella frase che ho evidenziato in grassetto che tradotta dovrebbe essere:
Dalla prospettiva della microarchitettura, ciò significa che le istruzioni dei processori logici persisteranno ed verranno eseguite simultaneamente all'interno delle risorse di esecuzione condivise.

Cioè thread facenti parte di uno stesso processo (chiaramente l'unità logica farà eseguire i thread di uno stesso processo che non hanno relazioni di dipendenza). Altrimenti come si spiega che un dual core (senza HT) è più veloce di un single core +ht nonostante gli stalli?

Io ho inteso così il discorso, però se sto sbagliando qualcosa ditemi e fatemi capire dove sbaglio nel ragionamento;)

Pensa che io da quello che ho letto capisco il contrario :D
Anche la figura a cui fai riferimento mi fa pensare il contrario, visto che le risorse che controllano il contesto del task sono duplicate.

Ammetto cmq di rimanere col dubbio.

[george_p]

@digieffe

OMG, in questo thread non si capisce più niente :D
1) se AMD ha cluster int dedicati per singolo thread, è un super quadcore.
2) Intel che ha cluster int condivisi tra 2 thread, è un octa-core :eek:

Quanta fantasia :O
la cosa strana, che nessun punto di vista mi sembra errato.


Certo, per questo forse amd intendeva battere intel con "core fisici". Però e mi rifaccio sempre alle conclusioni di Corsini nel 2011, anche per me 8 core integer + 4 fpu non son da considerarsi 8 core completi.

Se l'FPU è stata introdotta come componente fisso all'interno della cpu dalla fine degli anni 80 un motivo ci sarà perché "Integer" e Float Point Unit" siano da considerarsi un core completo oggi e da molti anni.

Possiamo anche considerare octa-core un FX 8xxx per tutti quei programmi che si basano su soli calcoli interi e quadcore per tutti quelli che fanno uso intensivo di calcoli in virgola mobile.
Così accontentiamo tutti ma sempre qualcosa non torna.

Ad amd non servono più punti di vista ma soldoni e quote di mercato elevate.
Cosa che ha capito quasi subito 4 anni fa.

[Mister D]

I processori single core pre hyper threading erano superscalari, ma comunque elaboravano un processo alla volta. La presenza di un'architettura superscalare e l'esecuzione out of order non c'entra niente con l'esecuzione di piu` processi, non nasce per questo motivo.

L'hyper-threading e` stato inventato successivamente per sfruttare gli stalli nell'esecuzione per esguire piu` task contemporaneamente, ma un task puo` essere talmente ottimizzato da non lasciare pipeline libere. (e infatti in quel caso l'hyper-threading non serve a niente).

Scusami tanto ma allora il mio vecchio athlon 64 3500+ (single core super scalare) come fa ad eseguire più processi? Se fosse come dici te ogni programma avviato in più si sarebbe messo in coda fino alla fine degli altri programmi precedenti. Anche se lento le cose contemporaneamente le faceva solo che i processi e i loro thread venivano eseguiti alternativamente, cioè primi uno e poi l'altro, invece l'HT consente di eseguirli nello stesso momento (cioè nel momento di stallo):
http://arstechnica.com/features/2002/10/hyperthreading/3/

[Mister D]

Pensa che io da quello che ho letto capisco il contrario :D
Anche la figura a cui fai riferimento mi fa pensare il contrario, visto che le risorse che controllano il contesto del task sono duplicate.

Ammetto cmq di rimanere col dubbio.

Parto dal punto che io non avendo studiato queste cose, leggo e le interpreto usando la logica. Forse sbaglio ma le risorse duplicate servono proprio perché i thread di uno stesso processo non abbiano relazione di dipendenza oltre che allocare e smistare le risorse occorrenti l'elaborazione dei thread.
Perché se il thread B è legato al risultato del thread A di uno stesso processo, quando la pipeline stalla sul thread A, le risorse duplicate, come possono dargli in pasto un thread che parte dal risultato di quello stallato? Si avrebbe l'attesa dell'attesa:D
Altra cosa, il thread A stallato non è che viene buttato a mare ma viene ripreso e si va avanti.
Per il fatto che suppongo, a questo punto non ne sono certo nemmeno io, che le risorse duplicate del core logico non possono dare in pasto alle risorse di esecuzioni condivise i thread di un altro processo è perché dovrebbe perdere il risultato del thread A stallato facendo svuotare tutta la pipeline e ricaricando tutto con i thread di un altro processo.
Cosa succede se la pipeline non stalla? L'ht non interviene e continua a processare i vari thread di stessi processi e di altri processi uno dietro l'alto o alternativamente sempre con la tecnica del super-thread. Ed ecco che così si spiega perché in alcuni software l'impatto è quasi nullo dell'HT. Se ho scritto bene un software i momenti di stallo dovrebbero tendere a zero e la pipeline è sempre piena e in quel caso l'unica tecnica per aumentare la potenza è:
aggiungere pipeline al core (maggiore ILP) o
aumentare il numero dei core o
utilizzare la tecnica del super thread smistando i thread di diversi processi su un singolo core per farli elaborare chiaramente non contemporaneamente (nell'articolo di arstecnica sarebbe la prima figura in cui processo thread rosso, poi quello giallo, poi rosso, poi 2 gialli, poi 2 rossi e così via).

Almeno io ho interpreto così però non so se nelle nuove implementazioni del SMT (da neahlem in poi) il core logico oltre processare il thread B dello stesso processo del thread A può anche infilare un thread C di un secondo processo. Qua ho io il dubbio;)

[epimerasi]

Scusami tanto ma allora il mio vecchio athlon 64 3500+ (single core super scalare) come fa ad eseguire più processi? Se fosse come dici te ogni programma avviato in più si sarebbe messo in coda fino alla fine degli altri programmi precedenti. Anche se lento le cose contemporaneamente le faceva solo che i processi e i loro thread venivano eseguiti alternativamente, cioè primi uno e poi l'altro, invece l'HT consente di eseguirli nello stesso momento (cioè nel momento di stallo):
http://arstechnica.com/features/2002/10/hyperthreading/3/

Stai confondendo il multiprocessing/threading con il multitasking, ma sono cose indipendenti.
https://it.wikipedia.org/wiki/Multitasking

Da decenni i sistemi operativi eseguono piu` processi contemporaneamente, ma in macchine che non siano multicore (a prescindere che i core siano fisici o logici) e` una "illusione", i processi vengono sempre eseguiti uno alla volta.

[Piedone1113]

Stai confondendo il multiprocessing/threading con il multitasking, ma sono cose indipendenti.
https://it.wikipedia.org/wiki/Multitasking

Da decenni i sistemi operativi eseguono piu` processi contemporaneamente, ma in macchine che non siano multicore (a prescindere che i core siano fisici o logici) e` una "illusione", i processi vengono sempre eseguiti uno alla volta.

Ma il problema è che io affermo che 4 core ht possono eseguire 4 processi ed 8 th al massimo contemporaneamente, mentre di contro mi si dice che possono essere eseguiti 8 processi indipendenti simultaneamente.
Bene in questo momento ho 22 processi attivi e 38 th in esecuzione contemporanea, che cpu ho?

[epimerasi]

Parto dal punto che io non avendo studiato queste cose, leggo e le interpreto usando la logica.
La dipendenza dei dati di un thread da un altro thread e` stabilita a livello di programmazione, non di esecuzione.
Se avviene una cosa del genere, deve essere bravo il programmatore ad ottimizzare il programma affinche` i thread dipendenti non passino troppo tempo ad aspettare (a volte e` possibile e a volte no)

Forse sbaglio ma le risorse duplicate servono proprio perché i thread di uno stesso processo non abbiano relazione di dipendenza oltre che allocare e smistare le risorse occorrenti l'elaborazione dei thread.

Le risorse duplicate, a quanto capisco, servono proprio per effettuare velocemente il context switch. Cioe` passare dall'esecuzione di un thread, all'esecuzione di un altro.
La CPU non puo` sapere a priori se i dati necessari all'esecuzione del secondo thread dipendono dal primo, questo sta all'ottimizzazione del programmatore.

Proprio a questo proposito, uno scenario in cui il secondo thread appartiene adun processo indipendente dal primo sarebbe piu` favorevole all'hyperthreading perche` e` meno probabile che dipenda dai dati del primo thread (anche se non e` detto, ripeto, dipende tutto dal modello di programmazione con cui e` stato scritto il programma).


Perché se il thread B è legato al risultato del thread A di uno stesso processo, quando la pipeline stalla sul thread A, le risorse duplicate, come possono dargli in pasto un thread che parte dal risultato di quello stallato? Si avrebbe l'attesa dell'attesa:D
Altra cosa, il thread A stallato non è che viene buttato a mare ma viene ripreso e si va avanti.
Per il fatto che suppongo, a questo punto non ne sono certo nemmeno io, che le risorse duplicate del core logico non possono dare in pasto alle risorse di esecuzioni condivise i thread di un altro processo è perché dovrebbe perdere il risultato del thread A stallato facendo svuotare tutta la pipeline e ricaricando tutto con i thread di un altro processo.

Coem ti dicevo prima, la dipendenza dei dati di un task da un altro puo` accadere sia fra thread che fra processi, dipende tutto da come e` stato scritto il programma.
Se il secondo thread dipende dal primo che non ha finito, deve aspettare, sempre.
Questo vale anche per i processi.

Cosa succede se la pipeline non stalla? L'ht non interviene e continua a processare i vari thread di stessi processi e di altri processi uno dietro l'alto o alternativamente sempre con la tecnica del super-thread. Ed ecco che così si spiega perché in alcuni software l'impatto è quasi nullo dell'HT. Se ho scritto bene un software i momenti di stallo dovrebbero tendere a zero e la pipeline è sempre piena e in quel caso l'unica tecnica per aumentare la potenza è:
aggiungere pipeline al core (maggiore ILP) o
aumentare il numero dei core o
utilizzare la tecnica del super thread smistando i thread di diversi processi su un singolo core per farli elaborare chiaramente non contemporaneamente (nell'articolo di arstecnica sarebbe la prima figura in cui processo thread rosso, poi quello giallo, poi rosso, poi 2 gialli, poi 2 rossi e così via).

Almeno io ho interpreto così però non so se nelle nuove implementazioni del SMT (da neahlem in poi) il core logico oltre processare il thread B dello stesso processo del thread A può anche infilare un thread C di un secondo processo. Qua ho io il dubbio;)

La risposta breve e`: si`. Se le pipeline sono riempite da un task il beneficio dell'hyperthreading e` nullo.
Se le pipeleine sono tutte piene hai gia` estratto il massimo possibile di ILP.

Da quel che mi sembra di aver capito, il secondo core logico puo` elaborare un secondo thread indipendentemente dal fatto che sia o meno generato dallo stesso processo.

[epimerasi]

Ma il problema è che io affermo che 4 core ht possono eseguire 4 processi ed 8 th al massimo contemporaneamente, mentre di contro mi si dice che possono essere eseguiti 8 processi indipendenti simultaneamente.
Bene in questo momento ho 22 processi attivi e 38 th in esecuzione contemporanea, che cpu ho?

Quello che vedi "contemporaneo" nell'OS (immagino ti stia riferendo a windows e al task manager) non c;entra niente con quello che viene fatto EFFETTIVAMENTE CONTEMPORANEAMENTE nella CPU

[Mister D]

Stai confondendo il multiprocessing/threading con il multitasking, ma sono cose indipendenti.
https://it.wikipedia.org/wiki/Multitasking

Da decenni i sistemi operativi eseguono piu` processi contemporaneamente, ma in macchine che non siano multicore (a prescindere che i core siano fisici o logici) e` una "illusione", i processi vengono sempre eseguiti uno alla volta.

Ok ma il multithreading di cui parlo io è una tecnica di multitasking (passatemi questa approssimazione) ma che invece di essere fatta a livello di processi viene fatto a livello di thread in cui vengono scomposti i vari processi.
Quindi non è che le sto confondendo è che se il multistasking come dice wiki, sia in inglese che in italiano, permette di eseguire più processi contemporaneamente, il super-threading o multithreading consente di eseguire più thread dello stesso processo ma non conmporaneamente come fa la sua evoluzione, cioè il SMT.
Per quanto riguarda l'illusione sì sono d'accordo ma il mio athlon single core per eseguire più processi "contemporaneamente" (l'ho messo tra virgolette perché non è proprio contemporanei) perché l'OS è multitasking, divide i vari processi in più di un thread e fa eseguire con quella tecnica di super-threading.

Ripeto io lo interpreto così e mi sembra che giri tutto. O no?

[tuttodigitale]

Sì ma lì spiega che dalla parte del sistema operativo è trasparente l'adozione del SMT o HT.
se lo è per il sistema operativo a maggior ragione lo è per la cpu.

poi ci pensano le unità del processore a dividere bene i compiti allocando al core fisico + core ht diversi processi.
Tu presupponi una struttura asimmetrica che non esiste. E se esistesse, lo scheduler dovrebbe esserne consapevole. Certo se si dimostra che i componenti allocati staticamente penalizzano il secondo thread, cambio idea.
non c'è un thread preferenziale per Nehalem, non ha alcun senso parlare di core logico o fisico, l'importante è caricare in modo uguale i core (e qui entra in ballo lo scheduler che deve essere HT consapevole)


Dalla prospettiva della microarchitettura, ciò significa che le istruzioni dei processori logici persisteranno ed verranno eseguite simultaneamente all'interno delle risorse di esecuzione condivise.
Come hai spiegato sopra, il secondo thread alimenterebbe la pipeline solo con lo stallo del primo thread: questo è un multithreading temporale (vedi cpu Barrel) non simultaneo.

un dual core, ha il doppio delle risorse di esecuzione. Sarà per quello. Gli stalli sono relativamente rari, una miss prediction avviene circa nel 2% del tempo. Certamente troppo poco per perdere il 50% di prestazioni di una soluzione dual core.



Il fatto che un single core possa processare più processi contemporaneamente è uno perché i processori super scalari hanno più pipeline all'interno di un core integer e due perché usano la tecnica del multihread temporale:
https://en.wikipedia.org/wiki/Super-threading

temporale, sta per "istanti diversi", quindi un single core non elabora più processi contemporaneamente. E' una contraddizione in termini.
Il fatto che le cpu siano super-scalare non c'entra niente

[Mister D]

La dipendenza dei dati di un thread da un altro thread e` stabilita a livello di programmazione, non di esecuzione.
Se avviene una cosa del genere, deve essere bravo il programmatore ad ottimizzare il programma affinche` i thread dipendenti non passino troppo tempo ad aspettare (a volte e` possibile e a volte no)



Le risorse duplicate, a quanto capisco, servono proprio per effettuare velocemente il context switch. Cioe` passare dall'esecuzione di un thread, all'esecuzione di un altro.
La CPU non puo` sapere a priori se i dati necessari all'esecuzione del secondo thread dipendono dal primo, questo sta all'ottimizzazione del programmatore.

Proprio a questo proposito, uno scenario in cui il secondo thread appartiene adun processo indipendente dal primo sarebbe piu` favorevole all'hyperthreading perche` e` meno probabile che dipenda dai dati del primo thread (anche se non e` detto, ripeto, dipende tutto dal modello di programmazione con cui e` stato scritto il programma).




Coem ti dicevo prima, la dipendenza dei dati di un task da un altro puo` accadere sia fra thread che fra processi, dipende tutto da come e` stato scritto il programma.
Se il secondo thread dipende dal primo che non ha finito, deve aspettare, sempre.
Questo vale anche per i processi.



La risposta breve e`: si`. Se le pipeline sono riempite da un task il beneficio dell'hyperthreading e` nullo.
Se le pipeleine sono tutte piene hai gia` estratto il massimo possibile di ILP.

Da quel che mi sembra di aver capito, il secondo core logico puo` elaborare un secondo thread indipendentemente dal fatto che sia o meno generato dallo stesso processo.

Ok anche così fila il discorso ma come può il secondo core logico, che condivide le risorse di esecuzione con il core fisico, elaborare un thread appartenente ad un secondo processo non ancora caricato nelle risorse di esecuzione? Non so se mi spiego bene. Vedendo il primo documento di intel che ho postato sembra che il thread B non deve avere relazione di dipendenza con il thread A pena non far funzionare l'HT ma deve appartenere allo stesso processo perché i dati del processo sono già stati caricati e divisi in vari thread (possono essere più di due).
A questo punto se ho un processo cui le unità logiche del core fisico divide in TH_A, TH_B e TH_C e il thread A stalla e io voglio caricare nel core logico un thread diverso (TH_A1 di un secondo processo) non devo svuotare tutti i registri e perdere per es il risultato che si sarebbe ottenuto dall'elaborazione del TH_A passato lo stallo (e dopo l'esecuzione di TH-B sul core logico)?
Cioè l'unità di esecuzione è UNA per core e le risorse attorno vengono solo duplicate per permettere di far eseguire il secondo thread quando il primo non va avanti.

Se riesci a rispondere a questo mi hai convinto del tutto:D Si fa per dire, nel senso che sto solo cercando di capire come può essere quello che supponi te anche perché allora perché l'HT non da lo stesso vantaggio di un vero secondo core fisico?

[Mister D]

se lo è per il sistema operativo a maggior ragione lo è per la cpu.


Tu presupponi una struttura asimmetrica che non esiste. E se esistesse, lo scheduler dovrebbe esserne consapevole. Certo se si dimostra che i componenti allocati staticamente penalizzano il secondo thread, cambio idea.
non c'è un thread preferenziale per Nehalem, non ha alcun senso parlare di core logico o fisico, l'importante è caricare in modo uguale i core (e qui entra in ballo lo scheduler che deve essere HT consapevole)


Come hai spiegato sopra, il secondo thread alimenterebbe la pipeline solo con lo stallo del primo thread: questo è un multithreading temporale (vedi cpu Barrel) non simultaneo.

un dual core, ha il doppio delle risorse di esecuzione. Sarà per quello. Gli stalli sono relativamente rari, una miss prediction avviene circa nel 2% del tempo. Certamente troppo poco per perdere il 50% di prestazioni di una soluzione dual core.




temporale, sta per "istanti diversi", quindi un single core non elabora più processi contemporaneamente. E' una contraddizione in termini.
Il fatto che le cpu siano super-scalare non c'entra niente

Scusa se non uso il multiquote ma faccio prima con il grassetto.
Per la prima parte leggi questo articolo di arstecnica e vedrai che il multithreading temporale non è il HT di intel. L'HT di intel (o più in generale un SMT a 2 vie) è un multithreading temporale ma simultaneo.
http://arstechnica.com/features/2002/10/hyperthreading/3/
Questo però non c'entra con il fatto che possa eseguire un thread di un altro processo non caricato nel percorso logico condiviso delle risorse di esecuzione. Vedi post sopra che ho appena scritto.

Per la seconda parte il time-slice multithreading o superthreading esegue più thread non in contemporanea su un singolo core non più processi. Ho sbagliato a scrivere effettivametne;)

[tuttodigitale]

in realtà l'avevo solo dimenticato che l'incremento dell'HT è dovuto principalmente dal codice scritto, a prescindere dall'architettura...
:O


ma allora dove sta il lavoro degli ingegneri nel rendere l'architettura più performante?
sono tutti qua su Hwupgrade. :cool:


rendere l'HT il più efficiente possibile anche in situazioni di codice scritto mediamente bene o male?
il codice è sempre scritto male


esempi, numeri ipotizzati per rendere l'idea:
codice 1: scritto perfettamente, stalli prossimi allo 0, HT inutilizzato
codice 2: scritto bene, stalli prossimi al 15%, HT utile al 15%
codice 3: scritto discretamente, stalli prossimi al 30%, HT utile al 30%
codice 4: scritto mediamente, stalli prossimi al 40%, HT utile al 30% (limite dell'architettura)
codice 5: scritto male, stalli prossimi al 50%, HT utile sempre al 30% (limite dell'architettura)

fai parte della famiglia



l'architettura di Intel al massimo dello sfruttamento dell'HT sappiamo che rende il +30%, ma in sostanza rende come se il codice fosse scritto perfettamente cioè sfrutta il Core; quello che mi chiedo è quando gli stalli superano la percentuale di sfruttamento dell'HT ed in questo caso avremo un risultato finale inferiore al teorico a causa del codice, ma anche a causa del limite della tecnologia HT.
Non ci ho capito molt, ma deve essere giusto, perchè:


Io dico, e qua do una mano a Dirk Meyer,

[epimerasi]

Ok ma il multithreading di cui parlo io è una tecnica di multitasking (passatemi questa approssimazione) ma che invece di essere fatta a livello di processi viene fatto a livello di thread in cui vengono scomposti i vari processi.
Quindi non è che le sto confondendo è che se il multistasking come dice wiki, sia in inglese che in italiano, permette di eseguire più processi contemporaneamente, il super-threading o multithreading consente di eseguire più thread dello stesso processo ma non conmporaneamente come fa la sua evoluzione, cioè il SMT.
Per quanto riguarda l'illusione sì sono d'accordo ma il mio athlon single core per eseguire più processi "contemporaneamente" (l'ho messo tra virgolette perché non è proprio contemporanei) perché l'OS è multitasking, divide i vari processi in più di un thread e fa eseguire con quella tecnica di super-threading.

Ripeto io lo interpreto così e mi sembra che giri tutto. O no?

Ci sono diverse cose inesatte.

La prima cosa e` che l'OS non divide nulla, al massimo smista (tramite lo scheduler).
E` il programmatore che decide in quanti processi e/o in quanti thread deve essere diviso il programma e utilizza gli strumenti messi a disposizione dall'OS e dal linguaggio di programmazione (fork, semafori e quant'altro) per gestirli.

Secondo: multithreading e` un termine molto generale, di cui il superthreading e` solo un tipo. L'hyperthreading NON e` un tipo di superthreading, l'hyperthreading e` un implementazione del concetto di Simultaneuous Multithreading che e` diverso.
Lo dice anche l'articolo di wikipedia:
"Super-threading (or time-slice multithreading) is a type of multithreading that enables different threads to be executed by a single processor without truly executing them at the same time.

This qualifies it as time-sliced or temporal multithreading rather than simultaneous multithreading (SMT)

While this approach enables better use of the processor's resources, further improvements to resource utilization can be realized through SMT, which allows the execution of instructions from multiple threads at the same time."

Terzo, rileggi bene l'articolo di wikipedia sul multitasking. Non dice che serve a far andare piu` processi contemporaneamente, ma piu` PROGRAMMI contemporaneamente.
Questo grazie all'illusione che vengano eseguiti contemporaneamente dal processore, ma non e` affatto detto che sia cosi`.
(anche perche` se un processore ha 4 core, logici o fisici che siano, piu` di 4 cose contemporaneamente non puo` oggetivamente fare).
Se apro 3 browser diversi, 2 lettori video, 1 lettore musicale e 1 gioco non troppo pesante contemporanemente su un 4 core sembra che vadano insieme, ma di fatto non e` cosi` perche` piu` di 4 task contemporaneamente non puo` fare. L'illusione e` data dal fatto che il processore salta velocissimamente da un task all'altro. Questo e` il multitasking.

[epimerasi]

Scusa se non uso il multiquote ma faccio prima con il grassetto.
Per la prima parte leggi questo articolo di arstecnica e vedrai che il multithreading temporale non è il HT di intel. L'HT di intel (o più in generale un SMT a 2 vie) è un multithreading temporale ma simultaneo.
http://arstechnica.com/features/2002/10/hyperthreading/3/
Questo però non c'entra con il fatto che possa eseguire un thread di un altro processo non caricato nel percorso logico condiviso delle risorse di esecuzione. Vedi post sopra che ho appena scritto.

Per la seconda parte il time-slice multithreading o superthreading esegue più thread non in contemporanea su un singolo core non più processi. Ho sbagliato a scrivere effettivametne;)

Ti copio semplicemente una frase dallo stesso articolo di ars technica:

"Simultaneous multithreading (SMT), a.k.a. hyper-threading, takes superthreading to the next level. Hyper-threading is simply superthreading without the restriction that all the instructions issued by the front end on each clock be from the same thread."

Nell'articolo di ars-techcnica fa il confronto fra un superthreading in cui il front-end contiente dati da thread multipli, ma le unita` di esecuzione eseguono i dati di un thread per volta

http://arstechnica.com/paedia/images/superthread-single_cpu-thum.png
[ guarda l'immagine, dall'alto verso il basso le unita` di esecuzione hanno colo colore rosso o giallo uno per volta, ogni riga e` una unita` temporale]

e l'hyper threading, in cui anche le unita` di esecuzione possono accedere a thread multipli

http://arstechnica.com/paedia/images/hyperthread-single_cpu-thum.png
[guarda l'immagine sucessiva, dall'alto verso il basso le unita` di esecuzione possono essere gialle o rosse nella stessa unita` temporale (riga)]

[Mister D]

Ci sono diverse cose inesatte.

La prima cosa e` che l'OS non divide nulla, al massimo smista (tramite lo scheduler).
E` il programmatore che decide in quanti processi e/o in quanti thread deve essere diviso il programma e utilizza gli strumenti messi a disposizione dall'OS e dal linguaggio di programmazione (fork, semafori e quant'altro) per gestirli.

Secondo: multithreading e` un termine molto generale, di cui il superthreading e` solo un tipo. L'hyperthreading NON e` un tipo di superthreading, l'hyperthreading e` un implementazione del concetto di Simultaneuous Multithreading che e` diverso.
Lo dice anche l'articolo di wikipedia:
"Super-threading (or time-slice multithreading) is a type of multithreading that enables different threads to be executed by a single processor without truly executing them at the same time.

This qualifies it as time-sliced or temporal multithreading rather than simultaneous multithreading (SMT)

While this approach enables better use of the processor's resources, further improvements to resource utilization can be realized through SMT, which allows the execution of instructions from multiple threads at the same time."

Terzo, rileggi bene l'articolo di wikipedia sul multitasking. Non dice che serve a far andare piu` processi contemporaneamente, ma piu` PROGRAMMI contemporaneamente.
Questo grazie all'illusione che vengano eseguiti contemporaneamente dal processore, ma non e` affatto detto che sia cosi`.
(anche perche` se un processore ha 4 core, logici o fisici che siano, piu` di 4 cose contemporaneamente non puo` oggetivamente fare).
Se apro 3 browser diversi, 2 lettori video, 1 lettore musicale e 1 gioco non troppo pesante contemporanemente su un 4 core sembra che vadano insieme, ma di fatto non e` cosi` perche` piu` di 4 task contemporaneamente non puo` fare. L'illusione e` data dal fatto che il processore salta velocissimamente da un task all'altro. Questo e` il multitasking.

Ok io ho preso per buono quanto scritto da arstechica che definisce il SMT semplicemente come un multithreading ma simultaneo.
Secondo in wiki inglese multitask è definito come la capacità di eseguire più task (conosciuti anche come processi). Word è un programma ma per eseguirlo il processo è word.exe o no? Allora processo e programma può essere considerato la stessa cosa nel caso il programma giri su un solo processo. Purtroppo in italiano i termini sono meno precisi che in inglese:D

Cmq posso stopparvi tutti perché rileggendo effettivamente i vari documenti non viene esplicitato che il secondo core logico non possa processare thread di altri processi e rileggendo bene artecnica e questa pagina di wiki in inglese:
https://en.wikipedia.org/wiki/Multithreading_(computer_architecture)
Il multithreading non può processare thread che non appartengano allo stesso processo (e per questo fa prima uno o poi l'altro e da questo penso venga il termina time-slice) mentre il SMT (e da questo viene la S di simultaneo) può processare thread di diversi processi solo quando stalla il thread precedente.
Ero convinto che anche il SMT (aka HT) avesse quel problema e invece no. Scusatemi:D Avevate ragione voi!:sofico:

[Piedone1113]

Quello che vedi "contemporaneo" nell'OS (immagino ti stia riferendo a windows e al task manager) non c;entra niente con quello che viene fatto EFFETTIVAMENTE CONTEMPORANEAMENTE nella CPU

Questo è chiarissimo, ma se nel core logico 0 gira un PID 10 con 100% dell'uso delle Pipeline e al core 1 viene assegnato un processo (non un TH) con PID 100 cosa succede il secondo processo non viene eseguito?
Forse il computer non emette più Audio?
Non aggiorna la schermata di word?
Come gia detto prima se viene assegnato un processo diverso al core virtuale questo fa decadere le prestazioni in modo vertiginoso se lo si vuole eseguire in contemporanea con un altro processo, mentre se si parla di th questi possono accellerare o meno l'esecuzione ma non farla stallare, ti risulta che con SMT ci sono casi di freeze del sistema (assegnare due processi allo stesso core porta questi risultati).
Un secondo processo da eseguire ha bisogno di tempo cpu dedicato, o di contendere risorse all'altro processo?
Che possano essere inviati più processi allo stesso core reale è lampante, ma che questi possono essere eseguiti simultaneamente ancora non è stato definito (e lo studio di Ibm postato prima indica che il 22% di maggior velocità nei processi è dovuto al 32% di maggior velocità nell'esecuzione del singolo processo parallelizzando in ht, e non alla capacità di eseguire contemporaneamente più processi sullo stesso core che difatti rallenterebbero il sistema.

[tuttodigitale]

Ok anche così fila il discorso ma come può il secondo core logico, che condivide le risorse di esecuzione con il core fisico, elaborare un thread appartenente ad un secondo processo non ancora caricato nelle risorse di esecuzione?
esattamente come fa con il primo thread...solo il DTLB e la cache, e ovviamente le unità esecutive sono condivise dinamicamente tra i due thread. Le altre risorse del front-end, o sono duplicate o partizionate staticamente.

. Vedendo il primo documento di intel che ho postato sembra che il thread B non deve avere relazione di dipendenza con il thread A pena non far funzionare l'HT ma deve appartenere allo stesso processo perché i dati del processo sono già stati caricati e divisi in vari thread (possono essere più di due).
I thread, sulla carta, più indipendenti di quelli appartenenti a processi diversi quali sono? :D

one del TH_A passato lo stallo (e dopo l'esecuzione di TH-B sul core logico)?
Cioè l'unità di esecuzione è UNA per core e le risorse attorno vengono solo duplicate per permettere di far eseguire il secondo thread quando il primo non va avanti.
Le ultime cpu Intel hanno 4 pipeline int per singolo core.

Devi sapere che nelle cpu superscalari, la cpu esamina il singolo thread, e attraverso tutta una serie di algoritmi implementati via HW, cerca di esaminare quali istruzioni, all'interno del singolo thread possono essere eseguite contemporaneamente, addirittura manipolando anche l'ordine di esecuzione (OoO). Tuttavia nonostante tutta una serie di tecniche, ci sono casi in cui l'esecuzione dell'istruzione successiva dipende dal risultato di una esecuzione precedente.
In questo caso solo una delle 4 pipeline sono utilizzabili, vengono di fatti sprecate il 75% delle pipeline integer..

ed ecco che viene in aiuto HT
http://sc.tamu.edu/Images/NehalemSMT.png
Notare che secondo la slide di Intel, il thread 1 è penalizzato dalla concorrenza del thread2, ma le prestazioni complessive aumentano

[epimerasi]

Ok io ho preso per buono quanto scritto da arstechica che definisce il SMT semplicemente come un multithreading ma simultaneo.
Secondo in wiki inglese multitask è definito come la capacità di eseguire più task (conosciuti anche come processi). Word è un programma ma per eseguirlo il processo è word.exe o no? Allora processo e programma può essere considerato la stessa cosa nel caso il programma giri su un solo processo. Purtroppo in italiano i termini sono meno precisi che in inglese:D

Cmq posso stopparvi tutti perché rileggendo effettivamente i vari documenti non viene esplicitato che il secondo core logico non possa processare thread di altri processi e rileggendo bene artecnica e questa pagina di wiki in inglese:
https://en.wikipedia.org/wiki/Multithreading_(computer_architecture)
Il multithreading non può processare thread che non appartengano allo stesso processo (e per questo fa prima uno o poi l'altro e da questo penso venga il termina time-slice) mentre il SMT (e da questo viene la S di simultaneo) può processare thread di diversi processi solo quando stalla il thread precedente.
Ero convinto che anche il SMT (aka HT) avesse quel problema e invece no. Scusatemi:D Avevate ragione voi!:sofico:

Una sola precisazione: programma e` un termine molto piu` generico di processo.
Una cosa che vedi come un programma puo` benissimo essere fatta da piu` processi.

[Piedone1113]

Ok io ho preso per buono quanto scritto da arstechica che definisce il SMT semplicemente come un multithreading ma simultaneo.
Secondo in wiki inglese multitask è definito come la capacità di eseguire più task (conosciuti anche come processi). Word è un programma ma per eseguirlo il processo è word.exe o no? Allora processo e programma può essere considerato la stessa cosa nel caso il programma giri su un solo processo. Purtroppo in italiano i termini sono meno precisi che in inglese:D

Cmq posso stopparvi tutti perché rileggendo effettivamente i vari documenti non viene esplicitato che il secondo core logico non possa processare thread di altri processi e rileggendo bene artecnica e questa pagina di wiki in inglese:
https://en.wikipedia.org/wiki/Multithreading_(computer_architecture)
Il multithreading non può processare thread che non appartengano allo stesso processo (e per questo fa prima uno o poi l'altro e da questo penso venga il termina time-slice) mentre il SMT (e da questo viene la S di simultaneo) può processare thread di diversi processi solo quando stalla il thread precedente.
Ero convinto che anche il SMT (aka HT) avesse quel problema e invece no. Scusatemi:D Avevate ragione voi!:sofico:

Quindi due processi differenti non vengono eseguiti contemporaneamente.

[Mister D]

Ti copio semplicemente una frase dallo stesso articolo di ars technica:

"Simultaneous multithreading (SMT), a.k.a. hyper-threading, takes superthreading to the next level. Hyper-threading is simply superthreading without the restriction that all the instructions issued by the front end on each clock be from the same thread."

Nell'articolo di ars-techcnica fa il confronto fra un superthreading in cui il front-end contiente dati da thread multipli, ma le unita` di esecuzione eseguono i dati di un thread per volta

http://arstechnica.com/paedia/images/superthread-single_cpu-thum.png
[ guarda l'immagine, dall'alto verso il basso le unita` di esecuzione hanno colo colore rosso o giallo uno per volta, ogni riga e` una unita` temporale]

e l'hyper threading, in cui anche le unita` di esecuzione possono accedere a thread multipli

http://arstechnica.com/paedia/images/hyperthread-single_cpu-thum.png
[guarda l'immagine sucessiva, dall'alto verso il basso le unita` di esecuzione possono essere gialle o rosse nella stessa unita` temporale (riga)]

Vedi post precedente. Il mio errore è che pensavo che i quadrati rossi potevano essere solo istruzioni di un thread e che tutti quei thread (tutto il rosso e tutto il giallo) facessero per forza parte di un solo processo invece no. Il rosso è il processo con più o meno thread e il giallo un'altro. L'importante è che finalmente ho capito dove sbagliavo nell'interpretazione, per cui grazie;)

[epimerasi]

Questo è chiarissimo, ma se nel core logico 0 gira un PID 10 con 100% dell'uso delle Pipeline e al core 1 viene assegnato un processo (non un TH) con PID 100 cosa succede il secondo processo non viene eseguito?
Forse il computer non emette più Audio?
Non aggiorna la schermata di word?

Questo e` un problema dello scheduler del sistema operativo.
E cmq si`, se non riesce ad essere eseguito, aspetta.
La schermata di word non si aggiorna

Come gia detto prima se viene assegnato un processo diverso al core virtuale questo fa decadere le prestazioni in modo vertiginoso se lo si vuole eseguire in contemporanea con un altro processo, mentre se si parla di th questi possono accellerare o meno l'esecuzione ma non farla stallare, ti risulta che con SMT ci sono casi di freeze del sistema (assegnare due processi allo stesso core porta questi risultati).
Un secondo processo da eseguire ha bisogno di tempo cpu dedicato, o di contendere risorse all'altro processo?
Che possano essere inviati più processi allo stesso core reale è lampante, ma che questi possono essere eseguiti simultaneamente ancora non è stato definito (e lo studio di Ibm postato prima indica che il 22% di maggior velocità nei processi è dovuto al 32% di maggior velocità nell'esecuzione del singolo processo parallelizzando in ht, e non alla capacità di eseguire contemporaneamente più processi sullo stesso core che difatti rallenterebbero il sistema.

Porta questi risultati in base a cosa sta facendo quel processo.
Se sono 2 calcoli pesanti, ognuno capace di saturare le pipeline, ovvio che facciano bloccare tutto.

[epimerasi]

Quindi due processi differenti non vengono eseguiti contemporaneamente.

Possono farlo invece e non so che altro scrivere per convincerti sinceramente.

[epimerasi]

Vedi post precedente. Il mio errore è che pensavo che i quadrati rossi potevano essere solo istruzioni di un thread e che tutti quei thread (tutto il rosso e tutto il giallo) facessero per forza parte di un solo processo invece no. Il rosso è il processo con più o meno thread e il giallo un'altro. L'importante è che finalmente ho capito dove sbagliavo nell'interpretazione, per cui grazie;)

Prego

[Mister D]

Quindi due processi differenti non vengono eseguiti contemporaneamente.

No mi sbagliavo anche io. Nel caso di Super-Threading (o time-slice multithreading):
https://en.wikipedia.org/wiki/Super-threading
http://arstechnica.com/features/2002/10/hyperthreading/3/
NON può eseguire due processi in contemporanea ma li alterna, prima e poi l'altro mentre nel SMT (aka HT di intel):
https://en.wikipedia.org/wiki/Hyper-threading
il secondo core logico può processare in contemporanea ma solo quando stalla il primo thread anche thread di altri processi (e non solo thread di un solo processo come pensavo erroneamente io).
La differenza è che un vero dual core i thread di diversi processi le fa eseguire su core diversi e quindi non aspetta lo stallo del primo thread e lavora ancora più "contemporaneamente":D

[tuttodigitale]

Questo è chiarissimo, ma se nel core logico 0 gira un PID 10 con 100% dell'uso delle Pipeline e al core 1 viene assegnato un processo (non un TH) con PID 100 cosa succede il secondo processo non viene eseguito?
Forse il computer non emette più Audio?
Non aggiorna la schermata di word?

Entra in diretta competizione con il primo thread. Questo non toglie che una eventuale implementazione SMT possa essere asimmetrica, ma questo non è il caso di Nehalem, ma di Power8.
Proprio l'esempio che hai fatto (bravo) ti fa intuire che qualsiasi cambiamento nella gestione dei thread, lo scheduler deve essere consapevole dell'HW che sta sotto.

Non so se si è capito.
nel caso in cui il core è al 100% anche con un solo thread, virtualmente in HW non c'è nessun favoritismo di un thread rispetto all'altro. Nella slide sembrerebbe che un minimo di risorse sia comunque garantito, ma questo non è in fin dei conti un problema reale. Anche in un ipotetico caso di sfruttamento al 100% delle 4 pipeline ogni 100 cicli, 25ns, c'è un miss-prediction.

PS più si discute, più nascono dubbi e più ci si rende conto che il SMT non è banale come quel +5% lascia intendere

[epimerasi]

No mi sbagliavo anche io. Nel caso si Super-Threading (o time-slice multithreading):
https://en.wikipedia.org/wiki/Super-threading
http://arstechnica.com/features/2002/10/hyperthreading/3/
NON può eseguire due processi in contemporanea ma li alterna, prima e poi l'altro mentre nel SMT (aka HT di intel):
https://en.wikipedia.org/wiki/Hyper-threading
il secondo core logico può processare in contemporanea ma solo quando stalla il primo thread anche thread di altri processi (e non solo thread di un solo processo come pensavo erroneamente io).
La differenza è che un vero dual core i thread di diversi processi le fa eseguire su core diversi e quindi non aspetta lo stallo del primo thread e lavora ancora più "contemporaneamente":D

Ci stiamo riferende all'hyperthreading di Intel infatti

[Mister D]

esattamente come fa con il primo thread...solo il DTLB e la cache, e ovviamente le unità esecutive sono condivise dinamicamente tra i due thread. Le altre risorse del front-end, o sono duplicate o partizionate staticamente.


I thread, sulla carta, più indipendenti di quelli appartenenti a processi diversi quali sono? :D


Le ultime cpu Intel hanno 4 pipeline int per singolo core.

Devi sapere che nelle cpu superscalari, la cpu esamina il singolo thread, e attraverso tutta una serie di algoritmi implementati via HW, cerca di esaminare quali istruzioni, all'interno del singolo thread possono essere eseguite contemporaneamente, addirittura manipolando anche l'ordine di esecuzione (OoO). Tuttavia nonostante tutta una serie di tecniche, ci sono casi in cui l'esecuzione dell'istruzione successiva dipende dal risultato di una esecuzione precedente.
In questo caso solo una delle 4 pipeline sono utilizzabili, vengono di fatti sprecate il 75% delle pipeline integer..

ed ecco che viene in aiuto HT
http://sc.tamu.edu/Images/NehalemSMT.png
Notare che secondo la slide di Intel, il thread 1 è penalizzato dalla concorrenza del thread2, ma le prestazioni complessive aumentano

Grazie anche a te, ma epimerasi mi avevo già acceso la lampadina e rileggendo con più calma tutto ho visto dove il mio ragionamento era fallace:doh: . Cmq sì è proprio come dici te. Chiaramente l'esecuzione del secondo thread (che sia appartenente o no allo stesso processo) si può avere solo quando stalla il primo thread ed è per questo che il un core + SMT a 2 vie è meno contemporaneo di una cpu dual core. I core fisici processano contemporaneamente e indipendentemente i thread A e B.
Ci è voluto ragazzi ma ora mi è chiaro :sofico:

[Mister D]

Ci stiamo riferende all'hyperthreading di Intel infatti

Sì sì infatti esistono altri tipi di SMT che ora non ho voglia di conoscere ah ah ah:sofico:

[Mister D]

Detto tutto questo ma allora perché non realizzare un CMT + SMT? In fin dei conti si sarebbe più complesso ma si unirebbero i due punti di forza:
1. avere 2 core integer (o anche di più) che possono elaborare in contemporanea 2 thread,
2. avere per ogni core integer il SMT che aiuta quando le pipeline cui lo compongono stallano.

Non ci vedo niente di male, anzi sarebbe un architettura molto efficiente (se realizzata bene) o no?

E poi visto che il SMT, come quello di intel, trae vantaggio proprio in quelle occasioni di stallo è forse per questo che le ultime archit intel hanno più pipeline rispetto a quelle amd? Mi pare abbastanza evidente che più si aumenta il numero di pipeline a core più un SMT (anche con più di 2 vie) aiuta a riempirle quando stallano.

[Piedone1113]

Entra in diretta competizione con il primo thread. Questo non toglie che una eventuale implementazione SMT possa essere asimmetrica, ma questo non è il caso di Nehalem, ma di Power8.
Proprio l'esempio che hai fatto (bravo) ti fa intuire che qualsiasi cambiamento nella gestione dei thread, lo scheduler deve essere consapevole dell'HW che sta sotto.

Non so se si è capito.
nel caso in cui il core è al 100% anche con un solo thread, virtualmente in HW non c'è nessun favoritismo di un thread rispetto all'altro. Nella slide sembrerebbe che un minimo di risorse sia comunque garantito, ma questo non è in fin dei conti un problema reale. Anche in un ipotetico caso di sfruttamento al 100% delle 4 pipeline ogni 100 cicli, 25ns, c'è un miss-prediction.

PS più si discute, più nascono dubbi e più ci si rende conto che il SMT non è banale come quel +5% lascia intendere

Quindi in definitiva abbiamo:
un processo due th eseguiti simultaneamente
due processi si esegue il primo, in caso di stallo del primo si esegue il secondo processo nell'attesa che sia pronto il primo alla prosecuzione.
Quindi due processi sullo stesso core ma non eseguiti contemporaneamente.
Sbaglio in qualcosa?

[tuttodigitale]

E poi visto che il SMT, come quello di intel, trae vantaggio proprio in quelle occasioni di stallo è forse per questo che le ultime archit intel hanno più pipeline rispetto a quelle amd? Mi pare abbastanza evidente che più si aumenta il numero di pipeline a core più un SMT (anche con più di 2 vie) aiuta a riempirle quando stallano.
Esattamente

[epimerasi]

Quindi in definitiva abbiamo:
un processo due th eseguiti simultaneamente
due processi si esegue il primo, in caso di stallo del primo si esegue il secondo processo nell'attesa che sia pronto il primo alla prosecuzione.
Quindi due processi sullo stesso core ma non eseguiti contemporaneamente.
Sbaglio in qualcosa?

Sono eseguiti contemporaneamente ovvio che poi una unita` di esecuzione in un dato stage della pipeline non puo` fare 2 cose contemporaneamente, ma se ha un buco esegue allora l'istruzione del secondo thread.
I due thread pero` sono contemporanei.
La pipeline non deve essere svuotata e ricaricata.

[tuttodigitale]

Il secondo thread deve necessariamente attendere che il primo thread lasci qualche pipeline libera?
ora entriamo nel tecnico (fantasia)
Le probabilità che una nel ST cpu saturi le alu, sono rare. Ed è proprio per questo che esiste il SMT. In pratica quelle poche volte che la CPU è in grado di estrarre sufficiente ILP, può sfruttare le unità aggiuntive, a beneficio dell'ipc nel ST.
In quelle pochissime condizioni in cui il primo thread potrebbe saturare le pipeline, lo scheduler di Nehalem esegue comunque il secondo?
Scelte di questo tipo non si fanno su due piedi. Ma se proprio devo fare un azzardo direi che tutto dipende dal tipo di istruzione da eseguire. (sono uscito fuori con un dipende :sofico: ). Il secondo thread può abbattere le prestazioni del primo thread se garantisce prestazioni superiori (per esempio esecuzione di una MUL nel primo thread invece di una semplice SUM), poco importa se potenzialmente è in grado di saturare le unità esecutive.

[Piedone1113]

Sono eseguiti contemporaneamente ovvio che poi una unita` di esecuzione in un dato stage della pipeline non puo` fare 2 cose contemporaneamente, ma se ha un buco esegue allora l'istruzione del secondo thread.
I due thread pero` sono contemporanei.
La pipeline non deve essere svuotata e ricaricata.

Aspetta:
Se un Processo offre due th ed ogni singolo th usa al massimo 3 pipeline delle 4 disponibili il secondo th viene eseguito sulla pipeline libera.
Se ci sono due processi caricati sul core solo quando stalla il primo processo (cioè quando tutte le pipilene usate, che siano 1,2,3,4 devono essere svuotate e ricaricate tutte o in parte ) viene eseguito il secondo processo, nell'attesa che vengono ricaricati i dati giusti in cache.
Se una pipilene è condizionale ad un altro risultato e questo è in elaborazione su una seconda pipeline il task non è in stallo, ma in esecuzione, ed allora il secondo processo rimane in attesa.

In caso contrario non avrebbe senso dire che il secondo processo entra in esecuzione quando stalla il primo.

[tuttodigitale]

.
Quindi due processi sullo stesso core ma non eseguiti contemporaneamente.
Sbaglio in qualcosa?
sono eseguiti contemporaneamente, non nella stesso stadio di una determinata pipeline, ma in una pipeline adiacente, nel caso tutt'altro che raro che sia lasciata vuota (ma non solo) dal thread (in pratica il cluster int è coem se si dividesse in due, le proporzioni sono decise di volta in volta).

PS. Non c'è nessuna ragione per rilasciare il thread2 a favore del 1. Per lo scheduler sono la stessa cosa. Quello che conta sono le istruzioni.

[paolo.oliva2]

però nella pratica come fa a tenere in stallo il thread del primo processo se deve svuotare e ricaricare le cache per eseguire un thread di un altro processo?
Comunque sempre per tendere una mano a Paolo, oggi più che mai :D , le cache devono essere super veloci ed efficienti in un sistema SMT-HT così!
speriamo che tutti i brevetti di questi ultimi 3 anni sulle cache diano degli ottimi risultati, alla fine è il tendine d'Achille di AMD...

Sono più convinto che mai che AMD si sia buttata sul CMT perché era l'unico modo per aumentare le prestazioni senza dover realizzare cache veloci, rivedere la predizione e quant'altro... Cioè, ha di fatto puntato ad eseguire 2 TH contemporaneamente per compensare l'IPC e le cache Intel.
Ora... Fare cache veloci migliorare la predizione e inserire l'SMT e tenere il CMT su un silicio sconosciuto.... Praticamente fare quello che ha fatto Intel in 15 anni + il CMT, una paglia.almeno poteva fare un power8 sul 22nm SOI depotenziato per desktop e nei 125W...

[Piedone1113]

sono eseguiti contemporaneamente, non nella stesso stadio di una determinata pipeline, ma in una pipeline adiacente, nel caso tutt'altro che raro che sia lasciata vuota (ma non solo) dal thread (in pratica il cluster int è coem se si dividesse in due, le proporzioni sono decise di volta in volta).

PS. Non c'è nessuna ragione per rilasciare il thread2 a favore del 1. Per lo scheduler sono la stessa cosa. Quello che conta sono le istruzioni.

Quello che mi lascia perplesso:
La cache L1 deve contenere i TH di entrambi i processi aumentando esponenzialmente i cache miss su entrambi.
L'ingresso nella pipeline può essere gestita dal PID del processo, ma in ogni caso capiterà che un ingresso di dati in pipeline possa rallentare l'esecuzione del primo processo portandolo in stallo e rallentandolo ulteriormente.
Onestamente mi sembra troppo semplicistica questa spiegazione e non trovo riscontro nel poter gestire adeguatamente due processi differenti con una L1 di siffatta dimensione.

[tuttodigitale]

...
Troppo semplicistica? E cosa pretendevi da me :D
Comunque non guardare solo le dimensioni (in fin dei conti non dissimile da BD), ma anche l'associatività e la velocità. E non ultimo in caso di miss, c'è sempre una velocissima cache l2.

comunque non ho capito come possa mandare in stallo un thread una istruzione che deve ancora entrare nella pipeline, visto che si presuppone che gli operandi siano tutti presenti nei registri della cpu (il cache miss a limite riguarderanno le istruzioni successive).

Se invece ti riferisci al fatto che il primo thread rallenti, conta poco, credimi. Alla fine l'importante che la cpu esegua i calcoli più velocemente possibile.

[Piedone1113]

Troppo semplicistica? E cosa pretendevi da me :D
Comunque non guardare solo le dimensioni (in fin dei conti non dissimile da BD), ma anche l'associatività e la velocità. E non ultimo in caso di miss, c'è sempre una velocissima cache l2.

comunque non ho capito come possa mandare in stallo un thread una istruzione che deve ancora entrare nella pipeline, visto che si presuppone che gli operandi siano tutti presenti nei registri della cpu (il cache miss a limite riguarderanno le istruzioni successive).

Se invece ti riferisci al fatto che il primo thread rallenti, conta poco, credimi. Alla fine l'importante che la cpu esegua i calcoli più velocemente possibile.

Non soltanto rallenta, ma manda in stallo il processo:

A come ho capito dai grafici, i dati in pipeline vengono infilati alla rinfusa (non propriamente così, ma ogni pipeline contiene al suo interno nei vari stadi sia istruzioni del processo A che di quello B.)
Bene se il processo A nella pipeline 1 aspetta i dati di un'operazione presente nella Pipeline 2 e il processo B in pipeline 2 aspetta i dati da un'operazione presente nella Pipeline 1 ed entrambe le istruzione sono bloccate nel Passaggio di stadio dalle dipendenze rispettive in attesa cosa succede?
Vengono svuotate le pipeline e si riprende d'accapo tutto, si continua ad aspettare un dato facendolo elaborare nella pipeline 3 svuotandola e dichiarando orfano un ramo?
Onestamente non mi ci vedo tutta questa improvvisazione e lasciare al caso questi possibili conflitti.

[Grizlod®]

Non soltanto rallenta, ma manda in stallo il processo:

A come ho capito dai grafici, i dati in pipeline vengono infilati alla rinfusa (non propriamente così, ma ogni pipeline contiene al suo interno nei vari stadi sia istruzioni del processo A che di quello B.)
Bene se il processo A nella pipeline 1 aspetta i dati di un'operazione presente nella Pipeline 2 e il processo B in pipeline 2 aspetta i dati da un'operazione presente nella Pipeline 1 ed entrambe le istruzione sono bloccate nel Passaggio di stadio dalle dipendenze rispettive in attesa cosa succede?
Vengono svuotate le pipeline e si riprende d'accapo tutto, si continua ad aspettare un dato facendolo elaborare nella pipeline 3 svuotandola e dichiarando orfano un ramo?
Onestamente non mi ci vedo tutta questa improvvisazione e lasciare al caso questi possibili conflitti.
Non credo che la logica del processore possa cercare/prelevare dati da/nelle pipelines, bensì nei vari livelli delle caches (ovviamente da la priorità alla velocissima, seppur minuta L1) se non lo trovasse potrebbe prelevarlo direttamenta dalla lenta RAM di sistema.
Vado a memoria, ma credo che una pipeline si svuoti in caso di operazione errata, cioè se un dato nello stadio x che considerato corretto, in realtà poi non lo sia. Oppure se già stata risolta da un'altra pipeline coinvolta nella stessa operazione. Ciò implica anche un'efficiente branch prediction unit.

[tuttodigitale]

Se una pipilene è condizionale ad un altro risultato e questo è in elaborazione su una seconda pipeline il task non è in stallo, ma in esecuzione, ed allora il secondo processo rimane in attesa.

In caso contrario non avrebbe senso dire che il secondo processo entra in esecuzione quando stalla il primo.
Permetti di dubitare.... :D
in una moderna cpu la pipeline (una per semplicità) ha circa 20 stadi. Questo significa che occorrono circa 20 colpi di clock a percorrere la pipeline.
1) se alimenti la pipeline con il secondo thread solo quando tutte le pipeline hanno stallato (miss-prediction) siamo freschi. Siamo praticamente il punto d'accapo. Dobbiamo aspettare una 20ina di cicli prima che la cpu finisca di eseguire la prima istruzione successiva, indipendentemente dal thread. Tanto vale eseguire una nuova istruzione del thread1.
Il SMT sarebbe a dir poco inutile.

2) usare i tempi morti delle pipeline lasciate dal primo thread per l'esecuzione del thread2.
In questo modo si aumenta il throughput.


3) La presenza costante di un secondo thread, riduce e di molto il problema degli stalli (le pipeline sono comunque alimentate in parte dal secondo thread). Ecco perchè penalizzare le prestazioni di un thread non è una cattiva idea. Uno stallo costa la metà.

Non credo che la logica del processore possa cercare/prelevare dati da/nelle pipelines, bensì nei vari livelli delle caches (ovviamente da la priorità alla velocissima, seppur minuta L1) se non lo trovasse potrebbe prelevarlo direttamenta dalla lenta RAM di sistema.
le cpu devono caricare i dati nei registri. Le cache sono troppo lente.

PS ovviamente prendete con le pinze quello che ho scritto.

[Grizlod®]

le cpu devono caricare i dati nei registri. Le cache sono troppo lente.

PS ovviamente prendete con le pinze quello che ho scritto.Servirebbe una CPU 'magica' per eliminare le caches :D Purtroppo, mi sa che serviranno cache di III° livello sempre più di grandi dimensioni.

[mtk]

phiga....mi state mandando a massa con tutti sti dati....spero solo che per ipc o per frequenza moltiplicato per ipc,il prossimo procione sia ragionevole rispetto a intel......altrimenti se mi costa un rene resto con sti bidoni di fx pile :asd:

[george_p]

phiga....mi state mandando a massa con tutti sti dati....spero solo che per ipc o per frequenza moltiplicato per ipc,il prossimo procione sia ragionevole rispetto a intel......altrimenti se mi costa un rene resto con sti bidoni di fx pile :asd:

Se non altro da qui all'uscita di Zen ci facciamo tutti una bella cultura sul funzionamento dei processori :read: ... Dopo Zen ne progettiamo uno noi :sofico:

[mtk]

Se non altro da qui all'uscita di Zen ci facciamo tutti una bella cultura sul funzionamento dei processori :read: ... Dopo Zen ne progettiamo uno noi :sofico:

:D

[el-mejo]

Che Zen cominci a mettere pepe al culo ad Intel?:sofico:

http://www.tomshw.it/news/i-processori-intel-cannonlake-a-10-nanometri-avranno-fino-a-8-core-70602

[epimerasi]

Quello che mi lascia perplesso:
La cache L1 deve contenere i TH di entrambi i processi aumentando esponenzialmente i cache miss su entrambi.
L'ingresso nella pipeline può essere gestita dal PID del processo, ma in ogni caso capiterà che un ingresso di dati in pipeline possa rallentare l'esecuzione del primo processo portandolo in stallo e rallentandolo ulteriormente.
Onestamente mi sembra troppo semplicistica questa spiegazione e non trovo riscontro nel poter gestire adeguatamente due processi differenti con una L1 di siffatta dimensione.

Il front-end di ogni core gestisce entrambi i thread contemporaneamente, e` proprio li` che nasce il concetto di cpu multithread.

E` quello che faceva anche Bulldozer prima che ri-raddoppiassero il front-end nel modulo.

[batou83]

Che Zen cominci a mettere pepe al culo ad Intel?:sofico:

http://www.tomshw.it/news/i-processori-intel-cannonlake-a-10-nanometri-avranno-fino-a-8-core-70602

La speranza è di toglierci finalmente dai piedi i dual core e pagare al loro stesso prezzo i quad core :)

[tuttodigitale]

Il front-end di ogni core gestisce entrambi i thread contemporaneamente, e` proprio li` che nasce il concetto di cpu multithread.

E` quello che faceva anche Bulldozer prima che ri-raddoppiassero il front-end nel modulo.
inoltre le cpu odierne sono in grado di prelevare, mettere in coda molte più istruzioni di quanto possono essere effettivamente elaborare le ALU.

Servirebbe una CPU 'magica' per eliminare le caches :D Purtroppo, mi sa che serviranno cache di III° livello sempre più di grandi dimensioni.
E' più probabile che venga aggiunto un ulteriore livello di cache

[Grizlod®]

E' più probabile che venga aggiunto un ulteriore livello di cache
Sulla mainboard ?! Un ritorno al K6 III :eek: , oppure on package, ma quanto gli/ci costerà :rolleyes:

[davo30]

Che Zen cominci a mettere pepe al culo ad Intel?:sofico:

http://www.tomshw.it/news/i-processori-intel-cannonlake-a-10-nanometri-avranno-fino-a-8-core-70602

E' piu probabile che Intel si sia resa conto che i pochi miglioramenti da Sandy ad oggi hanno creato una sorta di auto-concorrenza (chi ha un Ivy puo saltare tranquillamente anche Skylake), e quindi si decida lei stessa a smuovere un po le acque, aumentando il numero di core di ciascuna fascia (fascia schifo (celeron) 2 core, fascia bassa (pentium) 4, fascia media (i5) 4+ht, fascia alta (i7) 8, fascia extreme (i7-e) 8+8, 16 ecc.)

Per il resto complimenti a tutti, siete davvero preparati, io piu che trollare ogni tanto e commentare piu su un lato "economico" e tifoso non mi posso spingere