Intel Core i7-6700K in overclock a 5,20GHz con raffreddamento ad aria

[Piedone1113]

Originariamente inviato da cdimauro

Scusami, avevo capito male io allora.

Francamente lo trovo improbabile per due ragioni: Intel riesce a fornire processori che finora si sono dimostrati inarrivabili in termini prestazioni, pur tenendo d'occhio i consumi.

Ma la ragione principale è che Apple ha aumentato il suo market share in ambito "desktop" proprio dopo essere passata dai PowerPC ai processori di Intel, grazie alla possibilità di poter eseguire anche Windows e lo stuolo di applicazioni (nonché giochi) x86.

Dubito fortemente che possa fare marcia indietro, rimuovendo questa comodissima possibilità.

Ne ha fatto di cose in passato che toglievano comodità e libertà all'utente.
Tanto si dirà, ma le cpu arm sono migliori ed via nel cesso le limitazioni x86 brutte, pesanti e cattive.
Guarda pure che prodotto a messo fuori con il macpro.
Sta spingendo molto sul cloud e verosimilmente la transizione sarà fatta anche spostando il calcolo in cloud per far sentire di meno il peso della compatibilità x86 mancante.
E poi con apple è sempre stato o così o Pomì.
Quindi credo che arm su mac sia possibile con un buon margine di possibilità.

[cdimauro]

Alla guida di Apple non c'è più l'intransigente Jobs, ma il ben più pragmatico Cooks.

[Piedone1113]

Originariamente inviato da cdimauro

Alla guida di Apple non c'è più l'intransigente Jobs, ma il ben più pragmatico Cooks.

Be Jobs avrebbe tranquillamente rinunciato ad una piccola percentuale di utili per il design, l'esclusività e l'efficienza.
Coocks cerca di massimizzare i profitti e mi pare di aver visto un'accellerata nella convergenza mobile-desktop ed il tentativo di formare un ecosistima unico (nello stesso modo che sta cercando di fare ms con continuum, ma seguendo strade diverse con la seconda che cerca di portare il desktop sul mobile ed apple il contrario).
A ben vedere gli utili maggiori per apple nel prossimo futuro arriveranno dai servizi, perché da pratico che è Coocks sa bene che si arriverà al punto di saturare il mercato e dover produrre per rimpiazzare le macchine obsolete, ma soprattutto fare utili dai servizi.

[calabar]

Originariamente inviato da cdimauro;

Sì, ma la nuova architettura la puoi realizzare a prescindere dal processo produttivo. Il nocciolo è questo.

L'architettura puoi progettarla, certo, ma se poi non hai il silicio su cui stamparla...

AMD ha fatto un errore sulla valutazione del processo produttivo con il Phenom I. Come dimostrano i Phenom II il progetto non era affatto cattivo, ma il processo produttivo non era adatto.
A confermarlo le dichiarazioni della stessa Intel, che disse che neppure loro, che disponevano dei transistor migliori, avrebbero osato tanto (ossia sviluppato un progetto così complesso sul processo produttivo disponibile in quel periodo), e i fatti hanno dato loro ragione.

Il progetto è fortemente legato ai processi produttivi disponibili, e i problemi che le fonderie hanno avuto negli ultimi anni su qualità dei processi e tempistiche sono stati uno dei principali problemi per AMD.

[cdimauro]

Forse non sono stato chiaro. Non parlavo di cambiare architettura aumentando a dismisura l'uso dei transistor, ma di sfruttare ciò che offre l'attuale processo produttivo per realizzare un'architettura nuova.

Se, per essere chiari, l'approccio CMT ha dimostrato di essere fallimentare, lo si butta e si progetta un nuovo chip, ma con gli stessi limiti del processo che è disponibile.

Prendi, ad esempio, Skylake: usa lo stesso processo produttivo di Broadwell (14nm), ma la (micro)architettura sarà nuova. I transistor li hanno usati in modo diverso...

[calabar]

Originariamente inviato da cdimauro;

