[Thread Ufficiale] Aspettando ZEN

[plainsong]

Originariamente inviato da Free Gordon

Può essere che in AMD quando crearono BD, pensarano principalmente alla sua integrazione con Fusion e quindi "risparmiarono" potenza in virgola mobile, sperando di delegarla alla futura GPU integrata..?

Questa è una ben nota leggenda metropolitana della cui veridicità dubito fortemente, a meno che in AMD non avessero a suo tempo del tutto cannato le loro previsioni. Siamo ancora molto lontani dalla possibilità di abolire convenientemente l'unità fp, figuriamoci ai tempi della progettazione dell'architettura BD.

[paolo.oliva2]

Io penso che l'interpretazione reale di fatto non esista per considerare un core come entità che racchiude INT + FP, quindi il nocciolo della questione è che un BD X8 è un X8 e non un X4 perché ha 4 FP (condivise}.
Per me il metro plausibile sarebbe quello prestazkonale, perché per assurdo, fantasticando, si potrebbe avere una quantità di core senza FP da una parte e dall'altra soluzioni per elaborare dati in FP. Basta confrontare la capacità prestazionale per avere un metro di misura, anche perché alla fine bisognerebbe vedere anche il costo, perché noi valutiamo la potenza ST e MT, ma ad esempio quella MT non dipende dalla potenza del core ma anche dal numero dei core, se la ditta X offre soluzioni che per stessa potenza offre un numero maggiore di core ma allo stesso prezzo, che importa a me se la ditta Y ha un core più potente?

[stefanonweb]

Scusate si sa almeno se le mobo AM4 avranno un connettore di alimentazione NORMALE a 24 pin... tanto per capire se il pico ali andrà ancora bene o no... Grazie.

[capitan_crasy]

Originariamente inviato da Free Gordon

Può essere che in AMD quando crearono BD, pensarano principalmente alla sua integrazione con Fusion e quindi "risparmiarono" potenza in virgola mobile, sperando di delegarla alla futura GPU integrata..?

Io ho sempre pensato così..

Peccato che le APU/HSA non abbian ancora preso piede adesso...nel 2017 tra un pò..

Originariamente inviato da plainsong

Questa è una ben nota leggenda metropolitana della cui veridicità dubito fortemente, a meno che in AMD non avessero a suo tempo del tutto cannato le loro previsioni. Siamo ancora molto lontani dalla possibilità di abolire convenientemente l'unità fp, figuriamoci ai tempi della progettazione dell'architettura BD.

A livello teorico era una considerazione che in molti azzardavano soprattutto quando si parlava del progetto "Fusion 2" che doveva o dovrebbe essere l'ibrido tra una CPU e una GPU.
Con le APU AMD ha mandato avanti questo concetto unificando e ampliando il controller RAM, ma anche se non si parla più direttamente di fusion 2 può darsi che l'ibridazione non sia stata abbandonata, forse deve solo evolversi e prendere nuove strade (L1 e/o L2 condivisa?).
Sono curioso di capire cosa voglia dire quel + nell'architettura ZEN destinata alle future APU...

[stefanonweb]

Originariamente inviato da Veradun

Questo mi pare scontato, le CPU andranno montate su mobo in standard ATX, no?

Si, certo, magari c'è alimentazione supplementare a 8 pin ecc...

[bjt2]

Originariamente inviato da Free Gordon

Può essere che in AMD quando crearono BD, pensarano principalmente alla sua integrazione con Fusion e quindi "risparmiarono" potenza in virgola mobile, sperando di delegarla alla futura GPU integrata..?

Io ho sempre pensato così..

Peccato che le APU/HSA non abbian ancora preso piede adesso...nel 2017 tra un pò..

Esisteranno sempre algoritmi non paralellizzabili per cui un solo core da 5 GHz sarà sempre meglio anche di 10000 core a 1GHz... E questo gli ingegneri di AMD lo sanno bene... L'unica cosa sarebbe fare pochi core ad alta frequenza, con molti core a bassa frequenza, con spazio di memoria unificato... Ma questo è proprio una APU con supporto HSA... Quindi già ci siamo...

[tuttodigitale]

Originariamente inviato da george_p

Si però tutto quello che vuoi per quanto siano potenti oggi non considero arm cpu a livello delle storiche intel, amd e ibm.
Poi ripeto, ognuno ha i suoi punti di vista su cosa sia un core, e visto che funziona così per ingegneri che lavorano nel settore, chi sono io per dire cosa è o cosa non è un determinato concetto?

