[Thread Ufficiale] Aspettando Bulldozer *leggere prima pagina con attenzione*

[bicchiere]

Originariamente inviato da cionci

Oak Trail sostituirà la serie Z5xx, quindi non saranno in competizione con Zacate. Il successore di Pine Trail è Cedar Trail, che uscirà nella seconda metà del 2011, oltre all'integrazione di una unità per la codifica e la decodifica dei flussi video, non sembra che introdurrà eccessive novità, forse solo un innalzamento della frequenza.

Le non eccessive novità penso saranno largamente sufficienti, non ti conviene ignorarle

[bjt2]

Originariamente inviato da cionci

Vero che si potrebbe realizzare direttamente nei software settando il thread affinity, ma non sarebbe la stessa cosa in quanto gli altri thread potrebbero venire occupati, anzi sicuramente lo saranno, da altri processi, ad esempio quelli del sistema operativo o di altri programmi. Quindi buona parte del vantaggio si perderebbe.

Non proprio, leggi sopra.
Diventa vantaggioso in tutti quei momenti in cui il multithreading non viene sfruttato adeguatamente o c'è una grossa dipendenza fra i dati.
Ad esempio nei giochi.

Ma se disabiliti i core, quegli stessi processi che indichi tu consumeranno tempo di CPU dei core superstiti, facendo svuotare le caches, i TLB e consumando tempo di CPU. Sarebbe peggio, IMHO...

[cionci]

Originariamente inviato da carlottoIIx6

appunto!!!!!!!!!!!!!!!!!!!!!!!

pensa solo che in idle amd fa 11 w (secondo hu 12 w, ma in altre recensioni 11)
compresa la gpu!!!!!
mentre il su4100 la gpu in idle consuma 0 w solo perchè aimhè non c'è!
quindi in intel il sistema con igp fa come una cpu con gpu!

mi sembra che non ci sia altro da dire
solo sfregarsi le dite... sperando che escano prodotti a poco prezzo

La GPU in idle è praticamente spenta, sia quella del SU4100, che c'è anche se non inclusa nel sistema, sia quella di Zacate.

[bjt2]

Originariamente inviato da paolo.oliva2

Mi sembrava che in passato c'era stata qualche avvisaglia che avrebbero cambiato, in Windows 8, che ormai sarebbe dietro l'angolo.

Il problema è stato risolto da tanto tempo, per colpa dei processori con Hyper Threading. Ci sono due modi per farlo e non so quale è stato fatto...
1) Modificare lo scheduler di Windows: prima riempire i core fisici (pari) e poi i logici (dispari)
2) Cambiare la numerazione dei core da BIOS o da Kernel: prima i fisici e poi i logici...

