Un HyperThreading al contrario per AMD

[lucusta]

bjt2:
la questione e' afascinante, in quanto risolverebbe non pochi problemi sui software non parallelizzabili e soprattutto per quelli semplici per desktop (tu m'insegni che un fare un codice per 1 CPU e un conto, per 2 e' un altro e per 4 e ul'altro ancora, e sempre piu' caro in quanto a "risorse umane"), ma non gridiamo al miracolo.
una emulazione per il single core (perche' tale dovrebbe essere) portera' via riorse e un multi core non avra' certo l'efficenza di un solo core a frequenza piu' elevata su tali codici; questo significa che un codice monothread non ottimizzato risultera' sicuramente piu' veloce, ma non il doppio piu' veloce che utilizzando 1 solo core a differenza di 2.

la questione si stava snocciolando con la comparsa del transmeta (bella cpu) e del suo core software e le voci sui primi multi-core, 2-3 anni fa'; in quel caso il core software gia' doveva emulare un x86, fargli fare anche questo tipo di lavoro risultava molto facile.

i vantaggi sono sicuramente a livello di creazione di codice, in quanto e' piu' semplice crearne uno adatto ad un singolo core, dove poi il "core software" si impegnera' a riempire i core fisici, e solo in parte per codici non parallelizzabili; se il thread non e' parallelizzabile da principio, non credo che un'emulazione software riesca a smistare le richieste molto agevolmente...

e' una feature interessante, sicuramente piu' pratica che nell'avere multicore separati e magari poco sfruttabili in un ambito desktop con software "caprone".
2 core possono dividersi il compito tra' programmi di elaborazione e programmeli in background, ma averne 4: 1 per il programma non ottimizzato, 1 per i programmi in background, e gli altri due a riposo, fino a che altri programmi non richiedono potenza elaborativa?

[MaRtH]

Originariamente inviato da lucusta

bjt2:
la questione e' afascinante, in quanto risolverebbe non pochi problemi sui software non parallelizzabili e soprattutto per quelli semplici per desktop (tu m'insegni che un fare un codice per 1 CPU e un conto, per 2 e' un altro e per 4 e ul'altro ancora, e sempre piu' caro in quanto a "risorse umane"), ma non gridiamo al miracolo.
una emulazione per il single core (perche' tale dovrebbe essere) portera' via riorse e un multi core non avra' certo l'efficenza di un solo core a frequenza piu' elevata su tali codici; questo significa che un codice monothread non ottimizzato risultera' sicuramente piu' veloce, ma non il doppio piu' veloce che utilizzando 1 solo core a differenza di 2.

la questione si stava snocciolando con la comparsa del transmeta (bella cpu) e del suo core software e le voci sui primi multi-core, 2-3 anni fa'; in quel caso il core software gia' doveva emulare un x86, fargli fare anche questo tipo di lavoro risultava molto facile.

i vantaggi sono sicuramente a livello di creazione di codice, in quanto e' piu' semplice crearne uno adatto ad un singolo core, dove poi il "core software" si impegnera' a riempire i core fisici, e solo in parte per codici non parallelizzabili; se il thread non e' parallelizzabile da principio, non credo che un'emulazione software riesca a smistare le richieste molto agevolmente...

e' una feature interessante, sicuramente piu' pratica che nell'avere multicore separati e magari poco sfruttabili in un ambito desktop con software "caprone".
2 core possono dividersi il compito tra' programmi di elaborazione e programmeli in background, ma averne 4: 1 per il programma non ottimizzato, 1 per i programmi in background, e gli altri due a riposo, fino a che altri programmi non richiedono potenza elaborativa?

Straquoto

[MaRtH]

@Automator: non è affatto vero ciò che dici, non è che la programmazione si fermerà dove è adesso...
Ma non credo che i milioni di utenti, per passare al Dual-Core abbandonino qualsiasi programma fatto per il Single-Core tagliando di netto tutte le "vecchie applicazioni"...

Io la vedo così...

Per il resto pare davvero una bella tecnologia, quando non si ha bisogno di + core, questi si uniscono e ne diventano uno superpotente...

Ottimo...

Ciao

[leptone]

OT-start:
il plurale di core è cores?
OT-end

IMHO dipende da cosa uno ci deve fare, se io ho (in un ipotetico futuro) un quad-core e sto usando un editor di testo (M$-word,OO-Writer,Abiword(che uso sempre quando non devo fare cose complesse,È UNA SCHEGGIA),ecc..) a me fa comodo che gli altri 3 cores stiano fermi per risparmiare corrente elettrica e quindi anche per diminuire la temperatura(in alcuni casi anche far calare il rumore della ventola). Secondome le tecnologie come cool'n'Quite e simili devono essere super ottimizzate, ma in futuro si dovrebbero anche poter configurare(con GNU/Linux qualcosina la si può fare) in base alle propie esigenze.
A me dispiacerebbe che gli altri core non vengono usati solo se utilizzandoli si avrebbero prestazioni superiori (quindi fino a che un core non si satura)anche con applicazioni banali o con tutti i processi in background del O.S.(io carico molte cose in background).

L'importante IMHO è che la potenza venga sfoderata solo quando serve, altrimenti in ambito soho i processori come il sempron sarebbero(64 bit cool'n'quiet), o pentium M insuperabili.

Ragazzi non so nulla in proposito, ma quando si fa un cluster linux le applicazioni mono-processore e single-thread dovrebbero essere processate da più calcolatori vero???
In questi casi il kernel, il sistema, le librerie ecc... sono compilate sicuramente per multi-cpu e multi-thread, ma le applicazioni finali sono anchese compilate per multi-cpu e multi-thread dalla distribuzione o dalla softwarehouse(vedi mathlab, mathematica , e altri software ingegneristici che ci sono per le workstation in tutti i sistemi UNIX(BSD,HP-UX, IBM AIX,XGI,SUN-OS,SOLARIS,NOVELL, eccc...))?
Personalmente nè ho visto uno dei ricercatori di biologia del campus che frequento, che 4 anni fa hanno comperato 4 AMD 2400+ che utilizzano con lo stesso software che utilizzavano su una workstation monoprocessore(i soldi sono pochi), ottenendo aumenti prestazionali mai inferiori a 3x con 4 processori. Come funzionano i Cluster???? Non pretendo risposte, ma almeno qualche link. Grazie in anticipo.

Comunque credo che questa tecnologia sarà utile in determinati ambiti, l'importante e poter decidere e poterla disattivare addiruttura se non serve, anche se non si può dir nulla finchè non viene fuori.

Ciao e usate il forum diligentemente e cercate di limitare i commenti inutili.....

[JOHNNYMETA]

Originariamente inviato da Nippolandia

Parole sante.....

Ma non dimentichiamo che potrebbe essere poco funzionale,ma da quello che ho visto se Amd implementa una nuova tecnologia lo fa per i suoi clienti non come mossa commerciale cosa che mi potrei aspettare da Intel(anche se ultimamente stia migliorando verso soluzioni vere e non sul piano commerciale)
Fate come me ragazui siate neutrali e non dei fanboy.

Sei neutrale anche dove non si deve essere.
Qui fanboy non centra proprio niente e nessuno è meno fanboy di me.
Non facciamo i bambini.
Oggettivamente questa tecnologia è un'evoluzione perchè non fa altro che aggiungere vantaggi.Aggiunge la potenza di più processori anche quando il software non vede o non prevede più CPU e non toglie nulla di quello che c'è gia.

[isd88]

tutte le invenzioni dell'industria sono trovate commerciali, nulla è a favore dell utente e basta

[Sawato Onizuka]

Originariamente inviato da JOHNNYMETA

Aggiunge la potenza di più processori anche quando il software non vede o non prevede più CPU e non toglie nulla di quello che c'è gia.

ma secondo la news ciò dovrebbe avvenire a livello "logico" come un HT al contrario o no ?
x forza che dopo questa news si comincia a sparare a zero, cm al solito, sui programmatori [di giochi in primis, ndr] visti titoli recenti non proprio ottimizzati decentemente ricordate anche che la progettazione/sviluppo/programmazione è un lavoro stressante e vincolato da quelle schifose date chiamate SCADENZE che fanno a capo al reparto amministrativo & marketing del distributore cui si rivolge la software house [nel caso più banale, ora nn stiamo a fare tutte le ipotesi] quindi a gente che NON ha idea di cosa significhi tale lavoro nè tantomeno le ripercussioni sulle vendite (vedi Ubisoft + Starforce e dietrofront successivo)

[Kayne]

tutte le invenzioni dell'industria sono trovate commerciali, nulla è a favore dell utente e basta

si grazie, ma cè una differenza SOSTANZIALE tra guadagnare + soldi vendendo un prodotto tecnologicamente "avanzato" e/o prestante e/o conveniente ecc, e tra guadagnarne dicendo alla gente che può navigare + veloce in internet col P4 o che 16+16 = 32 bit (come ai tempi del Sega Megadrive) ecc...

Originariamente inviato da Automator

invece di spingere a programmare bene, si spinge a programamre con i piedi.... o meglio, si lascian le cose come stanno... mah... me pare na strunzata

Non è sempre una questione di programmare bene o male... non tutti gli algoritmi sono parallelizzabili.

[Automator]

Originariamente inviato da MaRtH

@Automator: non è affatto vero ciò che dici, non è che la programmazione si fermerà dove è adesso...
Ma non credo che i milioni di utenti, per passare al Dual-Core abbandonino qualsiasi programma fatto per il Single-Core tagliando di netto tutte le "vecchie applicazioni"...

Io la vedo così...

Per il resto pare davvero una bella tecnologia, quando non si ha bisogno di + core, questi si uniscono e ne diventano uno superpotente...

Ottimo...

Ciao

Scusa ma c'è una falla nel tuo ragionamento....
Se non ti servono + core per una data appz, e dunque questa non è molto intensiva, a che ti serve una cpu superpotente????
Sta cosa serve solo per mettere una pezza a una programmazione fatta cosi e cosi.... che ottimizzo a fare? tanto!

[liviux]

Io sono un po' scettico sul fatto che questa tecnologia possa essere del tutto trasparente al software, e quindi possa essere utile per accelerare applicazioni legacy single-thread. Sarebbe una sorta di Santo Graal informatico al quale finora nulla fa pensare di essere vicini. In qualunque modo possa avvenire la ripartizione di risorse fra i vari core, "prestando" pipelines e ALU da un core all'altro in base al carico di lavoro, ci sono nei dati e negli algoritmi delle dipendenze ineludibili che in certi casi impediscono la parallelizzazione, anche a livello di un singolo core superscalare. La cosa potrebbe essere fattibile se si passasse ad un paradigma (scusate la parolaccia) di programmazione del tutto nuovo, non lineare. Con buona pace di Von Neumann e della compatibilità col vecchio software.

[bjt2]

Ma io credo che sia possibile una cosa che dissi qualche giorno fa, in un thread di schede grafice, augurandomi che qualcuno pensi di fare una GPU con microcontrolli per implementare una o più CPU. Mettendo da parte la parte GPU, il concetto è questo: ho n ALU, n FPU, n unità di LOAD e STORE. Ho m decoder e branch predictors, che implementano m CPU logiche (m potrebbe anche essere 1 nelle CPU di fascia bassa, ma mi aspetto sia almeno 2). Gli m threads si contendono le n unità disponibili. Se c'è un thread che richiede molta FPU, una molta ALU ed una molta memoria, capirete che questo porterà ad un maggiore sfruttamento. E' più un HT al cubo che una contrazione dell'HT, anche se credo che la cache L1 ed L2 sia meglio condivisa... Poi a livello di marketing si può dire che è il contrario dell'HT, am credo che una soluzione simile sia la più semplice la più economica, la più efficiente, la più facile da progettare e quella che da il massimo delle prestazioni sopratutto sulle applicazioni legacy monothread, spremendo al massimo il parallelismo (se si mette una finestra di istruzioni sufficientemente larga)...

[fek]

Originariamente inviato da Cionno

... manco la smettono di pensare alla velocità, i programmatori dovrebbero metterew i piedi per terra e sviluppare ambienti ad altissimo rendimento come motori grafici e programmi a struttura ottimizzata... è come per le schede video... che importa ai programmatori che il motore grafico è poesante... tanto ci sono i quad processor le DDR6 e 4 geforce 9900Pro in SLI...

#$#$%#$%^@#$%^@$%^@$^@$@$%^@ *censored* !!!

[Rubberick]

secondo me occorre fare un sistema dinamico che passi dall'usare x fisici a 1 logico somma degli altri e cosi' via... pero' trovare una via giusta per la programmazione che nn si capisce + nulla

[jappilas]

Originariamente inviato da leptone

OT-start:
il plurale di core è cores?
OT-end
IMHO dipende da cosa uno ci deve fare, se io ho (in un ipotetico futuro) un quad-core e sto usando un editor di testo (M$-word,OO-Writer,Abiword(che uso sempre quando non devo fare cose complesse,È UNA SCHEGGIA),ecc..)

su un kernel con supporto SMP processi separati vengono gia' assegnati a cpu o core diversi, anche se poi si tratta di processi a bassa time slice

a me fa comodo che gli altri 3 cores stiano fermi per risparmiare corrente elettrica e quindi anche per diminuire la temperatura(in alcuni casi anche far calare il rumore della ventola). Secondome le tecnologie come cool'n'Quite e simili devono essere super ottimizzate, ma in futuro si dovrebbero anche poter configurare(con GNU/Linux qualcosina la si può fare) in base alle propie esigenze.
A me dispiacerebbe che gli altri core non vengono usati solo se utilizzandoli si avrebbero prestazioni superiori (quindi fino a che un core non si satura)anche con applicazioni banali o con tutti i processi in background del O.S.(io carico molte cose in background).

e' che sui server si cerca e auspica il bilanciamento del carico (quindi far lavorare tutte le cpu) , per cui i kernel finora adottano la policy di schedulazione che a te appare "sprecona": ma si tratta appounto di una policy, non dovrebbe volerci molto per cui quello che desideri venga implementato (anche se credo che, se il sistema dovesse aspettare di arrivare al 100% del primo core per iniziare ad allocare processi sui restanti, si otterrebbe una perdita di "responsiveness", reattivita' nell' uso)

Ragazzi non so nulla in proposito, ma quando si fa un cluster linux le applicazioni mono-processore e single-thread dovrebbero essere processate da più calcolatori vero???

al contrario
il clustering e' conveniente quando il SW da eseguire, scala con il numero di processori, e questo accade quando si possono creare processi o thread di esecuzione indipendenti, di cui il kernel dell' OS effettua il dispatch su un nodo del cluster
nella situazione ideale, si produce un aumento prestazionale lineare con il numero di nodi

n questi casi il kernel, il sistema, le librerie ecc... sono compilate sicuramente per multi-cpu e multi-thread, ma le applicazioni finali sono anchese compilate per multi-cpu e multi-thread dalla distribuzione o dalla softwarehouse

non e' solo questione di "compilate", il problema e' soprattutto far si' che l' algoritmo di risoluzione ad un dato problema, sia al proprio interno parallelizzabile
una volta modellato il problema, si deve anche scrivere il programma in modo che crei e sincronizzi thread multipli, chiamando nel modo giusto le funzioni della thread library adottata (e' da tenere presente che il threading model varia con la libreria di appoggio e con la piattaforma target scelta - e che, per dire, in alcuni casi il threading e' effettuato in modo indipendente dal kernel, quindi senza possibilita' di dispatching su cpu fisiche/logiche -"core"- diversi)

Come funzionano i Cluster???? Non pretendo risposte, ma almeno qualche link. Grazie in anticipo.

http://www.mosix.org/
http://www.kerrighed.org/

Originariamente inviato da fek

#$#$%#$%^@#$%^@$%^@$^@$@$%^@ *censored* !!!

non te la prendere...
non tutti sanno quello che comporta sviluppare giochi...
chi non e' addetto ai lavori non percepisce bene gli sforzi, il design e il tweaking che servono per far si' che un' unica code base per la piattaforma "PC" funzioni al meglio su hardware uscito ieri e al tempo stesso sia godibile su quello di tre anni fa...

[Mr. X]

Ottima idea!

[xeal]

Ragazzi non facciamo sempre tanto casino e tanta confusione (per qualcosa che comunque bisognarà valutare sul campo).

E' stato detto (e ridetto, e ridetto, e ridetto...) che non tutto il software è parallelizzabile, e che il passaggio al multicore non implica necessariamente un miglioramento per tutto il software a patto che questo venga programmato apposta, cioè bene, e che se questo non succede allora vuol dire che il programmatore è brutto e cattivo e incapace e merita la forca.

Alcuni algoritmi non sono parallelizzabili perchè semplicemente... non lo sono, prima di poter fare una certa operazione occorre farne un'altra e prima di questa un'altra ancora. Oppure la parallelizzazione è molto complessa, ma una cosa molto complessa richiede molto tempo per essere realizzata, e molto tempo richiede molto denaro... e se poi le cose non funzionano o non funzionano bene o non ci sono vantaggi rispetto alla versione single thread? E se ricercare il parallelismo spinto fosse così complicato da non consentire una previsione valida sui vantaggi finali, e quando finalmente ci sei riuscito ti accorgi che hai buttato al vento tempo e denaro e ti cadono le braccia? Allora, forse, parallelizzare non sempre è cosa buona e giusta...

Estremizzando, si potrebbe pensare che anche il parallelismo realizzato per mezzo delle architetture superscalari e delle unità di esecuzione "fuori ordine" è una pezza hardware ad un problema software legato all'incompetenza del programmatore: se ci riesce il processore, che non conosce l'algoritmo nel suo complesso, ma solo quelle poche istruzioni che sta elaborando, a maggior ragione dovrebbe riuscirci il programmatore, e se non lo fa vuol dire che è pigro e programma con i piedi, giusto? Assolutamente NO! E perchè? Perchè intanto lavorare al livello delle singole istruzioni vorrebbe dire programmare in assembly e aumentare la difficoltà, aumentare i tempi, aumentare il rischio di commettere errori e introdurre bug -> sicuramente meglio lasciar fare al compilatore quello che può, con un approccio generico e affidarsi alla capacità del processore di riarrangiare l'ordine d'esecuzione dinamicamente, per adeguarlo alla situazione contingente delle risorse, che solo lui conosce: è più semplice, costa meno, funziona meglio. Poi perchè, a qualunque livello si lavori, c'è comunque la possibilità che il guadagno ottenuto con la parallelizzazione sia marginale, tanto da essere ininfluente o addirittura controproducente a causa dell'orpello che sta attorno alle operazioni da svolgere in parallelo: perchè comunque bisogna impiegare tempo (della macchina) e risorse (idem) per gestire la condivisione dei dati tra i vari thread, per la sincronizzazione, e per il context switch fra un thread e l'altro, di uno stesso processo e non, cosa che, comunque, richiede del tempo -> potrebbe essere preferibile accorpare le operazioni indipendenti in un unico thread/processo eseguito in maniera fluida e veloce da un solo core; inoltre, bisogna ricordare che in generale vale una specie di "regola" empirica per la quale grossomodo il 10% del codice viene eseguito per il 90% del tempo: ergo, ho speso tempo per realizzare una bella applicazione con tanti thread che vanno tanto veloci con tanti processori, e poi mi accorgo che uno di questi thread, un po' più grosso degli altri (perchè non sono riuscito a suddividere ulteriormente le operazioni), o addirittura grande quanto gli altri se non meno, impegna al massimo la cpu per molte time slice, mentre gli altri vengono eseguiti in un tempo del tutto trascurabile, tanto che potrei ridurne il numero, accorpandoli, o evitare del tutto di creare più di un thread, perchè vado solo a disturbare i processi in esecuzione sugli altri core senza che la mia applicazione ne tragga alcun vantaggio -> è stato tutto inutile....

[leptone]

jappilas grazie per le risposte e i link

[Mighty83]

Originariamente inviato da jappilas

non te la prendere...
non tutti sanno quello che comporta sviluppare giochi...
chi non e' addetto ai lavori non percepisce bene gli sforzi, il design e il tweaking che servono per far si' che un' unica code base per la piattaforma "PC" funzioni al meglio su hardware uscito ieri e al tempo stesso sia godibile su quello di tre anni fa...

In questo ti do ragione ma non puoi negare che negli ultimi tempi c'è stata molto meno ottimizzazione rispetto al passato...

(e me ne accorgo di quanto sia difficile programmare bene )

[isd88]

ma alla fine non è un processore super-superscalare?!?!?! cioè: un algoritmo interno suddivide le istruzioni per i 2 o piu core , e dentro ogni core un altro algoritmo li suddivide per le varie unità elaborative...non si fa prima ad aumentare le unità?