L'anti HT di AMD si fa più vicino

[Redazione di Hardware Upg]

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

AMD potrebbe presentare una nuova tecnologia in grado di abbinare la potenza di due core, così da meglio sfruttare le applicazioni single task

Click sul link per visualizzare la notizia.

[NvidiaMen]

Per la felicità dei funboy Intel che in spiaggia volevano "pettegolare" sul presunto primo posto di Intel almeno nel mese di Luglio...

Questa tecnologia permetterà di avere certamente grossi boost prestazionali nel breve periodo su applicazioni per CPU a single core... Il futuro però stringe sempre più l'occhio alle applicazioni multithread e ciò richiede anche l'efficienza architetturale dei futuri processori multi-core nelle operazioni "parallele"...

[danyroma80]

chissà se è piu' efficiente programmare sapendo a priori di avere sotto un multicore oppure programmare facendo finta di avere un solo processore.
Chissà, lo vedremo appena usciranno questi nuovi amd ed effettuando test con gli attuali dual core. Potrebbe essere l'asso nella manica di amd.

[simone1974]

Parlando in ambito videoludico

Parafrasando se maometto non va alla montagna, la montagna va da maometto, se i giochi non vanno nella direzione dei dual core, allora sono i dual core che vanno nella direzione dei videogiochi

[Symphysodon]

Non vorrei fare l'avvocato del diavolo, ma sembra un incentivo per non scrivere software adeguato su architetture multicore e/o multiprocessor. Il software scritto appositamente per gestire più processori ha sempre una marcia in più....

Comunque sia la soluzione di AMD è abbastanza intelligente e utile, sopprattutto per sfruttare al meglio i processori multicore con il software attuale e il software che per svariati motivi non può avvantaggiarsi del multicore.

[cionci]

A me la cosa lascia perplesso... Soprattutto se viene applicata in questa ottica...la cosa sarà sicuramente meno innovativa di quanto avevo ipotizzato...

Sicuramente se fosse relativa all'overclock di un solo core sarebbe un'immane cavolata...anche se sortirebbe i suoi effetti...

Riguardo alla possibilità di sincronizzare le L1 dei due core...non sarebbe impossibile...
Ma poi come evolverebbe la CPU ? Ci sarebbe un doppio incremento dell'istruction pointer ?!?!? Ma non finirebbe qui la cosa perchè si dovrebbero sincronizzare sia lo scheduler out-of-order che il register file e probabilmente le due pipeline per gli eventuali flushing... Insomma...possibile è possibile, ma la vedo un tantino complicata...

una ulteriore possibilità sarebbe un'evoluzione dello stato della pipeline guidato da una sola CPU...in pratica entrambe le pipeline devono essere "pienate" dallo stesso scheduler ooo... Gruppi di istruzioni dipendenti vanno in una pipeline e gruppi di sitruzioni dipendenti, ma indipendenti dalle precedenti vanno nella seconda...

L'ultima, ma forse la più semplice...le unità di esecuzione di un core vengono messe a disposizione dell'altro...in pratica le CPU condividono una parte della pipeline aumentando il parallelismo...

Negli ultimi due casi la CPU risultante oitrebbe tenere comunque conto solo delle cache L1 e L2 di una sola CPU e delle unità fetch & decode di una sola CPU...

[xpiuma]

Originariamente inviato da cionci

A me la cosa lascia perplesso... Soprattutto se viene applicata in questa ottica...la cosa sarà sicuramente meno innovativa di quanto avevo ipotizzato...

Sicuramente se fosse relativa all'overclock di un solo core sarebbe un'immane cavolata...anche se sortirebbe i suoi effetti...

Riguardo alla possibilità di sincronizzare le L1 dei due core...non sarebbe impossibile...
Ma poi come evolverebbe la CPU ? Ci sarebbe un doppio incremento dell'istruction pointer ?!?!? Ma non finirebbe qui la cosa perchè si dovrebbero sincronizzare sia lo scheduler out-of-order che il registry file e probabilmente le due pipeline per gli eventuali flushing... Insomma...possibile è possibile, ma la vedo un tantino complicata...

una ulteriore possibilità sarebbe un'evoluzione dello stato della pipeline guidato da una sola CPU...in pratica entrambe le pipeline devono essere "pienate" dallo stesso scheduler ooo... Gruppi di istruzioni dipendenti vanno in una pipeline e gruppi di sitruzioni dipendenti, ma indipendenti dalle precedenti vanno nella seconda...