Forse non sono stato chiaro. Non parlavo di cambiare architettura aumentando a dismisura l'uso dei transistor, ma di sfruttare ciò che offre l'attuale processo produttivo per realizzare un'architettura nuova.

Direi che non avevo capito l'affermazione allora!

Ad ogni modo anche questo non è così semplice. Se la fonderia da cui ti fornisci ti dice che tra sei mesi ci sarà il nuovo processo produttivo, tu ovviamente non investi in un progetto nuovo ma decidi di attendere sei mesi.
Poi però ti dicono che ci sono ritardi, che ci vorranno altre sei mesi, poi magari altri sei, poi cancellano il processo e si dedicano solo a quelli low power perchè il mercato tira da quella parte...

Ecco, ora applica questo ragionamento al fatto che non è disponibile da anni alcun processo produttivo per processori ad alte prestazioni dopo il 32nm SOI.

Intel ha le proprie fonderie (e un mercato che le consente di mantenerle) e per lei questo tipo di problemi sono di entità molto ridotta, per AMD invece in questi ultimi anni sono stati una bella mazzata.
É evidente che AMD deve gestire le proprie risorse che ha a disposizione, e investire in una nuova architettura è una cosa che va fatta con una certa cautela, non può certo permettersi due team che lavorano alternati come Intel.

Probabilmente all'inizio contavano di risolvere i problemi di BD, magari con un nuovo processo produttivo adeguato che non c'è stato. Visto l'andazzo ad un certo punto hanno iniziato a progettare la nuova architettura con alto IPC, che vedremo il prossimo anno.

[cdimauro]

I problemi di Bulldozer erano strutturali, e non potevano essere risolti con un nuovo processo produttivo, ma con una nuova microarchitettura.

Comunque, ormai è andata così. Vedremo il prossimo anno.

[Piedone1113]

Originariamente inviato da cdimauro

I problemi di Bulldozer erano strutturali, e non potevano essere risolti con un nuovo processo produttivo, ma con una nuova microarchitettura.

Comunque, ormai è andata così. Vedremo il prossimo anno.

I problemi di BD sono strutturali
Quelli di AMD finanziari.
Quelli di un'architettura competitiva il numero dei transistor.

Fuori da questo non si va da nessuna parte.

Ma tengo a rammentarti:
Willamette 42mil transistor ipc normalizzato 100
Northwood 54mil transistor ipc 104
Prescott 125mil transistor ipc 84

Questp riferito al cpu mark.
Negli altri applicativi dove si sfruttavano estensioni non presenti in willamette non possiamo dare giudizi, ma tra
Northwood e Prescott abbiamo:
northwood Prescott
Business winstone 100 100.5
Multimedia cc winstone 100 93
In Game 100 100
View perf7.1 suite 100 105
Sciencemark 100 96
Sperpi (media) 100 108 (Solo grazie alla cache maggiore)
Rendering 100 94
Cinebench 100 85
Encoding Audio 100 90
encoding divx 100 104
Encoding mpeg1/2 100 108
Windows media encoder9 100 120

Willamette è uscito nel novembre 2000
Cedarmill gennaio 2006.
Una famiglia di cpu che invece di migliorare (nonostante triplicarsi del numero di transistor) il proprio IPC lo peggiorava.
E mi sembra che intel avesse sia le tecnologie che le risorse economiche per poter rifare ex novo un'architettura desktop.
Perché sei così convinto che AMD avrebbe avuto le risorse tecniche ed economiche di buttar fuori una nuova architettura subito dopo il fiasco BD?

[cdimauro]

Prescott era stato progettato per salire molto più in frequenza rispetto a Northwood: è questo il motivo per cui aveva una pipeline molto più lunga, e dunque un peggior IPC. Da una parte si peggiora l'IPC, ma dall'altra si bilancia con l'aumento di frequenza.

Il problema è che Intel non è riuscita a spingere molto le frequenze rispetto a Northwood, a causa delle correnti di leakage, cosa che ha poi sancito la fine del progetto NetBurst. D'altra parte è lo stesso motivo per cui la scalata in frequenza dai 90nm in poi, s'è ridotta moltissimo, e questo per tutti.

