Link alla notizia: http://www.hwupgrade.it/news/cpu/17991.html

Mai confermate ufficialmente da AMD, le notizie su una possibile tecnologia che unifichi due core in uno vengono smentite

Click sul link per visualizzare la notizia.

"le software house si stanno sempre più spingendo verso l'adozione di architetture di tipo multitasking"

facciamo multithreading, va...

eh si, bella svista ;)

ma alla fine si... un solo super-procio nn serve ad una beneamata... se non a far dormire sugli allori i programmatori che non muovono il sedere verso la direzione multi-core

beh peccato una gestione dinamica poteva essere interessante, ma non implementarla del tutto è un vero peccato... Vabbè :)

non tutto e' parallelizzabile ed avere uno scheduler che dinamicamente sposta un thread su piu' core, o piu' thread su piu' core non e' cosa malvagia, anche se non subito immediato.

Non so se avete letto la notizia dell'Inquirer: smentisce e basta, non cita fonti, non fornisce giustificazioni. Da prendere con le dovute precauzioni. Se è vero che la direzione è quella del multithreading, è anche vero che non sempre è possibile pensare un software completamente parallelizzato. Ed in ogni caso ci sono istruzioni che possono essere completamente "spezzate a metà" e fatte elaborare a due core distinti.
Insomma, potrebbe comunque valerne la pena.

Bene sono contento che non ci sia nessun reverse HT, infatti come ho già detto nel futuro ci saranno sempre + videogiochi e altri programmi come ad esempio Oblivion che traggono già vantaggio dai processori dual core molto + che da single core anche se con frequenza + elevata.

inquirer = affidabilità 0%

non tutto e' parallelizzabile ed avere uno scheduler che dinamicamente sposta un thread su piu' core, o piu' thread su piu' core non e' cosa malvagia, anche se non subito immediato.
Il problema che vedo in questo approccio è lo stesso per cui (che io sappia) nessuno produce CPU single core con 16 pipelines. La stessa dipendenza fra dati che in alcuni casi impedisce ai programmatori di spezzare un'operazione in più thread impedirebbe anche allo scheduler/dispatcher di smistare le operazioni su un numero elevato di pipelines, anche se queste appartenessero ad un unico core. Discorso diverso per le GPU, ovviamente, che trattano dati molto più parallelizzabili (il colore di un pixel se ne infischia del colore dei pixel circostanti).
Va inoltre ricordato che la voce dalla quale è partito tutto proveniva proprio da The Inquirer. Sono molto simpatici, ma la fame di scoop nuoce all'obiettività.

non tutto e' parallelizzabile ed avere uno scheduler che dinamicamente sposta un thread su piu' core, o piu' thread su piu' core non e' cosa malvagia, anche se non subito immediato.
Se il programmatore stesso non riesce a parallelizzare un programma per limiti imposti dalla tecnologia, non credo esista processore al mondo in grado di farlo per lui. (istruzioni obbligatoriamente sincronizzate, fasi critiche ecc.)

IMHO questa tecnologia serviva solo per applicazioni non multithread per mancanza di voglia o progettazione "vecchia" da parte degli sviluppatori.

Resta il fatto che se non ricordo male AMD ha qualche brevetto al riguardo...

Non capisco, perchè è necessario che il sistema operativo veda 1 solo processore? Non è possibile che i core si passino le unità di calcolo non utilizzate in maniera trasparente anche se vengono identificati entrambi dal SO?

The inculer é un sito di minchioni, ma se effettivamente questa notizia é vera IMHO é una grossissima delusione, mi aspettavo molto da questa idea di AMD

The inculer é un sito di minchioni

per piacere evitiamo... :rolleyes:

The Inquirer può non piacere a noi italiani sopratutto perchè non capiamo quello che è il tipico giornalismo inglese, che fa un sacco di speculazioni sulle notizie di corridoio... Io trovo The Inquirer un ottimo sito con un format completamente differente dagli altre testate di informazione sulla tecnologia, certo non ti puoi aspettare che tutto quello che pubblicano corrisponda a verità, visto che per loro stessa ammisione si occupano proprio di pubblicare "rumors"... :)

Ciao,

