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

[digieffe]

Originariamente inviato da paolo.oliva2

Veramente non ci capiamo....

Ribalto con questa domanda. Quanto renderà di più un BD CMT X8 rispetto ad un BD CMT X6 in MT? Concordi che sarà più del 7% o no?

Originariamente inviato da calabar

In questo caso direi, supponendo uno scaling perfetto sul numero dei core (situazione che sappiamo non essere la norma), che l'incremento sarebbe banalmente del 25%.

avevo intuito l'equivoco di Paolo, cmq forse volevi dire 33% in situazione "teoricamente perfetta"

Originariamente inviato da marchigiano

jf diceva che conviene usare 2 thread su un modulo piuttosto che un thread su due moduli perchè possono sfruttare la L2 condivisa

poi se è vero non lo so

forse 2 thread dello stesso processo SI, in quanto avrebbero la possibilità di agire sugli stessi dati nella L2 condivisa,
credo di NO per 2 thread di processi differenti o dello stesso processo ma che trattano dati diversi in quanto la cache sarebbe riempita di set di dati differenti col rischio di perdere di efficienza

[calabar]

Originariamente inviato da digieffe

avevo intuito l'equivoco di Paolo, cmq forse volevi dire 33% in situazione "teoricamente perfetta"

Oops, si certo ovviamente.

[digieffe]

Originariamente inviato da Veradun

Quello che non afferri è che la prima e la seconda questione riguardano entrambe le scelte architetturali. L'IPC è quello di una architettura, ed in questo è già considerata qualunque perdita prestazionale dovuta a scelte di privilegiare altro (die size, per esempio). Quindi nell'ipotesi che l'IPC sia lo stesso del K10, non c'è da moltiplicare per nessun 80%, perché fa già parte dell'architettura.



I due core di un modulo hanno certe prestazioni perché progettati in un certo modo, il fatto che il secondo sia attivo o meno non cambia le prestazioni del singolo core non cambia le prestazioni in peggio, ma più facilmente in meglio a causa dell'esclusività delle risorse condivise.



Secondo AMD. Ovviamente è una elucubrazione non esistendo alcun BD senza CMT.

Originariamente inviato da Veradun

Non e' che mi sbaglio, lo ha detto AMD. Ora si possono prendere due strade, non credere ad AMD, quindi nemmeno all'80% e lasciar cadere tutto il discorso oppure credere a quello che scrivono loro e quindi anche a questo.

L'80% e' rispetto ad un'architettura ipotetica che non esiste, non c'e' nessun 80% da applicare a niente per fare delle simulazioni dei poveri, e' un numero che non ha alcuna attinenza con la realta' effettiva e dato in risposta a chi chiese "ma non conveniva farlo normale invece che CMT?"

Riguardo al discorso "handicap": progettare una CPU (ma anche una GPU, un chip in generale) e' una sfida che mette continuamente un progettista di fronte a scelte fra occupazione di area, consumi, rese produttive, performance. Tutte insieme non si possono avere "gratis". L'SMT di Intel e' una scelta che consuma spazio e non stabilmente conveniente quanto a performance. Al posto di quello spazio potevano metterci piu' cache, o alzare la frequenza, ma evidentemente i tradeoff scelti non hanno dato risultati scadenti.



L'architettura e' una sola, non cambia al variare del carico di lavoro e quel conto non ha senso alcuno. Quel conto rappresenta la differenza fra il BD che uscira' di qui a poco rispetto ad un ipotetico BD mai esistito senza CMT in un carico multithreaded. L'IPC dei core di BD sara' lo stesso in MT e ST, salvo pochi percento dovuti all'esclusivita' del condiviso, situazione che fra le altre cose non si verifichera' mai nel mondo reale, perche' anche in un carico di due threads si spegneranno tutti i moduli escluso uno, che continuera' a condividere le risorse fra i due core, proprio perche' lo svantaggio prestazionale nel fare cosi' rispetto a distribuire i thread su tutti i moduli prima di fare il secondo giro di riempimento e' sovrabbondantemente ripagato dalla possibilita' di aumentare il turbo grazie al risparmio energetico ottentuo spengendo l'inutile.

finalmente anche con l'aiuto di calabar ho capito dov'era il punto...
vado a rivedere un pò di materiale mi hai messo il dubbio

[The3DProgrammer]

Originariamente inviato da marchigiano

jf diceva che conviene usare 2 thread su un modulo piuttosto che un thread su due moduli perchè possono sfruttare la L2 condivisa

poi se è vero non lo so