Comunque già nel 2003 Intel aveva proposto una nuova architettura, il Pentium-M, che sebbene fosse stata pensata per il mobile era possibile impiegare anche in altri ambiti. Infatti è quella che avrebbe poi preso il posto dei Pentium4, sotto il nome di Core 2, a causa dei problemi di cui sopra che aveva NetBurst.

Riguardo al numero dei transistor, dai 125 milioni impiegati per Prescott, passiamo ai 151 di Yonah, di cui buona parte sono utilizzati per l'enorme (per l'epoca) cache L2 da 2MB. Dunque, come vedi, si può realizzare anche un'architettura con un miglior IPC, e con un simile budget di transistor.

Riguardo ad AMD, in passato ha sempre dimostrato di tirare fuori processori competitivi e innovativi. E' con Bulldozer che, invece, ha tirato i remi in barca. Il problema, più che finanziario, a mio avviso è dovuto al fatto che gente come Keller era andata via, che non è riuscita a rimpiazzare adeguatamente. Anche oggi AMD è in difficoltà finanziaria, eppure sta progettando una nuova architettura, proprio con Keller a dirigere il tutto, visto che è tornato.

[Piedone1113]

Originariamente inviato da cdimauro

Prescott era stato progettato per salire molto più in frequenza rispetto a Northwood: è questo il motivo per cui aveva una pipeline molto più lunga, e dunque un peggior IPC. Da una parte si peggiora l'IPC, ma dall'altra si bilancia con l'aumento di frequenza.

Il problema è che Intel non è riuscita a spingere molto le frequenze rispetto a Northwood, a causa delle correnti di leakage, cosa che ha poi sancito la fine del progetto NetBurst. D'altra parte è lo stesso motivo per cui la scalata in frequenza dai 90nm in poi, s'è ridotta moltissimo, e questo per tutti.

Comunque già nel 2003 Intel aveva proposto una nuova architettura, il Pentium-M, che sebbene fosse stata pensata per il mobile era possibile impiegare anche in altri ambiti. Infatti è quella che avrebbe poi preso il posto dei Pentium4, sotto il nome di Core 2, a causa dei problemi di cui sopra che aveva NetBurst.

Riguardo al numero dei transistor, dai 125 milioni impiegati per Prescott, passiamo ai 151 di Yonah, di cui buona parte sono utilizzati per l'enorme (per l'epoca) cache L2 da 2MB. Dunque, come vedi, si può realizzare anche un'architettura con un miglior IPC, e con un simile budget di transistor.

Riguardo ad AMD, in passato ha sempre dimostrato di tirare fuori processori competitivi e innovativi. E' con Bulldozer che, invece, ha tirato i remi in barca. Il problema, più che finanziario, a mio avviso è dovuto al fatto che gente come Keller era andata via, che non è riuscita a rimpiazzare adeguatamente. Anche oggi AMD è in difficoltà finanziaria, eppure sta progettando una nuova architettura, proprio con Keller a dirigere il tutto, visto che è tornato.

Il massimo che avrebbe potuto fare AMD con i 32nm GF sarebbe stato una cpu con 6 core (circa 1,3 miliardi di transistor), stesso ipc di sandy bridge e frequenze nell'ordine dei 3-3,2 GHz (ad essere ottimisti), insomma una pezza ma non una cpu in grado di competere contro due revisioni dei 22nm della concorrenza.
Non so se la nuova architettura sarà rivoluzionaria rispetto alle classiche cpu x86 che siamo abituati a vedere, ma le voci parlano comunque di molti transistor in campo e l'abbandono delle cache esclusive.
Eppure nonostante il tutto io vedo in BD una cpu in con un ottimo potenziale, ma purtroppo con alcune scelte architetturali tali da annullare i vantaggi della struttura a moduli (perché ci sono) senza mitigare la perdita di ipc del singolo core.
Keller è tornato in amd, ma sappiamo anche che le sue architetture Hanno costi di sviluppo sia in termini economici che temporali altissime dato che ha la propensione di massimizzare le prestazioni di ogni singola parte della cpu cercando di raggiungere il limite teorico prefissato a tutti i costi.
Questo non so se nell'attuale situazione di amd sia un punto a favore (raggiungere e forse superare le prestazioni di intel a parità di transistor), oppure a sfavore (elevato tempo di sviluppo dell'architettura), sperando che il pp previsto sia quello di inizio progetto e che non si debba virare verso un diverso pp allungando ulteriormente i tempi di sviluppo.
Per il resto ormai è storia passata ed i se e i ma non cambiano la situazione attuale.