scusate, non mi intendo molto di parallelizzazione del codice, ho sempre programmato in single thread. Ma domando: se un codice non e' parallelizzabile a livello software, perche' mai dovrebbe esserlo in hardware? Mi spiego, una serie di core diversi che lavorano sullo stesso thread possono dare conflitti a livello di program counter, a livello di coerenza di cache (che si fregherebbe completamente dopo ogni istruzione), ma specialmente a livello di pipeline, dove interdipendenze tra le istruzioni dovrebbero essere risolte a livello di 2 core: una cosa impossbile. Il tutto in somma si ridurrebbe nell'avere una sola CPU (chiaramente, visto che sullo stesso thread non ci possono essere piu' di 2 CPU!) con le unita' di esecuzione di 2 CPU che pero' non potrebbero essere sfruttate per via di quanto scritto sopra. Morale, secondo me e' una voce di corridoio a livello di pesce d'aprile... ed ha poco senso, visto che "l'ottimizzazione" viene fatta a livello di codice e non a livello di unita' di controllo. Se non si riesce a farla a livello di codice, quando un compilatore ha tempo virtualmente infinito per farlo e specialmente risorse illimitate, cosa puo' fare una control unit cablata e per giunta in pochi nanosecondi?

Ciao,
...
:mano: esattamente ciò che intendevo poco sopra... se c'è un motivo per cui non sia possibile rendere multithread un codice, allora quel motivo resta valido anche a livello CPU. Si salverebbero solo i software "vecchi" che non sono multithread perché non progettati in questo modo, ma che non hanno vincoli particolari.

Se consideriamo i core come 'divoratori' di istruzioni potrebbe essere utile accoppiarne due insieme, basta guardare il lavoro fatto con Cell di IBM (PS3). In linea teorica con N core visti come un'unica cpu le prestazioni dovrebbero essere moltiplicate per N (mantenendo invariata la frequenza uguale per tutti i core).

La filosofia dual-core si basa sul concedere tutto un core al programma attivo e le restanti (in background) al secondo core. Forse accoppiare quattro, otto, sedici core e farli vedere come un dual-core potrebbe essere la soluzione.

Se pensate che piu' la frequenza aumenta piu' la temperatura diventa assurda e molte prestazioni vengono 'perse' (guardate HT di intel che e' un modo per guadagnare un 20% spremendo un solo core alla medesima frequenza) forse c'e' un limite che dimostra come N core a basse frequenze sono piu' efficienti di un solo core ad alta frequenza.

Se AMD smentisce, forse Intel ci sta pensando seriamente.

...
In linea teorica con N core visti come un'unica cpu le prestazioni dovrebbero essere moltiplicate per N
...
:eek: ma dove? solo su sistemi in cui la sequenza di istruzioni può essere eseguita in ordine sparso!

esistono due tipi di programmi a cui si può applicare questo discorso del "Reverse HyperThreading"

1) programmi che sono stati sviluppati prima dell'avvento massiccio dei Dual/Tri/Quad/MultiCore

in questo caso questo sistema funzionerebbe, ma ancora meglio sarebbe dividere il programma in thread partendo dal codice, in modo da avere già in anticipo una stima del carico di lavoro di ogni thread e creare delle suddivisioni logicamente corrette

2) programmi che non sono stati realizzati multithreaded perché NON SI POTEVA FARE, magari perché ci sono delle sequenze di istruzioni (e capita spessissimo) che il programmatore SA di non poter dividere

in questo caso è tutto inutile, puoi avere anche 45 Core, ma se la sequenza inscindibile viene assegnato al 15°, lavorerà da solo perché così deve essere.

3) (ma non avevo detto 2? :stordita: ) programmi che si evolvono da single-thread a multithread, dove i programmatori individuano le zone parallelizzabili e ci applicano una divisione in thread, ed in questo caso il programmatore SA qual è un punto ad alta richiesta di risorse, quindi sfrutterà meglio i multicore

Ciao,

scusate, non mi intendo molto di parallelizzazione del codice, ho sempre programmato in single thread. Ma domando: se un codice non e' parallelizzabile a livello software, perche' mai dovrebbe esserlo in hardware? Mi spiego, una serie di core diversi che lavorano sullo stesso thread possono dare conflitti a livello di program counter, a livello di coerenza di cache (che si fregherebbe completamente dopo ogni istruzione), ma specialmente a livello di pipeline, dove interdipendenze tra le istruzioni dovrebbero essere risolte a livello di 2 core: una cosa impossbile. Il tutto in somma si ridurrebbe nell'avere una sola CPU (chiaramente, visto che sullo stesso thread non ci possono essere piu' di 2 CPU!) con le unita' di esecuzione di 2 CPU che pero' non potrebbero essere sfruttate per via di quanto scritto sopra. Morale, secondo me e' una voce di corridoio a livello di pesce d'aprile... ed ha poco senso, visto che "l'ottimizzazione" viene fatta a livello di codice e non a livello di unita' di controllo. Se non si riesce a farla a livello di codice, quando un compilatore ha tempo virtualmente infinito per farlo e specialmente risorse illimitate, cosa puo' fare una control unit cablata e per giunta in pochi nanosecondi?

