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.

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

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.

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

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.

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

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

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.

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

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

Per chi non ha perso tempo per mandare frecciatine:
Però vedo che la frecciatina ti ha raggiunto :D

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

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

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

Però vedo che la frecciatina ti ha raggiunto :D
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 :D

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

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.

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

...
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 :muro:
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 ;)

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.

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 :sofico:
In effetti attualmente e per qualche anno ancora direi che la si può vedere così, quindi questa tecnologia di Amd non è affatto azzardata.

potrebbero fare un procio quad core e mostrarne al os solo 2.
cosi i giochi vanno + veloci e i programmi "multitasca" anke.

Come notizia mi sembra un po' troppo vaga.
Se AMD riuscirà a gestire la sincronia tra i due core (con un semplice upgrade del bios o con le future release dei processori) riuscendo a processare, in ambito single tasking, 6 istruzioni per ciclo di clock, allora sarà di sicuro un'ottima mossa.
Se questa tecnologia prevede solo lo standby di uno dei processori e l'overclock dinamico dell'altro ... bhé, non mi sembra questa grande tecnologia
Aspettiamo di vedere questa tecnologia all'opera e poi faremo i dovuti raffronti con Conroe.

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

E' così che l'avevo immaginata inizialmente, però credevo che sarebbe stata necessaria una nuova revision, con alcune variazioni interne, ad esempio con alcuni registri "sdoppiati" (es: registri tampone nelle pipeline et similia, ma eventualmente anche registri generali) con l'aggiunta di qualche bit (ad uso interno) per identificare un dato o un'istruzione come relativa ad un core, in modo tale da poter eseguire microop relative a thread/processi diversi (ovvero a core diversi) in una stessa pipeline (una delle tre per ciascun core), risolvendo gli accessi alla cache grazie al codice di identificazione (il core che esegue operazioni "miste" - nella stessa pipeline o in più pipeline - riconosce l'istruzione come "sua" o "affidata" e, nel secondo caso, accede alla cache dell'altro core mediante hypertransport); nel caso di operazioni miste nella stessa pipeline si porrebbe il problema dello svuotamento in caso di problemi con un branch, però anche in questo caso il codice di identificazione potrebbe risolvere il problema: so quale gruppo di istruzioni non va bene, elimino/isolo quelle, continuando l'esecuzione delle altre.

