Link alla notizia: http://www.hwupgrade.it/news/cpu/17088.html

AMD starebbe studiando una nuova tecnologia, che permetterebbe di affiancare core diversi facendoli riconoscere dal sistema come un singolo processore

Click sul link per visualizzare la notizia.

Ormai anche i games (attraverso i driver ottimizzati) sfruttano i DC o L'HT.

Giusto ieri ho fatto una prova con aquamark 3:
HT off 44500 p
HT on 46500 p

Vantaggi con l'HT si hanno anche con FEAR, Call of Duty 2, Quake4, Morrowind 4...

E in futuro ce ne saranno sempre +.

Senza contare che nel MULTYPLAYER, in internet, fa sempre comodo un "processore" in + per gestire Antivirus e Firewall, Gamespy... così da evitare fastidiosi scatti. :O

----

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

Se ben implementata,una tecnologia del genere aiuterebbe ad avere il concetto di doppio processore = doppia potenza (che risiede nella maggior parte degli utonti :P)

Ottimo !!!!

Sarebbe una manna dal cielo....

pensate a una cpu quad core con 4 core da 2 ghz l'uno, l'applicazione la riconoscerebbe come unica cpu a 8 GHZ!!!

Secondo me è piu' efficiente un'architettura del genere... se l'applicazione è multitask allora ben venga la ripartizione dei compiti tra i vari core... pero' se è single task allora ben venga la somma della potenza elaborativa di tutti i core !!!

Bye

Cavolo che figata! Davvero una bella pensata!

Meraviglioso! Non avrei mai creduto si potesse pensare una cosa del genere! Dovrò ripensare la mia posizione dubbiosa sui molti-core :D

Ottimo !!!!
pensate a una cpu quad core con 4 core da 2 ghz l'uno, l'applicazione la riconoscerebbe come unica cpu a 8 GHZ!!!

Non credo sia propriamente così...
Tecnologia interessante cmq...

sicuramente la cosa non sara lineare ma anche se invece di 8ghz ne prende 5 .....beh mi sembra un bel guadagno ^^

credo che sia ben diverso avere 4 core da 2Ghz ad avere un processore unico da 8Ghz...
probabilmente si formerà tipo una sorta di pipeline tra processori... o qualcosa del genere

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

A parte pochi programmi professionali, moltissime applicazioni girano ancora in singletask... ok che nell'avvenire ciò cambierà, ma ora come ora una tecnologia del genere sarebbe molto ben accetta... almeno da me!! ;-)

Se i benefici rimangono e viene eliminato l'unico difetto è una gran cosa...
Basta che poi non mi compri un Dual Core per avere come ora un Single Core dal sistema addormentato :P

pensate a una cpu quad core con 4 core da 2 ghz l'uno, l'applicazione la riconoscerebbe come unica cpu a 8 GHZ!!!


No dai...secondo me sara' visto un unico processore...magari a 2ghz...con la differenza che sara' un processore con le palle quadrate :D :D

Grande amd come al solito :rullezza:

Dove non arriva il programmatore.....

ci arriva il processore......
fantastico... non sai programmare per 2 o più processori... no problem risolviamo in Hardware...

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

L'attuale tendenza è quella di avere un numero di core sempre maggiore in quanto sta diventando difficile aumentare la potenza del singolo core oltre i livelli attuali..

Di conseguenza il software deve essere rivisto in funzione di cpu costituite da 2 o più core, solo così si sfrutterà la vera potenza delle nuove CPU!

Sinceramente questa nuova tecnologia non la condivido. Il vantaggio di avere un processori multi core è ben visibile anche nell'utilizzo normale di un PC, il fatto di poter svolgere almeno un'operazione pesante e molte a basso "consumo" di risorse secondo me è un punto forte...
Ovvio una cosa del genere potrebbe aiutare in applicazioni multimediali come i giochi ma anche li non vedo grossi vantaggi, solitamente quando gioco ci sono comunque molte applicazioni aperte e un processore con più di un core mi farebbe comunque comodo.

