Un HyperThreading al contrario per AMD

[Mietzsche]

Originariamente inviato da Max Power

In qualunque caso L'HT ce lo verdrei bene su proci "MONCHI" come il Celly o il Sempry

L'HT non è altro che una roba per recuperare un po' dell'efficienza persa dalle pipeline kilometriche dei p4 (Netburst), poi l'effetto di aumentare la responsività del sistema è dovuta al fatto che l'attuale implementazione dello scheduling dei processi fa piuttosto schifo, mentre già negli AMD ho notato essere molto meglio anche coi single core (dal 64 e derivati in poi), detto ciò riterrei assolutamente inutile una cosa tipo HT su processori dalle pipe corte come gli AMD64 o i nuovi Intel CoreDuo e figli.

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

[*Pegasus-DVD*]

AMD ... sempre avanti

[viscm]

Nessuno ha provato a guardare un po piu' in la del suo naso?

Immaginatevi i prossimi quadri-core,nel 90% dei casi almeno uno se non due core staranno x il 99% del tempo a girarsi i pollici.
Con questa tecnologia avremmo ,perlomeno, uno 'spreco' di risorse piu' limitato.

[gropiuz73]

mah a me sembra una soluzione quale fu l'agp tanto tempo fa...
lo si fece per risparmiare sulla ram video proprio quando i prezzi stavano lì lì per crollare...

adesso uscirà sta sorta di "multi-core-non-multi-processo" e vedrai che tutti i software diventeranno inevitabilmente multi processo...

(cmq i programmi multi-proc. ci sono e sono tanti: 3dsmax, photoshop, maya, cinema4d, blender, softimage xsi e tanti altri...)
insomma dove serve il multi proc. è già implementato, ed anche bene... certo se poi uno vuole word o I.E. che gira a 4 core....

in ogni modo penso che i detrattori del multi core non l'abbiano in realtà mai usato... e checchè ne dicano anche i videogiochi indirettamente se ne avvantaggiano alla grande... per esempio il mio x2 4200 renderizza una scena 3d per 4 ore, mentre io gioco in rete a battlefield2 iperfluido... insomma un core solo per il rendering e l'altro solo per bf2...

[MiKeLezZ]

Originariamente inviato da Para Noir

Grande amd come al solito :rullezza:

Originariamente inviato da *Pegasus-DVD*

AMD ... sempre avanti

Grandi fanboys!!! C'avete la lingua a semiconduttore per sleccazzare meglio AMD.
Almeno vi pagasse.
Secondo quanto pubblicato dal sito x86-secret, tale approccio sarebbe attualmente allo studio anche da parte di Intel, per essere implementato in future architetture di processore.

Originariamente inviato da Mietzsche

L'HT non è altro che una roba per recuperare un po' dell'efficienza persa dalle pipeline kilometriche dei p4 (Netburst), poi l'effetto di aumentare la responsività del sistema è dovuta al fatto che l'attuale implementazione dello scheduling dei processi fa piuttosto schifo, mentre già negli AMD ho notato essere molto meglio anche coi single core (dal 64 e derivati in poi), detto ciò riterrei assolutamente inutile una cosa tipo HT su processori dalle pipe corte come gli AMD64 o i nuovi Intel CoreDuo e figli.

La disparità di trattamento che professi mi sembra fuori dal mondo.
Al massimo posson sembrare più reattivi per la bassa latenza di RAM e i bassi stadi di pipeline, ma i limiti del Single Core ci sono tutti nessuno escluso.

[OverClocK79®]

cerchiamo di mantenere toni più tecnici e attinenti che non da stadio....

sinceramente l'idea è buona, ma su post K8 quando ormai quasi tutte le applicazioni saranno sviluppate per multi-core non so quanto possa serve....
OK che ci sono giochi vecchi o applicazioni datate che magari potrebbero sfruttare questa implementazione ma allora la potenza di un singolo core magari sarà comunque sufficiente a far girare tale applicazione.....
almeno IMHO
poi è da vedere come verrà gestita questa cosa....se via HW, se via soft etc etc

BYEZZZZZZZZZZ

[sari]

... non riesco a capire perchè si parla a sproposito. Ritenete che offrire ai programmatori un modo per sfruttare i multi-core senza dover realizzare programmazione parallela sia un passo indietro? Probabilmente non è semplice capire un punto fondamentale : La programmazione parallela è complessa e attualmente nemmeno le grandi software house (software house governative o simil-NASA, con esigenze molto "importanti") sono in grado di realizzare due thread con la certezza che siano "perfetti per operare in parallelo tra loro"... Ora, se loro fanno fatica adirittura a creare semplice codice di debug che offra un buon grado di sicurezza, io che devo fare? AMD o Intel potrebbero offrirmi un ottimo compromesso. Inoltre, i multi-core in futuro potrebbero offrire core adibiti a funzioni specifiche, stile GPU... Detto ciò, sparare a zero su una soluzione "alternativa" come quella che si sta cercando di trovare nei laboratori AMD o Intel mi sembra alquanto fuoriluogo.