Naturalmente l'aumento prestazionale si avrebbe laddove fossero presenti istruzioni indipendenti in numero superiore rispetto al numero di pipeline presenti: troverei interessante (non so quanto sia possibile/conveniente all'atto pratico) la possibilità di "forzare" il numero di operazioni indipendenti considerando tali (sdoppiandole) le operazioni dipendenti, laddove si possano considerare noti i possibili valori che discriminano il risultato corretto/l'esecuzione di una piuttosto che un'altra (es: seguire i rami di uno o più salti - corrispondenti a uno o più if, o uno switch) in modo tale da non dover "buttare a mare" i risultati di una diramazione E ripartire praticamente da zero con l'altra, ma avendo già pronta (o giunta a buon punto) l'elaborazione alternativa. Il tutto condito da un meccanismo di bilanciamento del carico (che ritengo inevitabile per certi versi): un core può chiedere "aiuto" all'altro solo se ha raggiunto un certo livello di occupazione E l'altro è in idle o comunque ad un livello di occupazione inferiore (questo sarebbe il minimo indispensabile, altrimenti si romperebbero le scatole a vicenda), con l'entità dell' "aiuto" dipendente dal carico del core "aiutante" e dalle impostazioni per il risparmio energetico (nelle impostazioni più "dispendiose" un core potrebbe ridurre la propria velocità solo se non deve supportare nessun'altro core e andare sempre alla velocità massima quando lavora, mentre in quelle più "parsimoniose" - sta a vedere quanto - ciascun core gestirebbe il proprio carico, e il proprio risparmio energetico, indipendentemente, con le varie opzioni intermedie - ad esempio, e potrebbe essere l'impostazione di default, i core variano dinamicamente velocità a seconda del proprio carico e, raggiunta una certa soglia, chiedono aiuto ad un altro core, il quale andrebbe a variare la propria velocità in base al nuovo carico; l'esecuzione di istruzioni dipendenti e sdoppiate potrebbe essere subordinata, ove fattibile, alle impostazioni energetiche, ad esempio "concessa" solo se i due core devono comunque lavorare alla massima velocità se non sono in idle).

Un'implementazione di questo tipo potrebbe poi essere il preludio ad una evoluzione più complessa, con fetch e decode unificati (e magari anche logica ooo) e unità di calcolo in "stretta collaborazione", chissà...

Quanto all'ipotesi che prevede la disabilitazione di un core e l'overclock dell'altro, potrebbe presupporre la presenza di un moltiplicatore sbloccato verso l'alto; in questo caso: che sia una "potenzialità" riservata agli FX? che sia possibile sbloccare il moltiplicatore con una versione apposita del bios (ne dubito comunque, credo che in tal caso sarebbe saltata fuori una mobo per overclockers con bios opportuno)? che sia possibile per la cpu variare il moltiplicatore verso l'alto "dall'interno" mantenendo l'impossibilità di agire dall'esterno? :confused:
Edit: a ripensarci, se fosse riservata agli FX, sempre nell'ipotesi di overclock dinamico con un solo core abilitato, entrerebbe in contrasto con le versioni 4x4, no? Perchè aumentare il numero di core su singolo socket se poi se ne vuole utilizzare, per aumentare le prestazioni, uno solo overcloccato?


Tra qualche settimana ne sapremo sicuramente di più :D

scusate l'ignoranza... ma non riesco a vederne l'utilità. mi spiego:

l'HT era nato perchè il processore perdeva troppo tempo a switchare da un processo (o thread) quando l'SO lo porta da running a waiting (per I/O) o a ready (per scheduling). In pratica la duplicazione dei registri (ovvero l'HT) permetteva al processore di continuare a macinare calcoli e passare direttamente sull'altro insieme di registri mentre il contenuto degli altri registri viene aggiornato "senza che se ne accorga". In pratica, così, vengono azzerati i tempi morti dovuti allo scheduling tra più processi.

Ora invece l'Anti-HT fa il contrario, accorpa diverse CPU fisiche per dare vita ad una sola CPU logica. Non si corre il rischio di "annullare" i vantaggi apportati in termini di switch da tecnologie come l'HT e/o multicore?

(se ho detto un mare di castronate non mi fucilate pls :P)

praticamente un raid0 x le cpu?

ma tutto questo come si tradurrà in vantaggi x le cpu GIA' in ns possesso?

ragazzi non si è fatta un po' di confusione, forse la news non riporta il succo del "Reverse HT" ... ovvero il trucco ...

vi riporto quello che reputo il pezzo mancante:
"La tecnologia "ingannerebbe" il software facendo credere che la cpu abbia un solo core e non due, originando ben 6 IPC core le cui prestazioni complessive dovrebbero rivaleggiare con quelle dei 4 core di Merom, Conroe e Woodcrest".

e come fu per l'HT agli inizi ciò implica driver e programmi ad hoc imho :read:

si ma ripeto la domanda: tutto questo sarà applicabile sul vecchio HW o saremo obbligati a spendere ancora?

si ma ripeto la domanda: tutto questo sarà applicabile sul vecchio HW o saremo obbligati a spendere ancora?
Credo che sia limitato alle CPU AM2...

Domanda:
Se fosse come detto da Xeal non si potrebbe utilizzare il 2 prcessore esclusivamente per fare branch prediction ed isolare la parte della pipeline che "non va bene" e lasciare l'altro processore continuare a macinare come un mulo saltando come un passo tra un istruzione e l'altra?
Facendo questo amd potrebbe permettersi di "allungare" o cmq accodare le pipeline non temendo errori di fut pred con svuotamento completo della coda e via di fetch.
Ma ad intel nn poteva venire in mente prima sta cosa? cioe' dico con una pipeline a 31 stadi (al posto di poco meno di 20 da parte amd se ricordo bene) ed una gestione simile avrebbe tirato fuori un bel procio (pero' devo dire che si e' "salvata" con conroe)

ecco l'inghippo ... tagliano fuori tutti i 939 cercando di pompare gli am2 ...

Comunque se non ho capito male, (dalle notizie lette) il 4x4 dovrebbe integrare al suo interno la tecnologia ( HT Iversed ;) ), in modo che 4 core vengano visti come 2 con un raddoppio (teorico) delle prestazioni, anche se un onesto 80% non sarebbe male al momento del lancio.

X Le disquisizioni tecniche della prima pagina post interessanti, ma ho capito poco.

ecco l'inghippo ... tagliano fuori tutti i 939 cercando di pompare gli am2 ...

Ovviamente :O

AMD lo fa' per vendere, mica regala nuove prestazioni sui proci già venduti.
Ad AMD interessa che il suo procio che si trova sugli scaffali sia + potente della concorrenza, da indurci a comprarlo ed AMD a incassare ... i proci che già abbiamo nel case ad AMD non glie ne frega + nulla ormai.

Ovviamente :O

AMD lo fa' per vendere, mica regala nuove prestazioni sui proci già venduti.
Ad AMD interessa che il suo procio che si trova sugli scaffali sia + potente della concorrenza, da indurci a comprarlo ed AMD a incassare ... i proci che già abbiamo nel case ad AMD non glie ne frega + nulla ormai.

Premetto che son sempre stato fanboy di AMD, infatti i miei pc han sempre montato proci AMD.

Tuttavia questa tecnologia mi pare inutile, specie perchè giochi quali oblivion vanno meglio con un 3800+ X2 che con un single core anche con 1MB di L2. Sono stati fatti test overcloccando single core ma il gioco non trae vantaggio da maggiore frequenza e quindi maggiore potenza di calcolo di un single core ma solo da due core!!!

A che pro quindi unire i due core nei calcoli quando oramai iniziano ad esserci gli applicativi che sfruttano i dual core??? Anche nei giochi?

Per me non ha senso. Forse nei proci con 4 core, ma per ora mi sembra inutile.

ecco l'inghippo ... tagliano fuori tutti i 939 cercando di pompare gli am2 ...
beh magari qualche appassionato smanettore molto bravo potrebbe modificare/adattare i driver per il skt 939 :D

sarabbe un bel colpo :D



.....sognamo va..... ;)

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....
mah, veramente photoshop è proprio una di quelle applicazioni su cui il multithreading è stato applicato per primo, proprio per accelerare il calcolo dei filtri sulle workstation multiprocessore, o per mantenere reattiva l' interfaccia anche durante il calcolo... :stordita:
scusate l'ignoranza... ma non riesco a vederne l'utilità. mi spiego:
..