più che altro mi pare di capire che per cdimauro, la questione non è avere o no la FPU, ma se le 2 sezioni integer sono totalmente indipendenti
Io direi che ogni core in configurazione CMT è pari al 90%, proprio per la penalità dello scaling. Non sono 2 core puri, ma ci vanno dannatamente vicini, soprattutto da steamroller in poi che ha decoder dedicati.

Detto questo il CMT ha molto poco a che vedere con lo scarso ipc di Bulldozer.

PS molte definizioni, vengono stravolte per esigenze di marketing, vedi le ALU della gpu chiamati core/processor, i nanometraggi del silicio, ecc. Non è la prima e non sarà l'ultima volta.

Originariamente inviato da george_p

Mah, indubbiamente, solo non penso che la definizione di core nelle schede video sia la stessa di core nei processori x86.
Core è un termine e come tutti i termini viene applicato per intendere un insieme o parti di insiemi fondamentali, niente più.

Sulla class action nulla da dire, pare inutile anche a me.

per core delle gpu, nvidia si riferisce alle singole ALU...in questo senso è come se un FX8350 fosse una cpu da 48 core

EDIT
come non detto mi ero dimenticato che il oltre al SMM c'è il GPC

[george_p]

Originariamente inviato da tuttodigitale

più che altro mi pare di capire che per cdimauro, la questione non è avere o no la FPU, ma se le 2 sezioni integer sono totalmente indipendenti
Io direi che ogni core in configurazione CMT è pari al 90%, proprio per la penalità dello scaling. Non sono 2 core puri, ma ci vanno dannatamente vicini, soprattutto da steamroller in poi che ha decoder dedicati.

Detto questo il CMT ha molto poco a che vedere con lo scarso ipc di Bulldozer.

PS molte definizioni, vengono stravolte per esigenze di marketing, vedi le ALU della gpu chiamati core/processor, i nanometraggi del silicio, ecc. Non è la prima e non sarà l'ultima volta.


per core delle gpu, nvidia si riferisce alle singole ALU...in questo senso è come se un FX8350 fosse una cpu da 48 core

maxwell ha 4 scheduler/cluster da 32 core (ALU).
quindi nella dominazione AMD, i 128 cuda core, sarebbero "solo" 4 core.
Ma questi 4core, per funzionare necessitano di un front-end, e di altre unità "accessorie" tutte condivise...e questo costituirebbe il modulo CMT di AMD.

Appunto, come scritto, alla fine core è un mero termine che non indica granché di specifico in sé, ma in ogni categoria (cpu o gpu) trova una sua maggiore "definizione", e nemmeno al 100% da ciò che ho visto.
A maggior ragione creare class action per questo motivo è da pazzi o furbi.

[tuttodigitale]

Originariamente inviato da george_p

Appunto, come scritto, alla fine core è un mero termine che non indica granché di specifico in sé, ma in ogni categoria (cpu o gpu) trova una sua maggiore "definizione", e nemmeno al 100% da ciò che ho visto.

Questo è certo.

Originariamente inviato da george_p

A maggior ragione creare class action per questo motivo è da pazzi o furbi.

furbi non saprei...qualcosa dovranno pur sborsare immagino....

[george_p]

Originariamente inviato da tuttodigitale

Questo è certo.


furbi non saprei...qualcosa dovrammo pur sborsare immagino....

Furbi non è (quasi) mai sinonimo di intelligenza.

[Free Gordon]

Originariamente inviato da bjt2

Ma questo è proprio una APU con supporto HSA... Quindi già ci siamo...

Forse dovrebbero spingere moolto di più lato software...ora..
Ma ci immaginiamo cosa potrebbe fare AMD con le APU, con un team "tipo" quello di CUDA alle spalle?

[cdimauro]

Originariamente inviato da bjt2

La FPU di Zen non dovrebbe essere potente quanto quella di Skylake. E' su questo che stavo facendo i calcoli. Come dici tu dovrebbe avere 4 pipeline in grado di fare 4 operazioni a 128 bit (ad esempio 4 a 32 bit), accoppiabili per farne 2 da 256, con MOP double. Fino a XV 2 erano per l'FP (compreso FMAC) e due facevano l'SSE/AVX/MMX su interi e le altre operazioni, come conversione, accesso a memoria, e non ho notizie sulle x87.

