L'anti HT di AMD si fa più vicino

[JohnPetrucci]

Originariamente inviato da 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

In effetti attualmente e per qualche anno ancora direi che la si può vedere così, quindi questa tecnologia di Amd non è affatto azzardata.

[Snyto]

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

[adynak]

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.

[xeal]

Originariamente inviato da cionci

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

[Kralizek]

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)

[K Reloaded]

praticamente un raid0 x le cpu?

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

[Sawato Onizuka]

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

[K Reloaded]

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

[cionci]

Originariamente inviato da K Reloaded

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

[GrrPulcy]

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)

[K Reloaded]

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

[giovanbattista]

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.

[Sayan V]

Originariamente inviato da K Reloaded

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

Ovviamente

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.

[DakmorNoland]

Originariamente inviato da Sayan V

Ovviamente

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.

[gianni1879]

Originariamente inviato da K Reloaded

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

sarabbe un bel colpo



.....sognamo va.....

[jappilas]

Originariamente inviato da 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....

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

Originariamente inviato da Kralizek

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

[blackshard]

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!

[gianni1879]

Originariamente inviato da blackshard

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

[xeal]

Originariamente inviato da gianni1879

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 inc@z..rebbe 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.

[jappilas]

Originariamente inviato da xeal

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)