L'ultima, ma forse la più semplice...le unità di esecuzione di un core vengono messe a disposizione dell'altro...in pratica le CPU condividono una parte della pipeline aumentando il parallelismo...

Negli ultimi due casi la CPU risultante oitrebbe tenere comunque conto solo delle cache L1 e L2 di una sola CPU e delle unità fetch & decode di una sola CPU...

Mah, la prima tua ipotesi mi pare un pò troppo complicata, sinceramente credo che ci sarebbe troppo OH di sincronizzazione, e la ritengo davvero complessa da gestire.

Sono d'accordo con la tua ultima ipotesi, aumentare il parallelismo mettendo a disposizione le pipeline di un core all'altro.
Per le unità di fetch e decode non la vedo così tragica, gli A64 sono sempre stati prodigi di fetch e decode, credo ne abbiano in abbondanza per riempire due core senza problemi (dato che ovviamente non viaggerebbero entrambe al 100% fisico).
Per la cache... Magari una connessione logica tra le due cache L1 e la duplicazione dei dati sarebbe la soluzione più logica, mentre per la L2 non ci sono problemi, è già condivisa tra i due core.

Più che altro la cosa che mi impressionerebbe in un sistema così sarebbe la gestione del reorder buffer, che dovrebbe operare con i dati provenienti da due core. Oppure si utilizzerebbero entrambe i ReB ed un qualche meccanismo per congiungerli alla fine? (ma mi sembra improbabile).

[MiKeLezZ]

AMD sta arrancando di riffa e di raffa..

La cosa in sé, è interessante, perchè potrebbe portare a benefici tangibili per quelle applicazioni incapaci di sfruttare il multithreading.
Il problema è che un'implementazione corretta sarebbe stata usare una capacità di reggere dinamicamente il carico (ovvero il secondo processore mette a disposizione tutto o solo una parte della sua potenza a seconda della richiesta), mentre così mi sembra un banale "merge" dei due processori, che porta con sè tutte le vecchie problematiche single core che si pensava fossero state superate.
Non ultima, certamente, quella che gli sviluppatori si adagino un po' troppo sugli allori. Con i quad core alle porte, non ce lo possiamo permettere.

In ogni caso sembra che la funzionalità sia insita nei processori AM2 e per attivarla basti un aggiornamento del BIOS e l'installazione di un pacchetto driver.

Per chi non ha perso tempo per mandare frecciatine:
- una tecnologia del genere è facilmente replicabile da Intel (o affondabile, oliando le ruote giuste)
- Intel ha un know-how maggiore per sfruttare questa tecnologia in quanto è presente già dalle prime architetture Core la L2 unica e condivisa mentre AMD ci sta ancora lavorando su :P
- per ora non abbiamo nulla fra le mani, solo un forse e un chissà, mentre per Conroe ci sono bench esaustivi (addirittura pure sul quad core).
In ogni caso, l'ipotetica supremazia AMD, avverrebbe a che prezzo? I processori FX single core è quasi un anno che sono stati tolti per metter al loro posto i Dual Core. Ormai come bench, il 70% è dedito al multithreading. Mi sembra un controsenso.

[freeeak]

hehehe se la montagna non va da Maometto,Maometto va alla montagna.(la storia dei 64bit&M$ ha insegnato qualcosa)

[cionci]

Originariamente inviato da xpiuma

Oppure si utilizzerebbero entrambe i ReB ed un qualche meccanismo per congiungerli alla fine? (ma mi sembra improbabile).

Infatti...è per quello che mi viene da pensare che tutta la parte della pipeline antecedente e successiva alla fase di esecuzione di una CPU debba essere disabilitata...e tutto va a fare riferimento alle unità dell'altra CPU...

[cionci]

Originariamente inviato da MiKeLezZ

Per chi non ha perso tempo per mandare frecciatine:

Però vedo che la frecciatina ti ha raggiunto

[jedy48]

per me è una bella mossa, usando ad esempio photoshop puoi avere un incremento notevole sfruttando tutti i core per una applicazione invece di lasciare un core a grattarsi le pall....

[Dumah Brazorf]

Non ci resta che aspettare per vedere se funziona e quanto efficiente sarà, il tifo da stadio è superfluo.
Ciao.

[generals]

Una buona idea, il vuoto che si è creato coi multi core è proprio questo, quello di essere preformanti con applicazioni multi, che però stentano a decollare in modo massiccio, ma presenta lo svantaggio di basse prestazioni in ambito single o cmq un limite nella sua crescita, si pensi ai giochi. Questa tecnologia dovrebbe, anche se in parte, risolvere questo gap