non mi sembra un passo in avanti....ma un pararsi il **** di fronte alle applicazioni pigre che non accettano di spostarsi al multitasking...
Secondo me come l' HT verrà accantonato in futuro...o comunque mi semra una complicazione eccessiva...rispetto ai reali benefici che porterà in futuro (oh...anche se non me ne intendo affatto)

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

Infatti, cmq purtroppo esistono tanti programmatori eccellenti che fanno male il loro lavoro, se l'ottimizzazione multithread avviene in hardware, ben venga!

mmm ma sarà utile? o è solo un operazione commerciale?

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

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.

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

AMD ... sempre avanti

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.

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

Grande amd come al solito :rullezza:
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.

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.

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

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

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

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 :D ) 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 :D
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à :D

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

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

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? ^^ :D
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...

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

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.

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.

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.

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.

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.

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.

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?

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

@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

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

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.

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

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 ? :boh:
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 :O 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)

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

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: 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! :rolleyes:

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.

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

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

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 :D

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/

#$#$%#$%^@#$%^@$%^@$^@$@$%^@ *censored* !!!:friend: 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...

Ottima idea!

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

jappilas grazie per le risposte e i link

:friend: 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 :muro: )

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

liviux:
il tuo paradigma informatico si chiama core software (transmeta).

liviux:
il tuo paradigma informatico si chiama core software (transmeta).
No, no, non parlavo di code morphing. Intendevo proprio un nuovo modo di pensare la programmazione diverso dall'attuale:

leggi istruzione
leggi operandi
esegui istruzione
scrivi risultati
ripeti

Lo si è parallelizzato in tutti i modi possibili: con diverse unità funzionali in cascata, con più pipelines in parallelo, riordinando le operazioni, suddividendo i thread fra più core o più processori, infilando altri thread nelle fasi di stallo di quello principale, ma il concetto alla base rimane sempre quello di Von Neumann. Ritengo invece che per ottenere un vero balzo prestazionale sia necessario cominciare a pensare e programmare in modo meno lineare, magari bidimensionale. Non sono molto addentro la ricerca in questo campo, ma penso che gli automi celluari siano un buon punto di partenza. Ovviamente serviranno strumenti nuovi e la compatibilità all'indietro andrà a farsi benedire.

Per come la vedo io è una tecnologia di "nicchia" e di scarso valore applicativo. Ormai i software "single task" sono ridotti all'osso, a maggior ragione i software del futuro. Senza contare che la programmazione parallela ormai è diventata quasi "seamless". Quindi che ci siano 2 o 100 core non importa. Anche i giochi si stanno spostando verso il mondo del calcolo parallelo.

Ormai anche i games (attraverso i driver ottimizzati) sfruttano i DC o L'HT.

Giusto ieri ho fatto una prova con aquamark 3:
HT off 44500 p
HT on 46500 p

Vantaggi con l'HT si hanno anche con FEAR, Call of Duty 2, Quake4, Morrowind 4...

E in futuro ce ne saranno sempre +.

Senza contare che nel MULTYPLAYER, in internet, fa sempre comodo un "processore" in + per gestire Antivirus e Firewall, Gamespy... così da evitare fastidiosi scatti. :O

----

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


Basti pensare che già Quake III Arena ai tempi aveva già il supporto per l'SMP. ;)

Ottima idea da parte di AMD o chichessia che la svilupperà.

Qui si parla di unire uno svantaggio velocistico costituito dalle attuali architetture , che come ha dimostrato intel sul campo oltre ad una certa velocità in single tasking nn può arrivare, e lo svantaggio di avere in futuro troppe unità di calcolo che poi nn verranno utilizzate.

Nn si parla di programmatori idioti, sebbene nn siano nemmeno volti alla architettura 64 bit figuriamoci il multicore....., ma del fatto che di base molti algoritmi nn possono essere adattati al multicore, come la maggioranza dei decoding.

Se questa tecnologia prenderà piede si potranno avere SIA più core per i processi multicore, SIA più potenza per i processi singlecore, indi nn vedo svantaggi ma solo vantaggi.

Se poi si preferisce ragionare sul "questo mi basta e lo voglio ottimizzare fin dove posso, il resto nn serve" nn saremmo andati mai avanti come tecnologie.