[cdimauro]

Già. Per questo aggiungo soltanto una nota. A mio avviso AMD con Bulldozer ha puntato tutto sulle prestazioni in multithread, sacrificando troppo l'IPC. Non tutto il software può lavorare bene in multithreading; tutt'altro.

E' il motivo per cui prediligo processori che offrono un elevato IPC (per core/thread): mediamente si possono sfruttare meglio con l'enorme parco software. A maggior ragione col software che m'interessa di più: emulazione e compilazione.

[Vul]

Originariamente inviato da Piedone1113

Be Jobs avrebbe tranquillamente rinunciato ad una piccola percentuale di utili per il design, l'esclusività e l'efficienza.

Ma se il design, l'esclusività e l'efficienza sono il motivo stesso per cui Apple fa utili.

[Piedone1113]

Originariamente inviato da Vul

Ma se il design, l'esclusività e l'efficienza sono il motivo stesso per cui Apple fa utili.

Non puoi estrapolare una frase dal discorso:
Jobs non avrebbe incrementato gli utili abbandonando l'uso di x86 sui dispositivi che ne fanno uso attualmente solo per aumentare gli utili.
Avrebbe offerto al pubblico un prodotto chiaramente inferiore non pagando ad intel le cpu ma facendosele in casa.
Arm ancora non è in grado di offrire quello che offre x86, e forse mai lo farà, ma per i prossimi 2 anni una cpu arm su mac è improponibile, magari tra 3 il buon caro Coocks deciderà di massimizzare ancora i profitti sostituendo x86 con un bel A12 by Apple, ma non credo che Jobs sarebbe stato favorevole.
Coocks = massimizzare i profitti
Jobs = dispositivi senza compromessi.

Spero di essermi spiegato.

[digieffe]

Originariamente inviato da cdimauro

No, Intel continua a tirare per la sua strada, e fa del suo meglio per rilasciare prodotti migliori.

con tutta la stima che ti porto pur non conoscendoti, credo che Intel persegua ciò che persegue ogni azienda: gli utili.

E nel fare ciò non necessariamente si devono rilasciare prodotti migliori, si fanno apposite valutazioni per capire quanta qualità conviene immettere nei prodotti e come massimizzare gli utili anche tenendo conto delle quote di mercato.

[digieffe]

Originariamente inviato da cdimauro

Già. Per questo aggiungo soltanto una nota. A mio avviso AMD con Bulldozer ha puntato tutto sulle prestazioni in multithread, sacrificando troppo l'IPC. Non tutto il software può lavorare bene in multithreading; tutt'altro.

E' il motivo per cui prediligo processori che offrono un elevato IPC (per core/thread): mediamente si possono sfruttare meglio con l'enorme parco software. A maggior ragione col software che m'interessa di più: emulazione e compilazione.

spero che detto da te sia più convincente... io ho finito il fiato

[cdimauro]

Originariamente inviato da digieffe

con tutta la stima che ti porto pur non conoscendoti, credo che Intel persegua ciò che persegue ogni azienda: gli utili.

E nel fare ciò non necessariamente si devono rilasciare prodotti migliori, si fanno apposite valutazioni per capire quanta qualità conviene immettere nei prodotti e come massimizzare gli utili anche tenendo conto delle quote di mercato.

E' chiaro che l'obiettivo siano gli utili, ma considerata la situazione nel mercato desktop, Intel potrebbe benissimo mettere i remi in barca e riciclare i prodotti che già gli consentono di accaparrarsi la maggioranza del mercato.

Invece continua a proporre nuove (micro)architetture e a investire in processi produttivi più avanzati.

