Reverse HyperThreading: solo rumors

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

per piacere evitiamo...

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?

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.

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? ) 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

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.

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.