[MiKeLezZ]

Originariamente inviato da cionci

Però vedo che la frecciatina ti ha raggiunto

Un po' sì: mi son fatto la bocca a E6600 e multithreading (sto penando come un matto con l'AMD single core) e questa notizia mi è un po' indigesta

[gianni1879]

son curioso di vedere i primi test e di quanto possano aumentare le prestazioni in singletask..

certo sta battaglia tra amd ed intel mi sta proprio piacendo era da troppo che non ci si innovava

[viscm]

Originariamente inviato da gianni1879

certo sta battaglia tra amd ed intel mi sta proprio piacendo era da troppo che non ci si innovava

Anche a me,penso infatti che AMD non avesse programmato di far uscire questo anti-HT con i dual core ma a partire dalla prossima generazione (quad-core e +)

Ma la straordinaria riuscita di conroe ha fatto anticipare il tutto,anche se forse i benefici maggiori di questa innovazione si vedranno proprio da i quad-core in su.

Infatti sfido chiunque,tranne in casi particolarissimi, a sfruttare 4 core,secondo me nel 90 % dei casi 2 se non 3 core si gireranno i pollici.

[CENTAURO84]

cosa importa prendere le difese di intel dicendo che questa opzione durerà poco o le difese di Amd dicendo che è una grandissima cosa venerandola come fosse la manna dal cielo?

E' una cosa di cui si parlava già da tantissimo tempo e a mio modesto parere è venuta fuori solo ora come arma di difesa contro Intel che pare avrà prestazioni maggiori rispetto ai dual core di Intel.

Comunque sia la trovo una buona cosa sopratutto perchè non tutti i software vengono sviluppati da software house con diversi sviluppatori al seguito e tante monetine in tasca...
Questa è una possibilità in più per quei piccoli programmatori che non hanno le capacità o le finanze di mettersi a scrivere programmi che sfruttano i dual core. E di programmi freeware di questo genere c'è ne sono a bizzeffe!

Quindi non credo che il passaggio ai dual core sul lato software avverrà in tempi brevi e se ci sarà andrà bene come prima chissenefrega. Al momento dovrebbe uscire verso fine luglio e quindi da quel momento fino al quasi definitivo passaggio a programmi scritti tutti per più core verrà sfruttato... Tutto sta a quanto questa tecnologia sarà capace di aumentare realmente le prestazioni...

[sirus]

Originariamente inviato da xpiuma

...
mentre per la L2 non ci sono problemi, è già condivisa tra i due core.
...

Solo nelle CPU con architettura Core la L2 è condivisa, AMD ha parlato di L3 condivisa per K8L, non prima e in nessun altro livello oltre al terzo!

Comunque ho già espresso altrove le mie preoccupazioni, la circuiteria per gestire questo sistema con un'implementazione degna di nota e che magari sia tanto scalabile da poter essere usata in futuro con le CPU Quad Core, non è banale ed IMHO è necessario vedere se il gioco vale la candela
Una circuiteria simile potrebbe portare a delle notevoli latenze in alcuni casi limite e soprattutto potrebbe portare ad un riscaldamento non propriamente benigno di una parte del die (quella di controllo)...

Comunque le mie come ho già detto sono supposizioni, spero di essere smentito in merito

[xeal]

Originariamente inviato da Symphysodon

Il software scritto appositamente per gestire più processori ha sempre una marcia in più....

Per meglio dire: "il software che si può scrivere e da dei vantaggi per..."

Il problema consiste nella "solita" regoletta empirica per cui il 10% del codice richiede il 90% del tempo di esecuzione, per cui creare 10 thread di cui 9 leggerissimi e uno pesantissimo, vuoi per la quantità di calcoli che non si è riusciti a dividere in più thread (e non è una questione di svogliatezza o incapacità del programmatore, in genere è difficile farlo e in genere sono pochi i casi in cui si riesce a farlo efficientemente), vuoi per la loro complessità, non migliora l'efficienza del codice, anzi aggiunge overhead relativamente agli switch fra un thread e l'altro (che per quanto minimi ci sono sempre) e dei "fastidi" agli altri thread/processi, senza ottenere alcun vantaggio se non la possibilità di dire: ecco, abbiamo riscritto il programma per poter sfruttare i multicore (= marketing)...

Questa tecnologia potrebbe invece aggiungere parallelismo laddove è difficile ottenerlo.