Non si può rimanere a guardare, specialmente in un mercato dinamico questo. Bisogna sempre cercare di migliorarsi, perché non sai chi potrebbe arrivare domani e soffiarti il mercato.

Originariamente inviato da digieffe

spero che detto da te sia più convincente... io ho finito il fiato

In alternativa puoi invitare chi la pensa diversamente a disassemblare applicazioni di tipologie diverse che non sembrano trarre vantaggio da più core (o thread hardware), e a mostrare in che modo sarebbe possibile parallelizzare il codice.

I forum sono pieni di tuttologi che pontificano senza avere la minima idea di come funzionano realmente le cose. Ma di fronte alla prova dei fatti, "casualmente" o si trincerano dietro vuote e inutili parole, oppure spariscono.

[AleLinuxBSD]

A frequenza standard pare che i miglioramenti disponibili risultino nella norma rispetto a quanto accaduto in passato:
Intel Core i7-6700K ‘Skylake’ test results: 4–8% faster than Core i7-4790K

[Piedone1113]

Originariamente inviato da cdimauro

In alternativa puoi invitare chi la pensa diversamente a disassemblare applicazioni di tipologie diverse che non sembrano trarre vantaggio da più core (o thread hardware), e a mostrare in che modo sarebbe possibile parallelizzare il codice.

I forum sono pieni di tuttologi che pontificano senza avere la minima idea di come funzionano realmente le cose. Ma di fronte alla prova dei fatti, "casualmente" o si trincerano dietro vuote e inutili parole, oppure spariscono.

Apparentemente hai ragione, ma il bilanciamento ipc/th disponibili va sempre modificandosi e l'optimum che abbiamo adesso sarà diverso tra 5 anni.
Allo stato odierno l'architettura intel (quella attuale) è quella più equilibrata, ma con l'evoluzione degli os e dei software, con sempre più processi e moduli in esecuzione contemporanei ci stiamo sempre più spostanto verso molti processi leggeri in esecuzione e alcuni software monoTH con elevata richiesta di IPC:
L'ideale sarebbe una cpu con 16 o più core leggeri e 4/6 core ad elevato ipc.
Onestamente credo che una cpu con HT4 sarebbe una buona scelta tra 3-5 anni, con elevato ipc sul singolo th e possibilità di eseguire th a basso ipc senza significative perdite e senza un aumento spropositato dei transistor relegando l'architettura a moduli ad una nicchia ben specifica di impieghi (sempre che ci sia in futuro una tale cpu)

[cdimauro]

E' condivisibile, ma mi riferivo ad altro nel mio precedente commento, e più precisamente a due cose.

La prima è che il software, di per sé, non è affatto detto che possa trarre vantaggio da più core (o thread hardware): dipende tutto dagli algoritmi che utilizza. Ci sono algoritmi facilmente parallelizzabili, altri che richiedono più impegno/risorse, altri ancora che non lo sono del tutto.

Ci possono essere i programmatori più bravi al mondo, ma questi limiti non si possono valicare: se ho un algoritmo strettamente sequenziale, nessuno riuscirà a parallelizzarlo in alcun modo e per quanto tempo/risorse possa impiegare.

La seconda riguarda, invece, l'hardware, e più precisamente la capacità che ha un processore di elaborare il più velocemente possibile il codice che gli viene dato in pasto. Una misura che viene spesso usata è l'IPC: istruzioni (ovviamente mediamente eseguite) per ciclo di clock. I processori moderni sono in grado di eseguire più istruzioni per ciclo di clock, e dunque hanno un IPC > 1.

Ciò è dovuto al fatto che hanno a disposizione più unità di calcolo che possono essere utilizzate in parallelo (nello stesso ciclo di clock), unito al fatto che possono eseguire più istruzioni allo stesso tempo. Le istruzioni di un programma, però, devono essere eseguite strettamente sequenzialmente per ottenere il risultato atteso.