in effetti, è da quando sono usciti primi northwood con HT e i primi A64 che chi chiede che processore acquistare per il nuovo pc, si sente dire "per i giochi, meglio un AMD, per il multitasking meglio un intel"... :O

Io aspetterei a parlare, la notizia è molto poco dettagliata, ma come al solito c'è chi ha la palla di cristallo e trae già le sue brave conclusioni.

Inutile non lo è, se una cosa del genere viene attivata in maniera dinamica mentre uno o gli altri core non stanno facendo niente. Mi sembra l'unica prospettiva quella di incrementare le istruzioni per ciclo di clock sfruttando *almeno* le capacità delle unità esecutive in idle, anzi penso che se così fosse, questa sarebbe davvero un'ottima soluzione quando c'è un solo applicativo single-task (come un gioco).

Chi dice che sarà necessario riscrivere il codice come succede quando c'è la necessità di sfruttare più core, consiglio di rileggersi la notizia perché forse non ha capito qual è lo scopo di questa tecnologia.

Se la cosa venisse fuori solo come un overclock dinamico, ma non ci credo minimamente, allora si che sarebbe una cosa del tutto inutile!

Io aspetterei a parlare, la notizia è molto poco dettagliata, ma come al solito c'è chi ha la palla di cristallo e trae già le sue brave conclusioni.

Inutile non lo è, se una cosa del genere viene attivata in maniera dinamica mentre uno o gli altri core non stanno facendo niente. Mi sembra l'unica prospettiva quella di incrementare le istruzioni per ciclo di clock sfruttando *almeno* le capacità delle unità esecutive in idle, anzi penso che se così fosse, questa sarebbe davvero un'ottima soluzione quando c'è un solo applicativo single-task (come un gioco).