Ci sono rumors che la FPU di Zen sia più potente di quella di BD, ma dalle stime ad occhio dell'area occupata da Zen, non sembra più grande di un modulo XV, quindi non mi aspetto che la FPU sia molto più potente...
Comunque i rumors danno 2 pipeline in grado di fare FMAC o FADD o FMUL e 2 pipeline in grado di fare solo FADD, ma anche il resto delle istruzioni (memoria conversione ecc)... Ancora nessuna notizia sulle x87...

Non credo ci siano particolari differenze con le altre istruzioni SSE/AVX: quelle x87 saranno mappate in qualche porta che mette a disposizione servizi simili.

La mia stima ottenuta moltiplicando per 8 il consumo di una FMAC a 32 bit costruita come hanno fatto quei tizi, corrisponde al caso IDEALE di 2 pipeline simmetriche, in grado di fare 2x4x32 FMAC per ciclo, continuamente alimentate dalla L1, che dovrebbe avere 2 porte in lettura a 128 bit e una in scrittura, giusto giusto per uno stream. Quindi la mia stima era per eccesso, poichè la cache può supportare solo una FMAC, ma visto che l'IPC medio di un codice FP è circa 2 (se non mi sbaglio per spec FP è stato calcolato un IPC di 2.4, compreso le istruzioni intere di controllo e di flusso, che è tantissimo, visto che per spec INT si è poco sopra 1), si può supporre che in media sia occupata un'altra pipeline, con dati intermedi, da registro, simulando un calcolo mediamente complesso.

Considera che ci sono anche le MOV (sia fra registri, sia con la memoria), che sono sempre istruzioni conteggiate come floating point, e sono pure molto frequenti (oltre a essere molto veloci), per cui si capisce perché l'IPC possa superare il 2.

E' chiaro che la FPU di Zen dovrebbe poter fare almeno altre 2 FADD per ciclo, ma la cache non dovrebbe riuscire a sostenere questo carico allo steady state. Neanche si trattasse di due thread, perchè la cache dati dovrebbe essere una sola.

L'unico codice che riuscirebbe a sforare questo limite è un codice che fa parecchie operazioni per ogni dato in memoria e quindi può usare dei registri di appoggio per i dati intermedi. Ad esempio il powerhog che mi viene in mente è un calcolo che fa una FMAC e poi combina questo risultato altre 3 volte con dati fissi oppure di cicli precedenti, conservati in registri. Potrebbe essere un qualche filtro convolutivo molto ottimizzato. A regime si potrebbero avere anche 4 istruzioni per ciclo, se i risultati nei registri sono forwardati in tempo.

4 saranno il picco, per quanto hai già detto.

Ma la maggior parte dei calcoli utili, non usano solo fmac, fmul o addizioni, ma anche funzioni più complesse come fdiv, sqrt ecc, che non hanno un throughput di 1 per ciclo per pipeline e che quindi riducono l'IPC... In casi reali non si supera il 2.

Dipende. Ci sono anche le istruzioni reciproco di divisioni e radice quadrata, che sono di gran lunga più veloci di quelle normali, e che un compilatore può benissimo utilizzare al loro posto.

Comunque il ragionamento che hai fatto mi è chiaro, ma riguarda soltanto l'unità FMAC ma, sebbene sia importante, non tiene conto di tutto il "contorno", che consuma anch'esso corrente.

Per questo rimango scettico sul prendere soltanto questo elemento per fare previsioni.

Originariamente inviato da george_p

Non posso entrare troppo nel tecnico per mia ignoranza, anche se mi piace leggere a riguardo.
Difatti ho scritto che per molti il concetto di core è prettamente l'unità integer, io i miei dubbi un pò li ho sempre, anche perché, ripeto, amd stessa è tornata indietro con core a un integer+un fpu scartando praticamente tutto il concetto di cluster, fpu condivisa, cmt ecc., aggiungendo invece anche l'smt, che per "presunzione", come voler distinguersi dalla concorrenza forse, non hanno voluto implementare sin dall'inizio.

O magari sarà stato dovuto alla cocciutaggine di qualche ingegnere capo. Capita anche questo.

Originariamente inviato da digieffe

la differenza è che tu consideri il decoder parte del core, io considero core solo il singolo risc.
[...]
a partire da un successore di BD hanno messo due decoder, da quel momento li consideri due core?