Si è cercato di ovviare a questo introducendo tecniche come l'esecuzione in-order e, ancor meglio, out-of-order, dove il processore prova a eseguire più istruzioni in parallelo, dove non vi siano dipendenze, oppure "congelando" alcune istruzioni in attesa del risultato di altre.

Si potrebbe pensare, quindi, di aumentare a dismisura il numero di unità d'esecuzione, di istruzioni eseguibili contemporaneamente per ciclo di clock, e i buffer deputati al mantenimento delle istruzioni "congelate" in attesa che le altre da cui dipendono si sblocchino. Il problema è che tutto ciò ha un costo enorme, ma soprattutto man mano che si aumentano queste risorse i benefici calano velocemente, in quanto non viene risolto alla radice l'inghippo delle dipendenze, ma soltanto posticipato in continuazione.

Siccome le dipendenze che si vengono a creare man mano che si esegue il codice sono parecchie, alla fine il sistema passerebbe più tempo in stallo che a eseguire istruzioni, dunque vanificando l'enorme aumento delle risorse precedenti.

Per rendersi conto di ciò basterebbe disassemblare il codice, e analizzare le istruzioni che vengono eseguite, con le loro dipendenze: posto che si abbia abbastanza esperienze con le architetture dei processori, si arriva facilmente alla conclusione di cui sopra.

Non esistono, dunque, ricette magiche che consentano di aumentare arbitrariamente l'IPC di un processore, e quindi migliorare sensibilmente le prestazioni. Chi afferma il contrario è il classico tuttologo internettiano che non ha idea di ciò di cui sta parlando.

P.S. Il mio discorso è generale. Poi è ovvio che ci siano casi particolari in cui sarebbe possibile eseguire in parallelo parecchie istruzioni. E' anche il motivo per cui sono nate le unità SIMD: per sfruttare certi pattern d'esecuzione che consentono una facile parallelizzazione. Ma anche qui, non ci può spingere arbitrariamente aumentando a dismisura la dimensione dei registri SIMD e/o il numero di istruzioni SIMD eseguibili per ciclo di clock. Anche questo codice, alla fine, presenta delle dipendenze che vanno risolte.

[Piedone1113]

Originariamente inviato da cdimauro

E' condivisibile, ma mi riferivo ad altro nel mio precedente commento, e più precisamente a due cose.

La prima è che il software, di per sé, non è affatto detto che possa trarre vantaggio da più core (o thread hardware): dipende tutto dagli algoritmi che utilizza. Ci sono algoritmi facilmente parallelizzabili, altri che richiedono più impegno/risorse, altri ancora che non lo sono del tutto.

Ci possono essere i programmatori più bravi al mondo, ma questi limiti non si possono valicare: se ho un algoritmo strettamente sequenziale, nessuno riuscirà a parallelizzarlo in alcun modo e per quanto tempo/risorse possa impiegare.

La seconda riguarda, invece, l'hardware, e più precisamente la capacità che ha un processore di elaborare il più velocemente possibile il codice che gli viene dato in pasto. Una misura che viene spesso usata è l'IPC: istruzioni (ovviamente mediamente eseguite) per ciclo di clock. I processori moderni sono in grado di eseguire più istruzioni per ciclo di clock, e dunque hanno un IPC > 1.

Ciò è dovuto al fatto che hanno a disposizione più unità di calcolo che possono essere utilizzate in parallelo (nello stesso ciclo di clock), unito al fatto che possono eseguire più istruzioni allo stesso tempo. Le istruzioni di un programma, però, devono essere eseguite strettamente sequenzialmente per ottenere il risultato atteso.

Si è cercato di ovviare a questo introducendo tecniche come l'esecuzione in-order e, ancor meglio, out-of-order, dove il processore prova a eseguire più istruzioni in parallelo, dove non vi siano dipendenze, oppure "congelando" alcune istruzioni in attesa del risultato di altre.

Si potrebbe pensare, quindi, di aumentare a dismisura il numero di unità d'esecuzione, di istruzioni eseguibili contemporaneamente per ciclo di clock, e i buffer deputati al mantenimento delle istruzioni "congelate" in attesa che le altre da cui dipendono si sblocchino. Il problema è che tutto ciò ha un costo enorme, ma soprattutto man mano che si aumentano queste risorse i benefici calano velocemente, in quanto non viene risolto alla radice l'inghippo delle dipendenze, ma soltanto posticipato in continuazione.