In realtà la cosa non è tanto infattibile (anche se complicata), si tratterebbe in pratica di condividere tutto ciò che va dal decoder in poi, per la coerenza si disabilita temporaneamente metà cache e si fa funzionare la CPU come se fosse un unico processore con la cache di un singolo core e pipeline di "larghezza" doppia. Per quanto riguarda le unità di esecuzione, le CPU odierne sono già superscalari, ossia sono in grado di eseguire più istruzioni per ciclo di clock, ad esempio gli A64 sono in grado di eseguire per quanto riguarda gli interi fino a 3 istruzioni per ciclo di clock, i Core 2 fino a 4, questo è reso possibile dall'esecuzione fuori ordine - Out OF Order Execution o OOO, e dalla rilevazione delle istruzioni indipendenti che possono quindi essere eseguite in parallelo. Ovvio che la sfruttabilità di tutte le unità non è mai ideale, ed anzi più unità ci sono e meno sono mediamente sfruttate, però non è detto nemmeno che siano inutili. Direi quindi che la notizia potrebbe essere un pesce d'aprile, ma potrebbe anche non esserlo, dato che come detto su AMD ha dei brevetti a riguardo. Dubito che i procesori attuali possano esserne capaci, se verità ce n'è forse si potrebbe vedere qualcosa di concreto solo dai K8L in poi.

:eek: ma dove? solo su sistemi in cui la sequenza di istruzioni può essere eseguita in ordine sparso!

esistono due tipi di programmi a cui si può applicare questo discorso del "Reverse HyperThreading"

1) programmi che sono stati sviluppati prima dell'avvento massiccio dei Dual/Tri/Quad/MultiCore

in questo caso questo sistema funzionerebbe, ma ancora meglio sarebbe dividere il programma in thread partendo dal codice, in modo da avere già in anticipo una stima del carico di lavoro di ogni thread e creare delle suddivisioni logicamente corrette

2) programmi che non sono stati realizzati multithreaded perché NON SI POTEVA FARE, magari perché ci sono delle sequenze di istruzioni (e capita spessissimo) che il programmatore SA di non poter dividere

in questo caso è tutto inutile, puoi avere anche 45 Core, ma se la sequenza inscindibile viene assegnato al 15°, lavorerà da solo perché così deve essere.

3) (ma non avevo detto 2? :stordita: ) programmi che si evolvono da single-thread a multithread, dove i programmatori individuano le zone parallelizzabili e ci applicano una divisione in thread, ed in questo caso il programmatore SA qual è un punto ad alta richiesta di risorse, quindi sfrutterà meglio i multicore

Di programmi non parallelizzabili a livello di codice ce ne sono parecchi, e dipende anche se e come sono parallelizabili, ad esempio se la parte parallelizzabile è quella che è eseguita il 10% del tempo i vantaggi sono relativi. Pensiamo ad un emulatore.

Di programmi non parallelizzabili a livello di codice ce ne sono parecchi, e dipende anche se e come sono parallelizabili, ad esempio se la parte parallelizzabile è quella che è eseguita il 10% del tempo i vantaggi sono relativi. Pensiamo ad un emulatore.
:boh: forse l'idea originale punta a quei tantissimi programmi "legacy" che per altrettanto tantissimi motivi non vengono sviluppati più. Pensiamo a quanti programmi di gestione di macchinari, quante ditte che hanno chiuso e che non aggiorneranno programmi, pensiamo anche solo a Windows98 che di un dual core se ne fa una cippa :asd: mentre con un dual che simula un "single" andrebbe più veloce :asd:

Ciao,

scusate signori... una CPU non funziona cosi'. Una CPU ha un'unita' di controllo che si occupa di eseguire le istruzioni del programma il sequenza. Poi i processori odierni operano scamuffi vari, come tradurle in un formato piu' omogeneo, eseguire in parallelo e fuori ordine e riordinarle solo alla fine... ma il flusso di programma e' unico. 2 processori distinti non potranno MAI eseguire lo stesso flusso, perche' si pesterebbero i piedi a vicenda e occorrerebbe una circuiteria di arbitraggio tra i due che sarebbe lenta e vanificherebbe ogni possibile incremento prestazionale che si otterrebbe... qui mi si propone di staccare cache ecc ecc... questo e' IMPROPONIBILE. L'unica soluzione sarebbe soltanto quella di avere una sola control unit e piu' unita' in parallelo. Questo pero' si puo' fare solo su un solo core, non su due core; e staccare cache non e' che sia cosi' semplice, visto che tutte le unita' di instruction fetching e di load/store degli operandi lavorano hard coded nella loro cache L1!
Continuo a sostenere che sia fantainformatica... poi puo' darsi che venga smentito...