Facendo la stessa cosa per BD non dovrebbero esserci problemi. Probabilmente ci sarà un setting BIOS o una opzione del driver della CPU o di AOD (magari dipendente dall'applicazione in esecuzione) perchè, contrariamente a HT, non sempre è deleterio riempire prima i moduli, sia per una questione di risparmio energetico (spengo i moduli inutilizzati), sia per la cache L2 condivisa (potrebbero aumentare addirittura le prestazioni)...

[cionci]

Originariamente inviato da bjt2

Ma se disabiliti i core, quegli stessi processi che indichi tu consumeranno tempo di CPU dei core superstiti, facendo svuotare le caches, i TLB e consumando tempo di CPU. Sarebbe peggio, IMHO...

I context switching tanto vengono fatti comunque anche con 8 core per la terminazione del time slice o entrando in attesa su qualche struttura condivisa.

[cionci]

http://www.hwupgrade.it/news/cpu/tec...amd_34478.html

[bjt2]

Originariamente inviato da cionci

I context switching tanto vengono fatti comunque anche con 8 core per la terminazione del time slice o entrando in attesa su qualche struttura condivisa.

Ma non vengono svuotate le caches e i TLB (almeno quelli globali, se non mi sbaglio con i tagged TLB rimangono anche quelli vecchi di un altro processo)...
Se c'è un altro processo si...

[cionci]

Originariamente inviato da bjt2

Ma non vengono svuotate le caches e i TLB (almeno quelli globali, se non mi sbaglio con i tagged TLB rimangono anche quelli vecchi di un altro processo)...
Se c'è un altro processo si...

Ma un altro processo ce lo infilano comunque anche con 8 core, stai pur sicuro.

[capitan_crasy]

Originariamente inviato da cionci

http://www.hwupgrade.it/news/cpu/tec...amd_34478.html

Notizia di Hwupgrade del 19.11.2011

In occasione del proprio Financial Analyst Day AMD ha anticipato l'intenzione di passare alla produzione utilizzando tecnologia produttiva a 28 nanometri per futuri prodotti attesi al debutto per la fine del prossimo anno. Ci riferiamo nello specifico alle APU Krishna e Wichita, soluzioni con un numero di core variabile da 1 a 4 basate su architettura Bobcat destinate a sistemi desktop di ridotte dimensioni e a notebook.

Quale sarà l'azienda produttiva partner di AMD per queste soluzioni, tra GlobalFoundries e TSMC? La risposta è estremamente chiara: la tecnologia produttiva scelta da AMD è quella high-k metal gate first, che verrà sviluppata da GlobalFoundries. Con questo partner, pertanto, AMD produrrà sia chip a 32 nanometri come le soluzioni Bulldozer e quelle Llano, sia futuri prodotti a 28 nanometri. La notizia è stata confermata dalla stessa AMD all'interno della sessione di Q&A del proprio Financial Analyst Day.

Questo processo produttivo verrà messo a disposizione dei propri partner anche dalla taiwanese TSMC, utilizzando tuttavia una tecnica gate-last sempre con interconnessioni high-k metal gate che presumiamo saranno adottate per la produzione di chip mobile oltre che per GPU di fascia alta.

Al momento attuale AMD utilizza tecnologia produttiva a 40 nanometri con TSMC per la produzione delle proprie GPU delle serie ATI Radeon HD 5000 e HD 6000; nel passaggio a processo a 28 nanometri non è chiaro se verrà scelto come partner GlobalFoundries oppure TSMC per questa tipologia di prodotti.

[Pihippo]

Originariamente inviato da bjt2

Ma non vengono svuotate le caches e i TLB (almeno quelli globali, se non mi sbaglio con i tagged TLB rimangono anche quelli vecchi di un altro processo)...
Se c'è un altro processo si...

Ciao
Bjt2, se si ha un context switch la TLB viene completamente flushata, non vi sono grosse penalità poichè "di solito" ogni entry della tlb è taggata con un asn e dunque solo le entrate della tlb con un numero asn che è uguale al numero del processo in esecuzione sono considerate valide, salvate nel registro cr3 (tipicamente nei 20 bit inferiori del registro) e poi ricaricate al resume del vecchio processo. Questo in genere impedisce che un caricamento di cr3 o context switch flushi entries molto usate presenti nella tlb, cosa che comporterebbe (se nessuna tlb ha l'entry corretta) un page walking che costa in termini di energia spesa e non è velocissimo

[cionci]

Originariamente inviato da Pihippo

Ciao
Bjt2, se si ha un context switch la TLB viene completamente flushata, non vi sono grosse penalità poichè "di solito" ogni entry della tlb è taggata con un asn e dunque solo le entrate della tlb con un numero asn che è uguale al numero del processo in esecuzione sono considerate valide, salvate nel registro cr3 (tipicamente nei 20 bit inferiori del registro) e poi ricaricate al resume del vecchio processo. Questo in genere impedisce che un caricamento di cr3 o context switch flushi entries molto usate presenti nella tlb, cosa che comporterebbe (se nessuna tlb ha l'entry corretta) un page walking che costa in termini di energia spesa e non è velocissimo

Mi stupisci sempre di più. Sei un ingegnere AMD sotto copertura ? Ho quasi capito tutto
In effetti mi pareva strano che non ci fosse un flush del TLB al momento del context switching. Però, sai, sono anni che non vedo questa roba.

[Pihippo]

Originariamente inviato da cionci

Mi stupisci sempre di più. Sei un ingegnere AMD sotto copertura ? Ho quasi capito tutto
In effetti mi pareva strano che non ci fosse un flush del TLB al momento del context switching. Però, sai, sono anni che non vedo questa roba.

Ciao
grazie per i complimenti , no non sono un ingegnere amd
Altrimenti avrei fatto andare bobcat a 3ghz come minimo
Però pian pianino i clock verranno su

[paolo.oliva2]

Comunque AMD non finisce di stupire con il suo silicio.

Se rifacessimo i calcoli del guadagno tra il 45nm ed 32nm HKMG low-k... a breve AMD commercializzerebbe il 1075T che è un esacore a 3GHz a 95W TDP (in barba alle previsioni di un esacore a 3GHz a 140W TDP)

Su questo dato, il 50% in meno di TDP a parità di performances dichiarato nel passaggio a 32nm, farebbe letteralmente schizzare le previsioni alle stelle la stessa potenza di un 1075T in poco più di 45W... o se vogliamo, potenza doppia allo stesso TDP.

[checo]

Originariamente inviato da paolo.oliva2

Comunque AMD non finisce di stupire con il suo silicio.

Se rifacessimo i calcoli del guadagno tra il 45nm ed 32nm HKMG low-k... a breve AMD commercializzerebbe il 1075T che è un esacore a 3GHz a 95W TDP (in barba alle previsioni di un esacore a 3GHz a 140W TDP)

Su questo dato, il 50% in meno di TDP a parità di performances dichiarato nel passaggio a 32nm, farebbe letteralmente schizzare le previsioni alle stelle la stessa potenza di un 1075T in poco più di 45W... o se vogliamo, potenza doppia allo stesso TDP.

frena frena.....

50% in meno a partità di performance, ma non a aprità di architettura però!

[cionci]

Originariamente inviato da paolo.oliva2

Su questo dato, il 50% in meno di TDP a parità di performances dichiarato nel passaggio a 32nm, farebbe letteralmente schizzare le previsioni alle stelle la stessa potenza di un 1075T in poco più di 45W... o se vogliamo, potenza doppia allo stesso TDP.

L'aumento del TDP non è lineare rispetto alla potenza.

[bjt2]

Originariamente inviato da cionci

Ma un altro processo ce lo infilano comunque anche con 8 core, stai pur sicuro.

Esatto. Processo che in un quad core avrebbe ingolfato uno degli altri core che invece servono all'applicazione principale... Invece in un octacore BD usa parte del front end e della FPU, ma poi le unità intere e la memoria vanno in un core a parte...

[bjt2]

Originariamente inviato da Pihippo

Ciao
Bjt2, se si ha un context switch la TLB viene completamente flushata, non vi sono grosse penalità poichè "di solito" ogni entry della tlb è taggata con un asn e dunque solo le entrate della tlb con un numero asn che è uguale al numero del processo in esecuzione sono considerate valide, salvate nel registro cr3 (tipicamente nei 20 bit inferiori del registro) e poi ricaricate al resume del vecchio processo. Questo in genere impedisce che un caricamento di cr3 o context switch flushi entries molto usate presenti nella tlb, cosa che comporterebbe (se nessuna tlb ha l'entry corretta) un page walking che costa in termini di energia spesa e non è velocissimo

Mi ricordavo sta cosa dei tag...

[bjt2]

Originariamente inviato da cionci

L'aumento del TDP non è lineare rispetto alla potenza.

Infatti dalle slides GF è "solo" il 40% di clock in più a parità di TDP... Segno che il processo 32 nm è quasi lineare e comunque ottimo... Questo perchè l'HKMG consente di avere clock più elevato anche con minore Vcore (molto minore, a parità di clock...) e quindi a ridurre sia la potenza dinamica che quella statica (leackage)... Da qui il calcolo dei 6GHz come limite superiore di clock a default per un modulo BD che ho fatto qualche pagina fa...

[Pihippo]

Originariamente inviato da bjt2

Infatti dalle slides GF è "solo" il 40% di clock in più a parità di TDP... Segno che il processo 32 nm è quasi lineare e comunque ottimo... Questo perchè l'HKMG consente di avere clock più elevato anche con minore Vcore (molto minore, a parità di clock...) e quindi a ridurre sia la potenza dinamica che quella statica (leackage)... Da qui il calcolo dei 6GHz come limite superiore di clock a default per un modulo BD che ho fatto qualche pagina fa...

Ciao Bjt2
Se saranno effettivamente 6ghz, come vedresti la competizione con sb anche se questo dovesse (che secondo me avrà, ma son cassate) un ipc di media (no benchmarketig con codice pieno di shuffle avx ma scommetto che futuremark ci proverà comunque ) del 10-15% superiore a Bd?
Io la vedrei molto critica per sb, ovvero doppi per bd, ipc vicino per ambedue, ma un 25% di clock in più per bd

[bjt2]

Originariamente inviato da Pihippo

Ciao Bjt2
Se saranno effettivamente 6ghz, come vedresti la competizione con sb anche se questo dovesse (che secondo me avrà, ma son cassate) un ipc di media (no benchmarketig con codice pieno di shuffle avx ma scommetto che futuremark ci proverà comunque ) del 10-15% superiore a Bd?
Io la vedrei molto critica per sb, ovvero doppi per bd, ipc vicino per ambedue, ma un 25% di clock in più per bd

Per i 6GHz, ribadisco che è un limite superiore per il turbo a 1 sol modulo e raggiungibile a processo maturo (dubito che i primi BD sfornati ci arrivino, OC a parte). Per quanto riguarda l'IPC: se supponiamo che gli scheduler, i branch predictor e i prefetcher siano inteligenti quanto quelli del SB, visto che INT e FP viaggiano su binari separati e che BD ha per ogni core più porte di INTEL e non condivise, l'IPC del BD potrebbe addirittura essere superiore. Supponendo che AMD NON possa essere superiore alla magnifica INTEL (per congiuntura astrale o solo perchè gli ingegniiiiiiiiiiiiieri INTEL sono i più migliori del mondo), prevedo che il delta di clock compensi abbondantemente le differenze eventuali di IPC (a meno che anche gli ingegniiiiiiiiieri del processo produttivo INTEL siano i più migliori del mondo e AMD non riesca a superare i 4GHz neanche con il turbo...) ( ... scusate... E da un po' che volevo essere così sarcastico visto la miriade di gente pessimista in questo thread... Non ce l'ho assolutamente con te... )