se i thread lavorano sugli stessi dati, è + conveniente farli eseguire nello stesso modulo. se i thread lavorano su dati totalmente diversi o sono di due applicazioni diverse, conviene farli eseguire su 2 moduli diversi. e' spiegato nelle 20 domande su bd linkate prima - ed è anche abbastanza ragionevole.

[paolo.oliva2]

Originariamente inviato da marchigiano

jf diceva che conviene usare 2 thread su un modulo piuttosto che un thread su due moduli perchè possono sfruttare la L2 condivisa

poi se è vero non lo so

Ma infatti è proprio questo il punto che ho affrontato nel mio post precedente.

Noi stiamo prendendo in considerazione che 2 core non condivisi sarebbero più potenti perché indipendenti, e questo lo concorda pure AMD, ma bisogna vedere bene se nel calcolo puro o nel totale. Ad esempio, come hai detto tu, il fatto di ricercare dei dati (AMD ha la L2-L3 esclusiva e non inclusiva) porterebbe tempi superiori perché un conto sarebbe cercare il dato tra 1 L2 e L3 del modulo ed un altro cercare lo stesso dato in tutte le l2 e nella totalità della L3 del procio.

Il confronto è relativamente semplice: se prendessimo 4 TH e li distribuissimo 1 a modulo, avremmo la condizione che il CMT non influenzerebbe per nulla ma ciò porterebbe il procio lavorare ad una frequenza def.

Invece se il procio lavorasse con 2 moduli completi e 4 TH, la frequenza aumenterebbe di 600MHz, cioè la frequenza accreditata al Turbo.

8150p (3,6GHz) + 600MHz = 16,66%
8170p (3,9GHz) + 600MHz = 15,3%

Quindi, o JF ha sparato -20% prendendo in considerazione UNICAMENTE i contro senza valutare i pro (tipo ricerca dati nelle cache ed altro ancora) o comunque forse ha sparato un valore massimo nelle condizioni più negative visto che quel valore dato all'impatto del CMT in ogni caso deve essere inferiore a -15,3%, quindi ben inferiore al 20%.

Edit:

Originariamente inviato da The3DProgrammer

se i thread lavorano sugli stessi dati, è + conveniente farli eseguire nello stesso modulo. se i thread lavorano su dati totalmente diversi o sono di due applicazioni diverse, conviene farli eseguire su 2 moduli diversi. e' spiegato nelle 20 domande su bd linkate prima - ed è anche abbastanza ragionevole.

E qui già avremmo condizioni differenti, quindi è già da ritenere che il valore -20% non può essere una costante ma forse da considerari "fino al" -20%.

[marchigiano]

Originariamente inviato da calabar

Intendevi forse dire 2 thread su due moduli?
Ovvio che un thread su due moduli vada meno... userebbe un solo core di un solo modulo!

si intendevo 2 thread uno per modulo

Originariamente inviato da digieffe

forse 2 thread dello stesso processo SI, in quanto avrebbero la possibilità di agire sugli stessi dati nella L2 condivisa,
credo di NO per 2 thread di processi differenti o dello stesso processo ma che trattano dati diversi in quanto la cache sarebbe riempita di set di dati differenti col rischio di perdere di efficienza

questa è una buona osservazione, ma alla fine non penso esistano dei scheduler talmente intelligenti da capire come è meglio suddividere i thread, quindi avranno simulato vari carichi di lavoro e scelto l'approccio MEDIAMENTE migliore, questo vuol dire che non sempre sarà ottimizzato al massimo

[paolo.oliva2]

Posto questo, ma non sao se sia già stato postato o sia una bufala.

Comunque... è un 8130p, portato ancora ad aria a 5,13GHz

http://lenzfire.com/2011/07/amd-bull...-reach-5-1ghz/

Questo artico è già stato postato ma consiglio di leggere le ultime 3 righe visto le discussioni circa "momento non propizio" per BD.

http://www.bit-tech.net/news/hardwar...he-next-week/1

[Matalf]

Originariamente inviato da paolo.oliva2

Posto questo, ma non sao se sia già stato postato o sia una bufala.

Comunque... è un 8130p, portato ancora ad aria a 5,13GHz

http://lenzfire.com/2011/07/amd-bull...-reach-5-1ghz/

Per quello che si vede nello screen penso che a 4,6GHz il punteggio sia circa 7...


un po pochino in somma, lo prendo per un fake e mi metto il quore in pace

[Claudio-x64]

un po pochino in somma, lo prendo per un fake e mi metto il quore in pace

[digieffe]

Originariamente inviato da marchigiano

si intendevo 2 thread uno per modulo