Ciao,

scusate signori... una CPU non funziona cosi'. Una CPU ha un'unita' di controllo che si occupa di eseguire le istruzioni del programma il sequenza. Poi i processori odierni operano scamuffi vari, come tradurle in un formato piu' omogeneo, eseguire in parallelo e fuori ordine e riordinarle solo alla fine... ma il flusso di programma e' unico. 2 processori distinti non potranno MAI eseguire lo stesso flusso, perche' si pesterebbero i piedi a vicenda e occorrerebbe una circuiteria di arbitraggio tra i due che sarebbe lenta e vanificherebbe ogni possibile incremento prestazionale che si otterrebbe... qui mi si propone di staccare cache ecc ecc... questo e' IMPROPONIBILE. L'unica soluzione sarebbe soltanto quella di avere una sola control unit e piu' unita' in parallelo. Questo pero' si puo' fare solo su un solo core, non su due core; e staccare cache non e' che sia cosi' semplice, visto che tutte le unita' di instruction fetching e di load/store degli operandi lavorano hard coded nella loro cache L1!
Continuo a sostenere che sia fantainformatica... poi puo' darsi che venga smentito...

Nessuno sta dicendo che due core eseguano lo stesso flusso, ma che in determinate condizioni si possa riconfigurare la CPU per lavorare come un solo core con il doppio delle unità di esecuzione (ma non il doppio delle capacità). Infatti, avere una sola cache attiva, control unit, magari un solo set di registri e un solo decoder/fetcher, ma con la possibilità di utilizzare le unità di esecuzione dell'altro core, anche se magari con efficienza ridotta. Con una CPU attuale è impossibile, ma bisogna vedere se è impossibile con un'adeguata logica di controllo e di interconnessione.
E notare che non sto dicendo che questa notizia sia vera o meno, ma semplicemente che la cosa potrebbe essere fattibile e che ci sono dei brevetti di AMD al riguardo. Potrebbero essere comunque soltanto rumors sparsi in giro allo scopo di stornare l'attenzione da Conroe ;)

Nessuno sta dicendo che due core eseguano lo stesso flusso, ma che in determinate condizioni si possa riconfigurare la CPU per lavorare come un solo core con il doppio delle unità di esecuzione (ma non il doppio delle capacità).
Infatti, resta tuttavia il fatto che (secondo me) sia mooooooolto più semplice "prevedere" l'indipendenza di un flusso di istruzioni partendo dal codice sorgente e soprattutto sapendo COSA FA tale codice. Una simile previsione su un codice macchina, magari con frequenti interruzioni dovute a istruzioni dipendenti fra loro la vedo ardua :stordita:

Infatti, resta tuttavia il fatto che (secondo me) sia mooooooolto più semplice "prevedere" l'indipendenza di un flusso di istruzioni partendo dal codice sorgente e soprattutto sapendo COSA FA tale codice. Una simile previsione su un codice macchina, magari con frequenti interruzioni dovute a istruzioni dipendenti fra loro la vedo ardua :stordita:

Il problema è che il codice può essere facilmente parallelizzato a livello di thread, ma cosa si fa quando un thread è non parallelizzabile e molto esoso in termini di risorse? Parallelizzare a livello di singole istruzioni è molto complicato a livello di codice, e se ci sono problemi ad avere interruzioni per istruzioni dipendenti in un singolo core, figurati che succede quando un'istruzione dipende da un'altra da eseguire su un altro core ;) Ovviamente si cerca di non avere mai questa situazione, tuttavia alcuni tipi di codice non sono facilmente parallelizzabili e punto. In quel caso avere un "singolo core" di capacità superiore è più utile rispetto ad avere due core separati di capacità inferiore, seppure non di tantissimo.

in verita', gia' dalla revisione tecnica del K8L, si era detto che la caches L3 di questi multiprocessori (perche' e' diverso parlare di dual e multi, come potranno confermare in molti), permetterebbe effettivamente di utilizzare l'esecuzione virtuale in monothead.