Chi dice che sarà necessario riscrivere il codice come succede quando c'è la necessità di sfruttare più core, consiglio di rileggersi la notizia perché forse non ha capito qual è lo scopo di questa tecnologia.

Se la cosa venisse fuori solo come un overclock dinamico, ma non ci credo minimamente, allora si che sarebbe una cosa del tutto inutile!
pienamente d'accordo. Dalla news si capisce che l'attivazione o meno del Reverse-HT avverrà in maniera dinamica, i driver individueranno il tipo di applicazione e decideranno se attivare o no il Reverse-HT. Quindi anche i giochi e le applicazioni single task che richiedono maggior potenza di calcoloil R-HT sarà su on mentre nelle altre applicazioni/giochi multi task il R-HT sarà tenuto disattivato.

non penso che si tratti di un oc dinamico, sarebbe abbastanza inutile e sa di presa x i fondi :)

pienamente d'accordo. Dalla news si capisce che l'attivazione o meno del Reverse-HT avverrà in maniera dinamica, i driver individueranno il tipo di applicazione e decideranno se attivare o no il Reverse-HT. Quindi anche i giochi e le applicazioni single task che richiedono maggior potenza di calcoloil R-HT sarà su on mentre nelle altre applicazioni/giochi multi task il R-HT sarà tenuto disattivato.

non penso che si tratti di un oc dinamico, sarebbe abbastanza inutile e sa di presa x i fondi :)

Non credo che si possa fare in questo modo, si interferirebbe con lo scheduler dei processi, che è un modulo del sistema operativo, e si [email protected] un po': il meccanismo "riconosco processo single task (?) -> attivo reverse-ht -> eseguo processo -> disattivo reverse-ht" sembra presupporre la possibilità per il processore di mostrarsi al sistema ora come single-core, ora come dual-core, e questo implicherebbe la necessità di variare dinamicamente il numero di code dei processi in esecuzione (con tutti i problemi del caso), che in genere sono una o più per cpu/core (per tener conto delle priorità), quindi si richiederebbe allo scheduler un lavoro che solo lui può fare (il driver di cpu non può certo sostituirsi interamente allo scheduler) e che probabilmente non sa fare (-> bisogna riscrivere lo scheduler!), aggiungendo dell'overhead credo non indifferente al context switch (le prestazioni peggiorano).

Ritengo sicuramente più semplice stabilire una soglia di occupazione cpu al di sotto della quale un core può "prestare" delle risorse di calcolo all'altro, e una al di sopra della quale diventa conveniente "chiedere aiuto"; oppure, se si vuol far vedere al sistema un solo processore, si disabilitano alcune parti di un core (relative al caricamento e decodifica dell'istruzione) e si opera con un solo core che può usare le alu e le fpu dell'altro, ma lo si fa sin dall'inizio (-> impostazione da bios) e si mantiene l'impostazione per tutti i processi.

Tutto IMHO, naturalmente.

Ritengo sicuramente più semplice stabilire una soglia di occupazione cpu al di sotto della quale un core può "prestare" delle risorse di calcolo all'altro, e una al di sopra della quale diventa conveniente "chiedere aiuto";
in effetti al'inizio il progetto "Hammer" sembrava proprio vertere su queste caratteristiche, multicore abbinato a un meccanismo di condivisione delle ALU e di load balancing tra i due core
poi all' epoca non si sono concretizzate e la microarchitettura del processore uscito è stata un po' meno rivoluzionaria di come inizialmente prospettato, ma proprio per questo penserei che la soluzione accennata dala news sia effettivamente questa
oppure, se si vuol far vedere al sistema un solo processore, si disabilitano alcune parti di un core (relative al caricamento e decodifica dell'istruzione) e si opera con un solo core che può usare le alu e le fpu dell'altro, ma lo si fa sin dall'inizio (-> impostazione da bios) e si mantiene l'impostazione per tutti i processi.
credo anch'io... per tutti i processi e per tutta la sessione fino al riavvio della macchina (come per HT, d' altronde)

Se nons baglio nella news si cita un supporto da parte di MS e quindi di fatto probabilmente interverranno anche profondamente sul SO... Boh...vediamo...