Siccome le dipendenze che si vengono a creare man mano che si esegue il codice sono parecchie, alla fine il sistema passerebbe più tempo in stallo che a eseguire istruzioni, dunque vanificando l'enorme aumento delle risorse precedenti.

Per rendersi conto di ciò basterebbe disassemblare il codice, e analizzare le istruzioni che vengono eseguite, con le loro dipendenze: posto che si abbia abbastanza esperienze con le architetture dei processori, si arriva facilmente alla conclusione di cui sopra.

Non esistono, dunque, ricette magiche che consentano di aumentare arbitrariamente l'IPC di un processore, e quindi migliorare sensibilmente le prestazioni. Chi afferma il contrario è il classico tuttologo internettiano che non ha idea di ciò di cui sta parlando.

P.S. Il mio discorso è generale. Poi è ovvio che ci siano casi particolari in cui sarebbe possibile eseguire in parallelo parecchie istruzioni. E' anche il motivo per cui sono nate le unità SIMD: per sfruttare certi pattern d'esecuzione che consentono una facile parallelizzazione. Ma anche qui, non ci può spingere arbitrariamente aumentando a dismisura la dimensione dei registri SIMD e/o il numero di istruzioni SIMD eseguibili per ciclo di clock. Anche questo codice, alla fine, presenta delle dipendenze che vanno risolte.

Sono perfettamente d'accordo.
Basti gia guardare ai software di rendering (cpu only)
Sono altamente parallelizzabili, eppure nonostante tutto un raddoppio dei core non porta ad un raddoppio delle prestazioni (a parità di architettura) tranne rari casi dove una cache l3 (o l4) maggiore porta benefici nel trasferimento dati (se la l3 si satura per via di dati maggiori della sua dimensione le prestazioni decado in modo esponenziale, ma non ha valore probatorio perché una l3 di dimensione maggiori porterebbe lo stesso vantaggio percentuale normalizzato con la metà dei core).
Stesso discorso per l'HT.
Un software che sfrutta per intero la cpu portandola ad eseguire codice in ogni sua parte avrà zero benefici dall'ht (addirittura si possono ridurre le prestazioni con ht attiva).
Un codice invece che accede sequenzialmente a parti diverse della cpu con dipendenze anch'esse sequenziali teoricamente porterebbe il + 100% di prestazioni dall'ht (sempre che un software fuori laboratorio così fatto abbia senso di esistere).
Ormai la strada migliore è un alto ipc con 2-4 th a core in modo da avere un buon equilibrio tra ipc single th ed ipc multi th.
Magari tra 4-5 anni nuove tecniche di programmazione renderanno l'ipc single th relativamente importante ed allora avremo necessità di cpu etereogeniche (credo che tu sappia cosa intendo) o con moltissimi core semplici, e potremmo rivedere strutture tipo il cell (non architettura cell), strutture omogenee evoluzioni di fusion, e gestione a moduli semplici (4-8 core a modulo compatti e con basso ipc rispetto ad architettura classica) per un totale di 80-120 core totali, oppure cpu altamente parallele come quelle sulle quali lavori.
Insomma il futuro è da scoprire, anche se credo che il massimo saranno le cpu polimorfe con struttura modulare, 16 core int (da max 2 istruzioni per clock), 4 fpu (da 2-3 istruzioni per clock), e 1-2 core companion che avranno la funzione di creare le cpu virtuali:
Th con elevato carico int parallelizzabile il core companion assegna alla cpu virtuale A 6 core int e 1 fpu.
Elevato carico sequenziale int fpt: 16 cpu da 1 core int ed 1/4 di tempo fpu.
Elevata flessibilità per il general purpose.
Ma credo che sia un'architettura ancona lontana dal poter essere realizzata (una parte vliw nei companion ed il resto x86-64) e forse nemmeno mai realizzabile economicamente.