in fondo gia' oggi ci sono piu' pipeline nei single core, fare vedere piu' core come unico non dovrebbe essere molto difficile con l'architettura con L3 condivisa, anzi, e' proprio questo il vantaggio:
in modulo multicore ogni singolo core ha la sua L1 e L2, ed accede alla L3 per bufferizzare le pagine d'immediato prossimo utilizzo invece che spedirle in ram;
in modulo virtuale monoprocessore le L1 e L2 vengono disabilitate, e la L3 viene divisa in L2 unica e L1 grande x4 (per via degli indirizzi di esecuzione), ed una dato prefect engine si occupa di gestire le varie pipeline dei vari core indistintamente, come prima si occupava di gestire le diverse pipeline del singolo core.
con l'architettura odierna sarebbe poco praticabile, in quanto la caches L2/L1 di un core dev'essere disabilitata ed accedere per bus esterno a quella dell'altro core, introducendo latenze che sommate ridurrebbero di molto la velocita'; un dual cosi' fatto, oltre a richiedere comunque una nuova revisione di maschera per gli adattamenti, non sarebbe tanto piu' veloce di un mono di pari frequenza, anzi, non toccherebbe nemmeno l'usuale 50% in piu' dei normali sistemi dual processor (un core non ha caches!), e se bisogna rifarlo, allora conviene la L3 condivisa ed un quad...
quindi crredo che sul K8 odierno non verra' mai preso in considerazione.

Il problema è che il codice può essere facilmente parallelizzato a livello di thread, ma cosa si fa quando un thread è non parallelizzabile e molto esoso in termini di risorse? Parallelizzare a livello di singole istruzioni è molto complicato a livello di codice, e se ci sono problemi ad avere interruzioni per istruzioni dipendenti in un singolo core, figurati che succede quando un'istruzione dipende da un'altra da eseguire su un altro core ;) Ovviamente si cerca di non avere mai questa situazione, tuttavia alcuni tipi di codice non sono facilmente parallelizzabili e punto. In quel caso avere un "singolo core" di capacità superiore è più utile rispetto ad avere due core separati di capacità inferiore, seppure non di tantissimo.
Morale della favola: tecnologia poco utile :asd: visto lo stato attuale delle cose

Morale della favola: tecnologia poco utile :asd: visto lo stato attuale delle cose

Non ho detto questo, tutto dipende se e come dovrebbe essere implementata.

in verita', gia' dalla revisione tecnica del K8L, si era detto che la caches L3 di questi multiprocessori (perche' e' diverso parlare di dual e multi, come potranno confermare in molti), permetterebbe effettivamente di utilizzare l'esecuzione virtuale in monothead.

in fondo gia' oggi ci sono piu' pipeline nei single core, fare vedere piu' core come unico non dovrebbe essere molto difficile con l'architettura con L3 condivisa, anzi, e' proprio questo il vantaggio:
in modulo multicore ogni singolo core ha la sua L1 e L2, ed accede alla L3 per bufferizzare le pagine d'immediato prossimo utilizzo invece che spedirle in ram;
in modulo virtuale monoprocessore le L1 e L2 vengono disabilitate, e la L3 viene divisa in L2 unica e L1 grande x4 (per via degli indirizzi di esecuzione), ed una dato prefect engine si occupa di gestire le varie pipeline dei vari core indistintamente, come prima si occupava di gestire le diverse pipeline del singolo core.
con l'architettura odierna sarebbe poco praticabile, in quanto la caches L2/L1 di un core dev'essere disabilitata ed accedere per bus esterno a quella dell'altro core, introducendo latenze che sommate ridurrebbero di molto la velocita'; un dual cosi' fatto, oltre a richiedere comunque una nuova revisione di maschera per gli adattamenti, non sarebbe tanto piu' veloce di un mono di pari frequenza, anzi, non toccherebbe nemmeno l'usuale 50% in piu' dei normali sistemi dual processor (un core non ha caches!), e se bisogna rifarlo, allora conviene la L3 condivisa ed un quad...
quindi crredo che sul K8 odierno non verra' mai preso in considerazione.


In verità pensavo che si potessero usare solo le cache l1 e l2 del primo core (in dual core) e il suo decoder/fetcher, mentre le pipeline e le unità di esecuzione verrebero messe a disposizione dal secondo al primo core.

Di grazia, vi sembra semplice legare le sole unita' di esecuzione presenti su un core con quelle presenti in un altro e con le unita' di controllo del flusso out of order di un altro ancora? Io onestamente non saprei come fare...

