Reverse HyperThreading: solo rumors

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 mentre con un dual che simula un "single" andrebbe più veloce

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

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

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.

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

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

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