[magilvia]

sono abbastanza scettico..
mi sembra un po' un rattoppo che va all'indietro anzichè avanti!

non mi sembra un passo in avanti....ma un pararsi il **** di fronte alle applicazioni pigre che non accettano di spostarsi al multitasking...

che importa ai programmatori che il motore grafico è poesante... tanto ci sono i quad processor le DDR6 e 4 geforce 9900Pro in SLI...

Non capisco come si fa a sparare a zero sui programmatori e sul single tasking senza un minimo di esperienza di programmazione.
Semplicemente per alcune applicazioni non è possibile programmare in multitasking, mentre per altre si hanno solo incrementi marginali!
Una innovazione come questa porterebbe tutti i vantaggi dei dual core con in più un boost nel single core. Dire che è un passo indietro è come dire chenesò, che l'ABS nelle macchine è peggio perchè bisogna imparare a fare frenate controllate..

[Kayne]

IMHO ci saranno ancora molte applicazioni che potrebbero girare meglio con questa "virtualizzazione" di core (alla buona dovrebbe risultare un po come raddoppiare le ALU della CPU et similia) che non riprogrammandole multithread.
Ne so pochissimo, ma programmare MT un sw che non sia un "semplice" rendering ripartito (come tutti i sw citati da gropiuz ) non mi pare cosa semplice, ma soprattutto non è detto che porti GROSSI incrementi in TUTTI i casi....dovrebbe essere questione di come quel dato sw/gioco deve gestirsi le code i semafori e quelle cose li
Un buon esempio di multithreading è sicuramente un gioco ke addebita al secondo core il solo calcolo della fisica, ma anche qui credo dipenda molto dalle situazioni riuscire ad avere un boost superiore ad una CPU "raddoppiata", e vanno considerate ache le routine ed i cicli "sprecati" x mettere d'accordo i 2 thread.
....poi ovviamente ci devono ancora dire se questa cosa la faranno, COME la faranno, e soprattutto quento bene funzionerà

[eta_beta]

la cosa che non dicono e se sarà implementata nel micro codice del processore o se si creerà una unita logica di controllo delle cpu tipo un direttore di orchestra
spero che smembreranno i due processori e accorpando le unità di previsione dei salti ,assemblatori e disassemblatori e la memoria l2
cosi da ottimizzare il micro codice delle due cpu

[YYD]

Aspetterei di vedere all'opera tale tecnologia prima di esaltarla o bocciarla a priori, cmq se cerca di rimediare in hardware a quella che è una evidente carenza software perchè no?
Suggerisco cmq di evitare commenti senza costrutto come "grande xxx e figa yyy" che non aggiungono lustro a xxx e yyy ma scatenano le reazioni spesso "ineleganti" degli Ultras di altre marche ( esistono ahimè esistono! ) che vedono in queste espressioni di entusiasmo delle autentiche offese e provocazioni col rischio di trasformare il forum nel Colosseo al tempo di Tito ( Flavio Vespasiano ) .

[Superboy]

Originariamente inviato da eta_beta

spero che smembreranno i due processori e accorpando le unità di previsione dei salti ,assemblatori e disassemblatori e la memoria l2
cosi da ottimizzare il micro codice delle due cpu

Ehm... scusa sai ma nn hai appena inventato la cpu superscalare? ^^
quello che vorresti fare tu è aggiungere pipeline di exe, ma questo limite è gia stato raggiunto da tempo.

X Mietzsche
Lo "scheduling" dei processi guarda che non è un folletto hw, ma codice del sistema operativo...

[jappilas]

Originariamente inviato da OverClocK79®

sinceramente l'idea è buona, ma su post K8 quando ormai quasi tutte le applicazioni saranno sviluppate per multi-core non so quanto possa serve....
OK che ci sono giochi vecchi o applicazioni datate che magari potrebbero sfruttare questa implementazione ma allora la potenza di un singolo core magari sarà comunque sufficiente a far girare tale applicazione.....
almeno IMHO
poi è da vedere come verrà gestita questa cosa....se via HW, se via soft etc etc
BYEZZZZZZZZZZ