credo anch'io... per tutti i processi e per tutta la sessione fino al riavvio della macchina (come per HT, d' altronde)
Per tutti i processi credo proprio di sì...fino al riavvio della macchina credo proprio di no... Essendoci dei driver sicuramente si potrà scegliere di switchare a questa modalità manualmente... Chiaramente sarebbe meglio switchare in modo automatico a seconda del programma in esecuzione...

la AMD è sempre avanti alla intel :sofico:

Per tutti i processi credo proprio di sì...fino al riavvio della macchina credo proprio di no... Essendoci dei driver sicuramente si potrà scegliere di switchare a questa modalità manualmente... Chiaramente sarebbe meglio switchare in modo automatico a seconda del programma in esecuzione...
mi ero perso il dettaglio del driver, chiedo scusa :O
...
quindi si richiederebbe allo scheduler un lavoro che solo lui può fare (il driver di cpu non può certo sostituirsi interamente allo scheduler) e che probabilmente non sa fare (-> bisogna riscrivere lo scheduler!),...
però il driver non dovrebbe comunque aver bisogno di "sostituirsi" allo scheduler, ma al più "integrarsi" con lo scheduler per permettergli di gestire le situazioni di switch (lo scheduler dovrà migrare al volo i processi che giravano sulla cpu che viene esclusa)

però il driver non dovrebbe comunque aver bisogno di "sostituirsi" allo scheduler, ma al più "integrarsi" con lo scheduler per permettergli di gestire le situazioni di switch (lo scheduler dovrà migrare al volo i processi che giravano sulla cpu che viene esclusa)

Già, però bisogna vedere se è possibile variare "a caldo" il numero di processori che lo scheduler deve gestire; si potrebbe forse risolvere forzando lo scheduler a vedere il secondo core come sovraccarico al punto di dover spostare tutti i processi nelle code dell'altra cpu, intervenendo sull'algoritmo di bilanciamento del carico (o richiamandolo opportunamente, ma rimane il problema di fondo: è possibile accedere a quei dati/funzioni oppure lo scheduler li gestisce per conto suo e non sente storie? in generale potrebbe essere necessaria una modifica, ma anche in questo caso non credo che tarderà ad arrivare, nè da parte di MS, nè dagli sviluppatori linux e unix.

Chissà, potrebbe essere una soluzione tampone prima dell'introduzione di una nuova revision (o magari del "famigerato" K8L) che deleghi tutto ad un processo hardware automatico. A questo punto non vedrei male anche una implementazione "interna" che cercasse di sfruttare risorse fpu inutilizzate per eseguire alcune operazioni su interi (ad esempio so che mediamente un'operazione fpu impiega un tempo t=nt' con t' tempo di esecuzione medio di un'operazione da parte dell'alu, quindi ogni n operazioni accodate nelle pipeline alu ne accodo una all'fpu), forse varrebbe la pena di valutare questa possibilità...

Comunque, se si tratterà di accorpare due core per farli vedere al sistema come uno solo, non credo che sia una gran mossa contro conroe: da un lato due core che possono, ciascuno, eseguire fino a quattro operazioni logico-aritmetiche (giusto? non vorrei ricordar male), dall'altra un solo "macrocore" che può può gestirne fino a sei alla volta, ma eseguire un solo thread alla volta (quindi meno reattivo nel multitasking, certo non eccellente con applicazioni multithreaded e forse da "guidare a mano" ). A meno che non sia una soluzione riservata ai soli 4x4, con quattro core che possono diventare due... In ogni caso, credo che questa tecnologia mi piacerà veramente quando sarà gestita in automatico dai core senza implicare la "disattivazione" di uno dei due, con l'uso di risorse temporaneamente inutilizzate.

Sono sempre più curioso di sapere cosa hanno intenzione di implementare... quasi quasi faccio un viaggetto a Dresda, mi intrufulo negli stabilimenti e do una sbirciatina ai progetti :D... salvo venire arrestato appena esco di casa solo per averci pensato :p

mio padre che lavora all'IBM ha riportato un computer prototipo con l'ultimo processore inventato da IBM a 500 Ghz..... ragazzi è un siluro! Ho fatto un test facendo avviare nello stesso momento 50 programmi del tipo grafica, audio, video.... insomma di quelli pesanti.... e sapete quanto ci ha messo a caricarli? 1 SECONDO!

ahahahahahahahahahahahahahah ci siete cascatiiiiiiii ahahahahahah

Se nons baglio nella news si cita un supporto da parte di MS e quindi di fatto probabilmente interverranno anche profondamente sul SO... Boh...vediamo...
si esattamente almeno dovrebbe essere così e con opportuni driver rilasciati da amd. Il cambio dovrebbe avvenire a caldo senza riavviare proprio nulla. Altrimenti il significato di dinamico avrebbe poco senso :)

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 ;)
pienamente d'accordo. ci sono applicazioni che non potranno mai essere scritte per utilizzare due ore, in questo modo si colma alla mancanza prestazionale dei multicore con queste applicazioni. ;)

