Reverse HyperThreading: solo rumors

[Redazione di Hardware Upg]

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.

[Arrex2]

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

facciamo multithreading, va...

[Paolo Corsini]

eh si, bella svista

[Rubberick]

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

[gianni1879]

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

[Cimmo]

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.

[MaxArt]

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.

[DakmorNoland]

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.

[ivabo]

inquirer = affidabilità 0%

[liviux]

Originariamente inviato da Cimmo

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

[rdefalco]

Originariamente inviato da Cimmo

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.

[leoneazzurro]

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

[Mazzulatore]

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?

[dema86]

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

[eltalpa]

Originariamente inviato da dema86

The inculer é un sito di minchioni

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

[Arrex2]

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?

[rdefalco]

Originariamente inviato da Arrex2

Ciao,
...

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.

[avware]

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.

[rdefalco]

Originariamente inviato da avware

...
In linea teorica con N core visti come un'unica cpu le prestazioni dovrebbero essere moltiplicate per N
...

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

[leoneazzurro]

Originariamente inviato da Arrex2

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.