Mi fa ricordare una cosa: quello che e' uscito sul mercato come K8 e' essenzialmente un athlon perfezionato, "tweaked", e integrato con il memory controller, il sistema NUMA e le porte hyper transport... ma a meta' del suo sviluppo, il processore "Hammer" sembrava destinato a concretizzarsi come qualcosa di molto piu' sofisticato
tra le caratteristice che avrebbe dovuto avere vi sarebbe stata una "condivisione" tra core diversi, delle unita' dello stadio di esecuzione: questo avrebbe realizzato un forma di bilanciamento di carico a livello HW, ed evitati i casi in cui un thread o processo satura il core su cui gira ed e' anzi limitato dalla carenza di alu, mentre il core adiacente e' in idle...
il fatto e' che un meccanismo simile era troppo complesso da realizzare all' epoca, forse hanno deciso di implementarlo ora

[diabolik1981]

Originariamente inviato da viscm

Nessuno ha provato a guardare un po piu' in la del suo naso?

Immaginatevi i prossimi quadri-core,nel 90% dei casi almeno uno se non due core staranno x il 99% del tempo a girarsi i pollici.
Con questa tecnologia avremmo ,perlomeno, uno 'spreco' di risorse piu' limitato.

E' esattamente quello che penso io. Con il moltiplicarsi dei Core la possibilità che qualche Core resti inutilizzato è parecchio elevata. Magari potremmo trovarci in situazioni tipo QuadCore ma con tale tecnica è come averne 1/2/3 in base alle necessità del sistema rendendolo automaticamente più efficiente.

[bjt2]

Questo approccio risolverebbe i problemi esposti, se fosse una cosa dinamica: per un processo molto parallelizzabile e limitato dalle risorse di esecuzione, devo accorpare le CPU per stargli dietro, per un processo light, sia perchè è un processo molto scarico (tipo word) sia perchè il programmatore ha già provveduto a dividere in thread, non accorpo le CPU.

Qui si dimenticano, come già altri hanno detto, i vantaggi che danno queste soluzioni:

- Software legacy che non è stato riscritto in MP oppure semplicemente la cui versione MP costa troppo (pensiamo a software di rendering o DB i cui costi di licenza sono proporzionali ai core: i sw possono usare sono uno o due core, secondo la licenza, ma nulla vieta che questi core siano accorpamenti di più sotto core).
- Software non semplicemente parallelizzabile, o comunque non parallelizzabile a grana grossa (thread), ma solo a grana fine (come le CPU sanno ben fare), che però saturano tutte le unità di una sola CPU.
- Software parallelizzabile anche a grana grossa, ma che per questioni di tempo/budget/difficoltà intrinseca/difficoltà di debug, non è stato parallelizzato.

[pachugo]

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

Sono d'accordo con te.
D'altronde l'idea in se non è particolarmente nuova: già oggi le cpu contengono distinte unità di elaborazione e dispacciano le istruzioni dopo averle riarrangiate in modo da parallelizzare i compiti.
Questa soluzione pare fare il medesimo lavoro, a un livello "più alto", con i problemi di trasporto tra CPU e memoria che ne derivano.
In realtà i problemi tipici della programmazione multithreaded, in primis la sincronizzazione, andranno comunque gestiti, con la differenza che un programmatore ha una visione completa dell'algoritmo che sta implementando, mentre il processore no. Quindi un programmatore può ottenere benefici molto maggiori se scrive codice corretto.
Un lock su un accesso ad una risorsa può fare azzerare il guadagno di prestazioni, quindi credo impossibile ipotizzare 4x2Gz= 1x8 Ghz, nemmeno nella migliore delle ipotesi.
Chiaro che se andiamo avanti così, i programmatori da 4 soldi non impareranno mai a lavorare e continueremo con soluzioni subottimali.

[Nippolandia]

Fate troppo casino uno dice e buono l´altro dice di no,ancora manco si sa se verra´prodotta una cpu con queste caratteristiche.
Puo´darsi che sia un pregio tipo se i programmi non usano bene il multi-core allora sta tecnologia serve a farli andare meglio,invece se i prog giarno bene in multi-core allora sto Ht rimane a guardare senza fare nulla.
Vediamo dei Test prima di spalancare le bocche.

[JOHNNYMETA]

Originariamente inviato da magilvia

Non capisco come si fa a sparare a zero sui programmatori e sul single tasking senza un minimo di esperienza di programmazione.
Semplicemente per alcune applicazioni non è possibile programmare in multitasking, mentre per altre si hanno solo incrementi marginali!
Una innovazione come questa porterebbe tutti i vantaggi dei dual core con in più un boost nel single core. Dire che è un passo indietro è come dire chenesò, che l'ABS nelle macchine è peggio perchè bisogna imparare a fare frenate controllate..

Quoto.Parole perfette.

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