Di grazia, vi sembra semplice legare le sole unita' di esecuzione presenti su un core con quelle presenti in un altro e con le unita' di controllo del flusso out of order di un altro ancora? Io onestamente non saprei come fare...

Veramente io parlavo di soli 2 core (e su un quad core potrebebro essere accoppiati 2 a 2) ma comunque nessuno sta dicendo che sia semplice ;) Per me è complicato anche avere una logica efficiente per gestire una cache unificata, ad esempio, ciò non toglie che sia stata realizzata.
In pratica neppure io saprei come costruire una CPU, dal punto di vista logico ovviamente bisognerebbe fare in modo che le unità di controllo di un core possano accedere alle unità di esecuzione dell'altro: è altrettanto ovvio che questa non è una cosa banale, ma dire "non è possibile farlo funzionare" mi sembra un pò limitativo.
Semmai il problema IMHO è ancora un altro: non tanto la fattibilità tecnica, quanto quella economica. Se una siffatta soluzione, come è probabile, portasse solo un modesto incremento prestazionale a fronte di un notevole incremento della complessità cpstruttiva, non sarebbe certo opportuno adottarla.

comunque ho trovato questo:

http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=6574725.PN.&OS=PN/6574725&RS=PN/6574725
Qui si parla di migliorare l'efficienza dei sistemi dual core mediante una estrazione del livello di parallelismo a livello di gruppi di istruzioni (si parla di "threads of instructions" ma sarebbe meglio dire "streams of instructions") e tramite esecuzione speculativa, del tutto trasparente al SO. Non è il reverse hyperthreading, anzi sembra essere un "hyperthreading al quadrato".

ripeto: può essere benissimo tutto fumo, però come ipotetica possibilità sarebbe molto interessante.

Ciao,

io ho progettato diverse CPU nella mia vita. Tutta roba semplice chiaramente, ma ad ogni modo so progettare una CPU. Quella di realizzare una circuiteria di arbitraggio per condividere unita' di esecuzione tra i 2core la vedo dura. Non e' infattibile, ma sono quasi certo che il gioco non valga la candela. L'unica cosa che si potrebbe fare e' un terzo core dotato di sole unita' di controllo e che prende il posto della CU dei due core principali; questo core fa lo scheduling e alloca risorse agli altri due. Certo neppure qui e' facile, ma la vedo come unica possibilita'.
Per quanto riguarda il parallelismo a livello di istruzione, e' in sostanza quanto sta alla base di IA64; il problema e' avere buoni compilatori in questo campo per poterlo sfruttare. Ma anche qui, e' conveniente avere un singolo core con tante unita' di esecuzione rispetto che piu' core separati.

beh, IA-64 fa qualcosa di diverso: in pratica toglie quasi tutta la logica di gestione delle predizioni, dipendenze, ecc. dalla CPU e trasferisce i suoi compiti al compilatore, che diventa responsabile di trovare dipendenze, parallelismi e quant'altro, per poi creare le "macroistruzioni" IA-64 da mandare alla CPU, ed di ordinare l'esecuzione speculativa. Tuttavia creare questi compilatori è stato tutt'altro che facile e mi pare opinione comune che uno dei motivi per cui l'architettura IA-64 ha avuto problemi è stato proprio nello sviluppo e nell'ottimizzazione di questi software.

Qui si parlerebbe ad esempio di permettere l'esecuzione speculativa dei due casi di una istruzione di fork ognuno su di un core e quindi ad aumentare l'efficienza su un thread singolo in maniera trasparente al SO e al compilatore, immagino sia complicato e non è detto che sia economicamente fattibile.

Per quanto riguarda il parallelismo a livello di istruzione, e' in sostanza quanto sta alla base di IA64; il problema e' avere buoni compilatori in questo campo per poterlo sfruttare. Ma anche qui, e' conveniente avere un singolo core con tante unita' di esecuzione rispetto che piu' core separati.
Mi hai rubato le parole di bocca (ladro! Ridammele! :) )
Stavo giusto per dire che, più che arrovellarsi ad "ingannare" il software in modi sempre più sofisticati ottenendo guadagni sempre minori, forse l'unico approccio valido per sfruttare un parallelismo estremo (molte pipelines) in un singolo thread è rendere esplicito il parallelismo già a livello di istruzioni macchina. Infatti, la "E" di EPIC sta proprio per "explicit". Peccato che non abbia sfondato, forse meritava una sorte migliore.