Per quanto mi riguarda, considero core un processore (nell'accezione del termine "elemento che processa") che non ha parti della pipeline condivisa con altri blocchi, fatta eccezione per le cache L2/L3/L4/memory controller/memoria.

i thread hardware di intel condividono le pipeline (dell'unico risc) in modo probabilistico. In un unico ciclo di clock se uno stadio della pipeline è occupato da un th hw non può essere disponibile per l'altro th cosa che non accade per il CMT.

Veramente succede più spesso il contrario, specialmente con codice più orientato al single-threading: le unità del thread hardware CMT sono impegnate e non possono processare altre istruzioni che, se ci fossero a disposizione tutte le porte che mette a disposizione un sistema SMT, sarebbe possibile eseguire.

E non serve nemmeno che il sistema SMT abbia lo stesso numero di porte totali di quello CMT.

quale sarebbe l'affermazione che non corrisponderebbe al vero?

Leggi il link di Bits&Chips.

Ps: personalmente preferisco SMT.

Io preferisco chi riesce a darmi migliori prestazioni in single-thread/core.

Originariamente inviato da tuttodigitale

ne avevano discusso tempo fa.

In particolare qui. Come mai hai rimosso poi il link?

ma quale narrazione storica...
la FPU era opzionale fino a pochi anni fa, per le architetture di ARM...

Come non detto....in piena epoca multi-core la FPU è opzionale, per l'a5..
http://www.arm.com/files/pdf/AT2_-_P...rtex-A5_v1.pdf vedi pagina 19

E lo sarebbe a prescindere dall'architettura. Si potrebbe benissimo sviluppare un processore x86 senza alcuna FPU: solo unità intere.

Comunque non ha più senso parlare di unità intera e unità FPU: da tempo c'è una pipeline che si "forca" sfruttando le varie porte a disposizione.

Di fatto l'unità intera e l'FPU sono state smembrate e/o moltiplicate, e il carico di lavoro viene smistato sulle varie porte specializzate.

Originariamente inviato da plainsong

Questa è una ben nota leggenda metropolitana della cui veridicità dubito fortemente, a meno che in AMD non avessero a suo tempo del tutto cannato le loro previsioni. Siamo ancora molto lontani dalla possibilità di abolire convenientemente l'unità fp, figuriamoci ai tempi della progettazione dell'architettura BD.

Non credo che l'FPU verrà mai rimossa dal core per smistare sulla GPU tutte le operazioni in virgole mobile. Hanno domini applicativi abbastanza diversi fra loro, anche se molti algoritmi (IN BLOCCO: non singole istruzioni FPU) possono essere smistati sulla GPU, SE ciò risultasse conveniente. Soprattutto se qualche sviluppatore abbia provveduto a scrivere il codice opportunamente.

Originariamente inviato da bjt2

Esisteranno sempre algoritmi non paralellizzabili per cui un solo core da 5 GHz sarà sempre meglio anche di 10000 core a 1GHz... E questo gli ingegneri di AMD lo sanno bene... L'unica cosa sarebbe fare pochi core ad alta frequenza, con molti core a bassa frequenza, con spazio di memoria unificato... Ma questo è proprio una APU con supporto HSA... Quindi già ci siamo...

In ogni caso non risolveresti il problema in generale.

Pensa a un'applicazione Python che dev'essere eseguita: smisteresti TUTTE le operazioni in virgola mobile a uno o più core della GPU integrata? Anche con la versione più evoluta ed efficiente dell'HSA, prestazionalmente sarebbe un suicidio.

Idem se fossero più istanze di applicazioni Python a girare in parallelo su più core (cosa che succede nei server, generalmente).

Originariamente inviato da tuttodigitale

più che altro mi pare di capire che per cdimauro, la questione non è avere o no la FPU, ma se le 2 sezioni integer sono totalmente indipendenti

Esattamente. Ho precisato ulteriormente sopra la mia idea.

Detto questo il CMT ha molto poco a che vedere con lo scarso ipc di Bulldozer.

Prova a lanciare un emulatore. In giro trovi benchmark di quelli più usati/blasonati (Dolphin e PCSX2 in particolare): persino il top di gamma basato su PileDriver, che è il successore di Bulldozer, mostra risultati molto scarsi.

Originariamente inviato da Free Gordon

Forse dovrebbero spingere moolto di più lato software...ora..
Ma ci immaginiamo cosa potrebbe fare AMD con le APU, con un team "tipo" quello di CUDA alle spalle?

Puoi spingere quanto vuoi: in certi (molti) calcoli l'FPU tradizionale rimane irraggiungibile.

L'unica, come dicevo, è portare interi blocchi di codice da far girare sulla GPU, ma solo se ciò ha senso e mostra realmente dei risultati migliori.

[tuttodigitale]

Originariamente inviato da cdimauro

In particolare qui. Come mai hai rimosso poi il link?

perchè nei post della nostra discussione si parla anche del bench sysmark, e volevo lasciare alle spalle la vicenda in questo thread.

Originariamente inviato da cdimauro

Prova a lanciare un emulatore. In giro trovi benchmark di quelli più usati/blasonati (Dolphin e PCSX2 in particolare): persino il top di gamma basato su PileDriver, che è il successore di Bulldozer, mostra risultati molto scarsi.

ma l'ipc basso non ha molto a che a vedere come il CMT....è come dire che le cpu SMT hanno sempre un ipc elevato....eppure il power6 è noto per avere un ipc molto basso nonostante il SMT4...ma in compenso viaggiava ad oltre 5GHz su un silicio, il 65nm, che ha dato non pochi problemi ad AMD.
è probabilmente vero il contrario: senza CMT bulldozer avrebbe un ipc ancora più basso.

Originariamente inviato da cdimauro

Comunque non ha più senso parlare di unità intera e unità FPU: da tempo c'è una pipeline che si "forca" sfruttando le varie porte a disposizione.

Nell'architettura Intel è senz'altro vero. In quella AMD che presenta uno scheduler e porte dedicate alle pipeline FP, ho qualche riserva.

[cdimauro]

Concordo assolutamente: se n'è parlato abbastanza.

Ma, parimenti, sarebbe da evitare di riprendere la discussione su core vs non-core, per gli stessi motivi.

[tuttodigitale]

Originariamente inviato da cdimauro

Ma, parimenti, sarebbe da evitare di riprendere la discussione su core vs non-core, per gli stessi motivi.

concordo tanto alla fine un termine generico come core, è per l'appunto generico.
Un ultima domanda, per curiosità: pensi che hanno fatto bene a fare causa ad AMD per questa stupidaggine? Alla fine i bench era disponibili, e solo uno sciocco (avrei molti aggettivi più azzeccati) poteva sperare che un prodotto da 150 euro potesse competere con una da 1000. AMD mica è una onlus?

[cdimauro]

Non conosco i termini precisi esposti nella causa, per cui non mi posso pronunciare.

Per me, come già detto, bisogna vedere le dichiarazioni che ha fatto AMD e se combaciano con quanto riportato nelle accuse.

Non c'entra se AMD sia ONLUS o meno, ma soltanto le sue dichiarazioni.

[bjt2]

Originariamente inviato da cdimauro

Non credo ci siano particolari differenze con le altre istruzioni SSE/AVX: quelle x87 saranno mappate in qualche porta che mette a disposizione servizi simili.

Ai fini del consumo le x87 sono ottime, perchè sono scalari... E non hanno le FMAC. Per gli 80 bit dei long double probabilmente ci saranno delle unità separate anche a causa della migliore gestione delle eccezioni e dell'arrotondamento... Se non mi sbaglio i registri non sono neanche 80 bit, ma 112 bit...

Originariamente inviato da cdimauro

Considera che ci sono anche le MOV (sia fra registri, sia con la memoria), che sono sempre istruzioni conteggiate come floating point, e sono pure molto frequenti (oltre a essere molto veloci), per cui si capisce perché l'IPC possa superare il 2.

Non ci avevo pensato... Meglio ancora per la mia stima... Se il codice più power hungry ha IPC 2.4 e alcune sono intere e alcune FMOV, ecco che la mia è una sovrastima... E anche AMD penso faccia così visto che le sue CPU non stanno quasi mai alla frequenza base anche con tutti i core occupati (con il cinebench ad esempio salta tra base e primo step di turbo con una frequenza media un po' superiore alla base...)

Originariamente inviato da cdimauro

4 saranno il picco, per quanto hai già detto.

Dipende. Ci sono anche le istruzioni reciproco di divisioni e radice quadrata, che sono di gran lunga più veloci di quelle normali, e che un compilatore può benissimo utilizzare al loro posto.

Comunque il ragionamento che hai fatto mi è chiaro, ma riguarda soltanto l'unità FMAC ma, sebbene sia importante, non tiene conto di tutto il "contorno", che consuma anch'esso corrente.

Per questo rimango scettico sul prendere soltanto questo elemento per fare previsioni.

Vedi sopra

Originariamente inviato da cdimauro

Comunque non ha più senso parlare di unità intera e unità FPU: da tempo c'è una pipeline che si "forca" sfruttando le varie porte a disposizione.

Di fatto l'unità intera e l'FPU sono state smembrate e/o moltiplicate, e il carico di lavoro viene smistato sulle varie porte specializzate.

Questo su INTEL... Su AMD è dal k7 che la FPU ha uno scheduler, porte e pipeline separato...

Originariamente inviato da cdimauro

Pensa a un'applicazione Python che dev'essere eseguita: smisteresti TUTTE le operazioni in virgola mobile a uno o più core della GPU integrata? Anche con la versione più evoluta ed efficiente dell'HSA, prestazionalmente sarebbe un suicidio.

Idem se fossero più istanze di applicazioni Python a girare in parallelo su più core (cosa che succede nei server, generalmente).

Puoi spingere quanto vuoi: in certi (molti) calcoli l'FPU tradizionale rimane irraggiungibile.

L'unica, come dicevo, è portare interi blocchi di codice da far girare sulla GPU, ma solo se ciò ha senso e mostra realmente dei risultati migliori.

Ti sei risposto da solo... Avendo sia CPU normali che "core" GPU, il codice poco parallelizzabile sarà scritto e compilato per girare sulla CPU e il codice paralellizzabile sulla GPU. Su CUDA è banale perchè per far eseguire il codice sulla GPU si deve farlo esplicitamente, mentre OpenCL per quanto ne so tratta CPU e GPU come un pool, anche se mi pare che si può specificare se un kernel può usare solo core GPU e/o CPU...

[cdimauro]

Ho visto che hai editato il precedente commento, per cui rispondo alle parti che hai aggiunto.

Originariamente inviato da tuttodigitale

ma l'ipc basso non ha molto a che a vedere come il CMT....è come dire che le cpu SMT hanno sempre un ipc elevato....eppure il power6 è noto per avere un ipc molto basso nonostante il SMT4...ma in compenso viaggiava ad oltre 5GHz su un silicio, il 65nm, che ha dato non pochi problemi ad AMD.
è probabilmente vero il contrario: senza CMT bulldozer avrebbe un ipc ancora più basso.

O più alto? Perché il problema del CMT è che, come già detto, mette un tappo/tetto alle prestazioni eseguibili, a causa del numero di porte intere a disposizione.

Anche se il codice che gira nel tuo thread hardware potrebbe eseguire più istruzioni intere, alle fine si trova bloccato aspettando le due ALU e/o le due load/store si liberino...

Per il POWER6 il discorso è completamente diverso, visto che è orientato al puro multithreading / throughput.

Nell'architettura Intel è senz'altro vero. In quella AMD che presenta uno scheduler e porte dedicate alle pipeline FP, ho qualche riserva.

Perché?

[bjt2]

Originariamente inviato da cdimauro

Perché?

AMD dal k7 è tornato al design a coprocessore, sfruttato al limite in BD con il CMT... Pipeline, scheduler e porte separate... Solo il ritiro è condiviso, ma mi pare che nell'architettura a coprocessore la CPU era il master e teneva tutti i flags e aspettava il coprocessore esterno che restituiva dati e/o eccezioni/stato, "ritirando" l'istruzione e sollevando eventuali eccezioni...

[tuttodigitale]

Originariamente inviato da cdimauro

O più alto? Perché il problema del CMT è che, come già detto, mette un tappo/tetto alle prestazioni eseguibili, a causa del numero di porte intere a disposizione.

ma non è il CMT a mettere il tappo. Come ho detto tempo fa, non basta una terza ALU, per avere magicamente un ipc alto. Ma è l'architettura, TUTTA, equilibrata per quelle 2 ALU. Ricordo che un modulo CMT, è grande quanto un core Sandy Bridge, che a sua volta è grande quanto 2 core k10, quindi l'architettura Intel è oggettivamente molto complessa.

Ma nessuno vieta ad AMD di fare un CMT ad alto ipc..ma poi si sarebbe trovata di fatto, con un'architettura inefficiente, quale teoricamente sono quelle ad alte ipc con un solo thread attivo.