Reverse HyperThreading: solo rumors

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-...p;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.

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.