ahahahahahahahahahahahahahah ci siete cascatiiiiiiii ahahahahahah
:rotfl: :rotfl: :rotfl: Simpaticissimo :rolleyes: Non faceva ridere...

Ovviamente :O

AMD lo fa' per vendere, mica regala nuove prestazioni sui proci già venduti.
Ad AMD interessa che il suo procio che si trova sugli scaffali sia + potente della concorrenza, da indurci a comprarlo ed AMD a incassare ... i proci che già abbiamo nel case ad AMD non glie ne frega + nulla ormai.
LOL! Mica e' stato chiesto di mettere un "plug-in" sui proci gia' comprati, ma di avere un NUOVO procio s939 con tale tecnologia.
Che io compro un nuovo procio s939 o sAM2 ad AMD arrivano soldi freschi comunque, solo che in un caso io devo cambiare mobo e ram nell'altro no, ma visto che amd non produce ne' ram ne' chipset per desktop non capisco dove sia il problema che dici tu.

Il fatto e' un altro: vuole incentivare il passaggio ad am2 perche' tanto tra poco tutta la produzione si spostera' su quello... ma il problema non sono certo i proci gia' venduti, questo era ovvio che nascono cosi' e moriranno con quelle features :p

Domanda:
La virtualizzazione non potrebbe in qualche modo intervenire sulle code dei process scheduler?
In questo modo si avrebbe la possibilita' dinamica di variare il pr sch ma non conosco l'argomento in dettaglio... :mc:
Che ne so, magari a livello kernel vengono inserite le 2 tipologie di pr sch (una x applicazioni singleth e l'altra x applicazioni multith) e tramite la virtualizzazione si salta da un tipo all'altro in base alle esigenze del caso.

mio padre che lavora all'IBM ha riportato un computer prototipo con l'ultimo processore inventato da IBM a 500 Ghz..... ragazzi è un siluro! Ho fatto un test facendo avviare nello stesso momento 50 programmi del tipo grafica, audio, video.... insomma di quelli pesanti.... e sapete quanto ci ha messo a caricarli? 1 SECONDO!

ahahahahahahahahahahahahahah ci siete cascatiiiiiiii ahahahahahah
ahahaha 500giga non ci ha creduto nessuno

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.
sarebbe allora meglio invece del dual core un single core con tutte le unità di calcolo raddoppiate, da usare con una tecnologia tipo hyper thread ma col supporto di unità di calcolo realmente multiple.

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
specie se fosse uscita subito insieme ai primi cpu dual....

mio padre che lavora all'IBM ha riportato un computer prototipo con l'ultimo processore inventato da IBM a 500 Ghz.....
350ghz.... :rolleyes:

specie se fosse uscita subito insieme ai primi cpu dual....
Non esageriamo... AMD già dobbiamo ringraziarla per aver introdotto fin dai suoi primi processori a 64bit il pieno supporto a lavorare a 32bit... questo era fondamentale farlo in hardware (grosso coinvolgimento dell'architettura), mentre nel secondo caso la circuiteria viene modificata probabilmente solo in qualche dettaglio, e il problema e' lo sviluppo del software (i drivers), e sappiamo tutti che sviluppare dei drivers del genere non é cosa da poco... Immaginati se per fare ciò avessero tardato a far uscire gli X2 fino ad ora, Intel sarebbe tornata ad avere la leadership da un bel po'... :D

A me pare che con l'arrivo di Conroe, ad AMD siano rimasti solo i videogames...