questa è una buona osservazione, ma alla fine non penso esistano dei scheduler talmente intelligenti da capire come è meglio suddividere i thread, quindi avranno simulato vari carichi di lavoro e scelto l'approccio MEDIAMENTE migliore, questo vuol dire che non sempre sarà ottimizzato al massimo

non sono certo ma, se i due core di un modulo fossero dichiarati come core logici (ugualmente a quanto accade con l'ht della controparte),
lo scheduler saprebbe che hanno parti condivise (anche se dovrebbe comunque conoscere le relazioni gerachiche nella cpu, per funzioni qual core parking, ecc)

però anche conoscendo la struttura della cpu, sapere come allocare i thread che operano sugli stessi dati...

non so se esiste, dovrebbero fare una chiamata di sistema da utilizzare nei programmi per indicare allo scheduler che 2 thread operano sullo stesso set di dati...
altrimenti l'unica distinzione possibile è solo che i thread appartengono a 2 processi diversi... (il che farebbe solo supporre che operino su dati diversi)

poi c'è un altro fattore: se mettendo insieme thread di 2 processi diversi sullo stesso modulo è possibile spegnerne un altro ed incrementare il clock addirittura da apportare vantaggi...

servirebbe uno scheduler apposito con driver specifico per la cpu, tale da valutare tutti questi casi...

speriamo che con windows 8 facciano qualcosa...
con Linux a parte ilnumero di scheduler disponibili, qualche tweak si trova sempre

[digieffe]

Originariamente inviato da Matalf

Per quello che si vede nello screen penso che a 4,6GHz il punteggio sia circa 7...


un po pochino in somma, lo prendo per un fake e mi metto il quore in pace

per pura curiosità: da dove deduci il 7? c'è qualche indicatore che s'intravede?

[marchigiano]

Originariamente inviato da paolo.oliva2

Posto questo, ma non sao se sia già stato postato o sia una bufala.

Comunque... è un 8130p, portato ancora ad aria a 5,13GHz

http://lenzfire.com/2011/07/amd-bull...-reach-5-1ghz/

non dirmi che non hai visto il 6.5ghz ad azoto

Originariamente inviato da digieffe

servirebbe uno scheduler apposito con driver specifico per la cpu, tale da valutare tutti questi casi...

più che altro servirebbe una patch per ogni software sviluppata dalla propria software house per forzare l'uso dei core nel modo più redditizio, un lavoraccio mica da ridere... non penso lo faranno subito ma col passare dei mesi

[capitan_crasy]

Originariamente inviato da paolo.oliva2

Posto questo, ma non sao se sia già stato postato o sia una bufala.

Comunque... è un 8130p, portato ancora ad aria a 5,13GHz

http://lenzfire.com/2011/07/amd-bull...-reach-5-1ghz/

Questo artico è già stato postato ma consiglio di leggere le ultime 3 righe visto le discussioni circa "momento non propizio" per BD.

http://www.bit-tech.net/news/hardwar...he-next-week/1

Old, Step B0...
Tieni buono la scimmia paolo, ormai manca poco...

[digieffe]

Originariamente inviato da marchigiano

non dirmi che non hai visto il 6.5ghz ad azoto



più che altro servirebbe una patch per ogni software sviluppata dalla propria software house per forzare l'uso dei core nel modo più redditizio, un lavoraccio mica da ridere... non penso lo faranno subito ma col passare dei mesi

era ciò a cui mi riferivo con questa frase:
"non so se esiste, dovrebbero fare una chiamata di sistema da utilizzare nei programmi per indicare allo scheduler che 2 thread operano sullo stesso set di dati..."

chiaramente non mi aspetto che sia il software ad indicare in che modo utilizzare i core
ma solo che possa indicare al SO che 2 o più thread operano sugli stessi dati
dopo sarà lo scheduler in base alla CPU a regolarsi di conseguenza
non credo sia tando difficile da implementare dal lato del software (nella creazione del thread ci sarebbe un campo in più es: "gruppo_dati")
il fatto e che lo scheduler deve essere predisposto (ma chissa che già non esista -in Linux- controllo)

per il resto, con l'affinità dei processi verso i core, già si può fare da software ma in questo modo il software deve conoscere la struttura della CPU e sarebbe pesante e non standard da implementare


UPDATE: esludendo windows, sembrerebbe che esistano una serie di strumenti e modi per bloccare sia i thread sia le pagine dei dati ad un certo core... questo dai sistemi Posix (Linux, Unix, ...) a quelli proprietari IBM, non ancora ho capito se si può fare in automatico o solo in modo esplicito, il che comporterebbe fatica.

[marchigiano]

Originariamente inviato da capitan_crasy

Old, Step B0...
Tieni buono la scimmia paolo, ormai manca poco...

ma alle redazioni sono arrivate le cpu da testare?

[capitan_crasy]

Originariamente inviato da marchigiano

ma alle redazioni sono arrivate le cpu da testare?

Dovresti chiederlo a gianni...

[paolo.oliva2]

Originariamente inviato da capitan_crasy

Old, Step B0...
Tieni buono la scimmia paolo, ormai manca poco...

Te hai ragione... ma è dura
Comunque... a meno che AMD/NDA non abbiano preso a busta paga i servizi segreti di tutto il mondo e/o che abbiano i magazzini pieni e comincino le spedizioni il 1° settembre, dubito per una reperibilità di BD prima di 2 settimane... mi sa che si va quasi a fine settembre.

[Wawacco]

Arrivà prima la disponibilità che le recensioni

[Polpi_91]

toto paper lunch: io scommetto tra il 12 e il 16 settembre

[crazyduck00]

Originariamente inviato da digieffe

non sono certo ma, se i due core di un modulo fossero dichiarati come core logici (ugualmente a quanto accade con l'ht della controparte),
lo scheduler saprebbe che hanno parti condivise (anche se dovrebbe comunque conoscere le relazioni gerachiche nella cpu, per funzioni qual core parking, ecc)

però anche conoscendo la struttura della cpu, sapere come allocare i thread che operano sugli stessi dati...

non so se esiste, dovrebbero fare una chiamata di sistema da utilizzare nei programmi per indicare allo scheduler che 2 thread operano sullo stesso set di dati...
altrimenti l'unica distinzione possibile è solo che i thread appartengono a 2 processi diversi... (il che farebbe solo supporre che operino su dati diversi)

poi c'è un altro fattore: se mettendo insieme thread di 2 processi diversi sullo stesso modulo è possibile spegnerne un altro ed incrementare il clock addirittura da apportare vantaggi...

servirebbe uno scheduler apposito con driver specifico per la cpu, tale da valutare tutti questi casi...

speriamo che con windows 8 facciano qualcosa...
con Linux a parte ilnumero di scheduler disponibili, qualche tweak si trova sempre

BINGO !
I processi applicativi sono gestiti dall'os, basterebbe soltanto che:
quando vede un processo appartenente allo stessa applicazione la manda sul core libero del modulo dove c'è l'altro core che processa il processo della stessa applicazione, se vede invece un processo appartenente ad un altra applicazione lo spara su un core di un altro modulo.
Non è difficile, e non sarà il software a gestire questo, niente patch ai software e nulla di complicato per chi li scrive, niente di tutto questo.
Linux già lo fa di suo, e tutto questo è gia implentato all'interno del kernel.

era ciò a cui mi riferivo con questa frase:
"non so se esiste, dovrebbero fare una chiamata di sistema da utilizzare nei programmi per indicare allo scheduler che 2 thread operano sullo stesso set di dati..."

chiaramente non mi aspetto che sia il software ad indicare in che modo utilizzare i core
ma solo che possa indicare al SO che 2 o più thread operano sugli stessi dati
dopo sarà lo scheduler in base alla CPU a regolarsi di conseguenza
non credo sia tando difficile da implementare dal lato del software (nella creazione del thread ci sarebbe un campo in più es: "gruppo_dati")
il fatto e che lo scheduler deve essere predisposto (ma chissa che già non esista -in Linux- controllo)

per il resto, con l'affinità dei processi verso i core, già si può fare da software ma in questo modo il software deve conoscere la struttura della CPU e sarebbe pesante e non standard da implementare


*UPDATE: esludendo windows, sembrerebbe che esistano una serie di strumenti e modi per bloccare sia i thread sia le pagine dei dati ad un certo core... questo dai sistemi Posix (Linux, Unix, ...) a quelli proprietari IBM, non ancora ho capito se si può fare in automatico o solo in modo esplicito, il che comporterebbe fatica.

Ma il software non centra niente infatti. Non è il software che deve riconsocere la struttura della cpu ma è' il sistema operativo a gestire i processi delle applicazioni software, e quindi a distribuire i processi all'elaborazione sui vari core e moduli della cpu, sfruttando la logica del core occupato. Se CORE.0 è occupato da un processo mando quest'altro su CORE.1 ... per il caso BD e i suoi moduli basta un aggiornamento al kernel di windows 7 non serve windows 8 per una cosa cosi banale.

*UPDATE Linux non ha bisogno di nessun aggiornamento invece perchè questa logica la implementa gia nel kernel.