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

[digieffe]

con 5000 cicli di una cpu a 2 ghz si riuscirebbe a scrivere in una ram da 10GB/s 25k, sicuramente di più in una L3 e più ancora in L2.

non ne sono sicuro, mi sembra di aver letto che lo stato di un core di una cpu moderna è circa 45k, che possa dipendere da ciò ???

Originariamente inviato da capitan_crasy

Clicca qui...

Grazie Lab!
Ne approfitto per chiederti se hai trovato qualcosa di BD sul quel BIOS Beta di MSI...

Per il momento niente di nuovo, ho scaricato il lavoro ai cruki visto che ho pochissimo tempo libero, il lavoro mi uccide!

P.S. Visto che non riesco a seguire il Th, se hai bisogno contattami in PVT, giorni fà (sabato 16/04/2011 13:15) ti ho inviato una mail con le info del bios, non ti è arrivata?

[Pihippo]

Originariamente inviato da cionci

Di solito il compilatore più performante è quello Intel, dubito che nVidia non lo usi.
Dici che non sia traumatico ? Secondo te ci sono poche istruzioni SIMD in un driver video ? Te lo chiedo perché sinceramente non ne ho idea.

Ciao
Mi sono espresso male
Dico che il team nvidia potrebbe aggiornare il compilatore usato a quest'ultimo che magari non presenta le deottimizzazioni. Un driver è un misto di tante cose tra cui anche un pò di simd.

Originariamente inviato da digieffe

ciao,
nella mia ignoranza provo a fare 2 calcoli...
con linux kernel 2.6.35, cpu in idle ho circa 1000 context switch al secondo (1 solo core attivo) 1000*5000=5.000.000 allora se è così la cpu perde 5 mhz a girarsi i pollici? se faccio fare degli accessi al disco salgo a 3000 se aggiungo il play un video da youtube (streaming rete + visualizzazione) e faccio ballare le finestre 3d a video arrivo a 8000 quindi arriverei a perdere 40 mhz (40M cicli).

Bingo ogni istanza di glxgears (diagnostico sistema grafico x) mi genera circa 4000 cambi di contesto al secondo. (20M cicli persi)

.... mmm .... premesso che stiamo parlando di sistemi diversi è come se il caso nvidia riuscisse a fare meno chiamate al kernel space

ps: senza intenzione di voler mettere in dubbio ciò ch scrivi ma per capire, come si formano quei 5000 cicli?

Ciao
La questione è complicata, anche perchè winzoz funziona in modo diverso da linux (purtroppo o meno male non sta a me dirlo) Ora tutto quello che scriverò da qui in giu è inesatto e\o sbagliato però potrebbe essere utile per farsi una mezza idea.
Partiamo dal fatto che quello che ammazza un pò le performances è lo switching dei ring (user\kernel mode) e purtroppo ciò avviene per quasi ogni draw call (la cpu carica i dati necessari alla gpu per processarli).
Dunque per ogni draw call il driver se ne va nel kernel mode.
I 5000 cicli sono dovuti al fatto che in winzozz tutte le chiamate dell'api non sono del tipo call+ret + switch del ring ( cosa che costerebbe circa 220 cicli secondo il manuale amd64 ) ma sono basati sugli interruttori! quindi altro overhead dovuto a dover passare per tutto lo stack del driver Abbiamo appena totalizzato circa 5000 (se non il doppio ovvero 10000 cicli ma non trovo più il doc della MS) cicli a fare un tubazzo! Per non parlare poi del fatto che l'api stessa (d3d) deve costruire i command buffer ovvero la lista dei comandi per la gpu passarli al driver il quale poi li trasforma in qualcosa di comprensibile per la gpu.
Tutto ciò si ha per quasi ogni draw call
(c'è da dire che ho letto che le dx11 pare siano progettate meglio per quanto riguarda il cpu overhead sia dal punto di vista degli switch dei ring sia per i command buffer)

[digieffe]

Originariamente inviato da Pihippo

Ciao
La questione è complicata, anche perchè winzoz funziona in modo diverso da linux (purtroppo o meno male non sta a me dirlo) Ora tutto quello che scriverò da qui in giu è inesatto e\o sbagliato però potrebbe essere utile per farsi una mezza idea.
Partiamo dal fatto che quello che ammazza un pò le performances è lo switching dei ring (user\kernel mode) e purtroppo ciò avviene per quasi ogni draw call (la cpu carica i dati necessari alla gpu per processarli).
Dunque per ogni draw call il driver se ne va nel kernel mode.
I 5000 cicli sono dovuti al fatto che in winzozz tutte le chiamate dell'api non sono del tipo call+ret + switch del ring ( cosa che costerebbe circa 220 cicli secondo il manuale amd64 ) ma sono basati sugli interruttori! quindi altro overhead dovuto a dover passare per tutto lo stack del driver Abbiamo appena totalizzato circa 5000 (se non il doppio ovvero 10000 cicli ma non trovo più il doc della MS) cicli a fare un tubazzo! Per non parlare poi del fatto che l'api stessa (d3d) deve costruire i command buffer ovvero la lista dei comandi per la gpu passarli al driver il quale poi li trasforma in qualcosa di comprensibile per la gpu.
Tutto ciò si ha per quasi ogni draw call
(c'è da dire che ho letto che le dx11 pare siano progettate meglio per quanto riguarda il cpu overhead sia dal punto di vista degli switch dei ring sia per i command buffer)

tenendo conto che ciò che hai scritto può essere "è inesatto e\o sbagliato" vorrei sincronizzare alcuni termini o concetti:
- switching dei ring (user\kernel mode) : normalmente 3\0.
- draw call = chiamata a direct x, al driver o coincidono?
- interruttori = software irq o qualcos'altro?
- stack del driver = intendi una struttura LIFO o una serie di call?


ps: in 220 cicli salva tutto lo stato della cpu???

grazie

[paolo.oliva2]

Domandona:

Dicembre 2010, primi ES Buldozer, presuminilmente step A1 ed in coincidenza slittamento di Llano dato per settembre 2011.

Ora si viene a sapere di uno step B0 per BD e che gli ES di questo step sono in consegna questi giorni, presumibilmente dovrebbero essere ES pre-produzione.

Quando AMD passò nel 45nm dal "liscio" al low-k, cambiò denominazione da C3 a E0.

Sarebbe interessante sapere se anche Llano abbia cambiato la lettera dello step.

Considerando che uno step richiede circa 6 mesi e che il tempo sia dall'ES Buldozer A1 che dai primi ES di Llano coincidono per questo lasso di tempo, non potrebbe essere che quanto visto fino ad ora fosse 32nm HKMG e che la produzione sarà 32nm HKMG ULK come AMD/GF hanno sempre attribuito per il 32nm?

In tutti i casi, ULK e non, realizzare uno step ulteriore porta sempre con sè miglioramenti.

[bicchiere]

Originariamente inviato da cionci

Di solito il compilatore più performante è quello Intel

Fonte?

Per quanto riguarda i giochi, quasi tutti ti installano il Visual C++ redistributable, quindi presumo che il compilatore Microsoft domini
con tutto ciò che abbia a che fare con DirectX.

Il compilatore Intel viene usato quando interessa la portabilita' del software (Mathematica etc...) in quanto è disponibile anche per il pinguino, ed è molto superiore al GCC. Ma assolutamente non credo sia il compilatore piu' usato (e nemmeno quello piu' performante)

[Tenebra]

Dubbio un po' di basso livello: non ho ancora capito se bisognerà attendere la presentazione di Bulldozer o se è già noto quali saranno le ram "migliori" (in ottica OC) da abbinare a BD e relativa mobo con chipset AM3+.
Sapete com'è, nell'attesa comincio a ipotizzarmi il preventivo cpu+mobo+ram

[capitan_crasy]

Originariamente inviato da Labview

Per il momento niente di nuovo, ho scaricato il lavoro ai cruki visto che ho pochissimo tempo libero, il lavoro mi uccide!

P.S. Visto che non riesco a seguire il Th, se hai bisogno contattami in PVT, giorni fà (sabato 16/04/2011 13:15) ti ho inviato una mail con le info del bios, non ti è arrivata?

Sembrava di no, invece ho dato un occhiata alle ultime mail e ti ho trovato come spam!
Quindi ancora nessuna traccia di BD sui BIOS MSI; grazie per la consulenza...

[Pihippo]

Originariamente inviato da digieffe

tenendo conto che ciò che hai scritto può essere "è inesatto e\o sbagliato" vorrei sincronizzare alcuni termini o concetti:
- switching dei ring (user\kernel mode) : normalmente 3\0.
- draw call = chiamata a direct x, al driver o coincidono?
- interruttori = software irq o qualcos'altro?
- stack del driver = intendi una struttura LIFO o una serie di call?


ps: in 220 cicli salva tutto lo stato della cpu???

grazie

Ciao
Ripremetto quelle che tu giustamente hai quotato: Cio che scrivo potrebbe essere inesatto, vediamo se riesco ad indovinare qualcosa
1) Mi sa che ci siamo intesi
2) Draw Call = L'applicazione chiama l'api e quest'ultima il driver.
3) Intendo dal punto di vista della cpu istruzioni come INT e SYSCALL che sono molto più costose che chiamare una funzione con call+ret. Comunque intendo proprio il software interrupt generato da una combinazione di istruzioni eseguite dal processore stesso (INT e SYSCALL).
Per il ps secondo il manuale in 220 cicli circa si salva tutto e si cambia pure ring

[Ishiki Takai]

Originariamente inviato da Tenebra

Dubbio un po' di basso livello: non ho ancora capito se bisognerà attendere la presentazione di Bulldozer o se è già noto quali saranno le ram "migliori" (in ottica OC) da abbinare a BD e relativa mobo con chipset AM3+.
Sapete com'è, nell'attesa comincio a ipotizzarmi il preventivo cpu+mobo+ram

Quoto Tenebra dato che pure io stò progettando la mia nuova bestiolina

[carlottoIIx6]

Originariamente inviato da digieffe

so già che dovrebbe essere postato nel thread sulla disparita di trattamento del compilatore intel ma voglio informare anche voi!!!

Intel C / C++ 11.1 0.93 / 1,24 (SPECint_2006base / SPECfp_2006base)
Intel C / C++ 12.0 1,10 / 1,42 (SPECint_2006base / SPECfp_2006base)
other compilers 1,00 / 1,00 (SPECint_2006base / SPECfp_2006base) *

* Best of Visual Studio 2010 and PGI

1,10 / 0,93 = 1,18 (+18%)
1,42 / 1,24 = 1,14 (+14%)

complimenti a tutti i possessori di processori amd diventati più veloci del 18% sugli int e 14% sui fp


EDIT: con questi dati qual'è la reale differenza tra k10 e SB? e quale sarà tra Bd e SB???

eheh la verità viene sempre a galla!

[bjt2]

Originariamente inviato da bicchiere

Fonte?

Per quanto riguarda i giochi, quasi tutti ti installano il Visual C++ redistributable, quindi presumo che il compilatore Microsoft domini
con tutto ciò che abbia a che fare con DirectX.

Il compilatore Intel viene usato quando interessa la portabilita' del software (Mathematica etc...) in quanto è disponibile anche per il pinguino, ed è molto superiore al GCC. Ma assolutamente non credo sia il compilatore piu' usato (e nemmeno quello piu' performante)

Stranamente anche Matlab installa il visual c runtime... Eppure c'è anche per Linux... C'è da dire che molte parti grafiche sono in Java...

[Pihippo]

Originariamente inviato da digieffe

tenendo conto che ciò che hai scritto può essere "è inesatto e\o sbagliato" vorrei sincronizzare alcuni termini o concetti:
- switching dei ring (user\kernel mode) : normalmente 3\0.
- draw call = chiamata a direct x, al driver o coincidono?
- interruttori = software irq o qualcos'altro?
- stack del driver = intendi una struttura LIFO o una serie di call?


ps: in 220 cicli salva tutto lo stato della cpu???

grazie

Originariamente inviato da Pihippo

Ciao
Ripremetto quelle che tu giustamente hai quotato: Cio che scrivo potrebbe essere inesatto, vediamo se riesco ad indovinare qualcosa
1) Mi sa che ci siamo intesi
2) Draw Call = L'applicazione chiama l'api e quest'ultima il driver.
3) Intendo dal punto di vista della cpu istruzioni come INT e SYSCALL che sono molto più costose che chiamare una funzione con call+ret. Comunque intendo proprio il software interrupt generato da una combinazione di istruzioni eseguite dal processore stesso (INT e SYSCALL).
Per il ps secondo il manuale in 220 cicli circa si salva tutto e si cambia pure ring

Mi son dimenticato di precisare che con stack del driver = stack struttura di dati, ovvero un last in first out (LIFO) come da te ben detto.

[Mparlav]

Asrock annuncia "real Am3+" Mb, dove si evincono diversi particolari interessanti

http://www.asrock.com/news/events/2011am3%2B/

1. The new "black" AM3b CPU socket make you recognize the new AM3+ motherboard at the first sight! With the 11% bigger pin hole size, it can get rid of the possible mechanical mismatch when installing the CPU, and avoid the CPU pin-bent problem.

2. Thanks for the AM3+ MB 3.4 MHz Serial VID support, it provides faster link between CPU and power controller. Compare to the old AM3 MB 400 KHz link, the new AM3+ MB can support better power management & Power saving.

3. Not only meet AMD's requirements, the new AM3+ MB design provides efficient power supply up to 11.8% better CPU power saving. An added bonus will be its environment-friendly feature.

4. As we know, the lower CPU noise, the better system stability. When the system is at the same loading, the new AM3+ MB design improves the Vcore variation and reduces the CPU power noise up to 22%!

5. Compare to the old AM3 CPU only needs 110A current, the new AM3+ CPU needs higher 145A current! The New AM3+ MB can satisfy the demand of 32% higher current and get rid of any power shortage issue.

6. With the new C.C.R. (Combo Cooler Retention Module) design, the ASRock new AM3+ MB can get better cooling effect for CPU, memory and power components. According to our test result, it makes the CPU power choke 5.4 °C cooler! Besides, the C.C.R. is backward compatible with the old AM3 / AM2+ CPU cooler as well.

[Emopunk]

Originariamente inviato da Ishiki Takai

Quoto Tenebra dato che pure io stò progettando la mia nuova bestiolina

Non fate così sennò mi aggiungo anch'io

[capitan_crasy]

Originariamente inviato da Mparlav

Asrock annuncia "real Am3+" Mb, dove si evincono diversi particolari interessanti

http://www.asrock.com/news/events/2011am3%2B/

1. The new "black" AM3b CPU socket make you recognize the new AM3+ motherboard at the first sight! With the 11% bigger pin hole size, it can get rid of the possible mechanical mismatch when installing the CPU, and avoid the CPU pin-bent problem.

2. Thanks for the AM3+ MB 3.4 MHz Serial VID support, it provides faster link between CPU and power controller. Compare to the old AM3 MB 400 KHz link, the new AM3+ MB can support better power management & Power saving.

3. Not only meet AMD's requirements, the new AM3+ MB design provides efficient power supply up to 11.8% better CPU power saving. An added bonus will be its environment-friendly feature.

4. As we know, the lower CPU noise, the better system stability. When the system is at the same loading, the new AM3+ MB design improves the Vcore variation and reduces the CPU power noise up to 22%!

5. Compare to the old AM3 CPU only needs 110A current, the new AM3+ CPU needs higher 145A current! The New AM3+ MB can satisfy the demand of 32% higher current and get rid of any power shortage issue.

6. With the new C.C.R. (Combo Cooler Retention Module) design, the ASRock new AM3+ MB can get better cooling effect for CPU, memory and power components. According to our test result, it makes the CPU power choke 5.4 °C cooler! Besides, the C.C.R. is backward compatible with the old AM3 / AM2+ CPU cooler as well.

Clicca qui...

[Ishiki Takai]

bene bene, dai voglio al più presto informazioni sulle nuove motherboard da parte anche di MSI e gigabyte!

di asus e asrock dopo diverse rotture non mi fido più.

[digieffe]

Originariamente inviato da bjt2

Stranamente anche Matlab installa il visual c runtime... Eppure c'è anche per Linux... C'è da dire che molte parti grafiche sono in Java...

è possibile che sia compilato "a più mani" e poi linkato insieme?

ps: gcc lasciava (non so ora) uno "timbro (es gcc 2.93)" nel proprio codice, che voi sappiate gli altri fanno altrettanto?

[Athlon 64 3000+]

http://translate.googleusercontent.c...oRTKwQ#p203883

[paolo.oliva2]

Originariamente inviato da Athlon 64 3000+

http://translate.googleusercontent.c...oRTKwQ#p203883

Veramente, io con il Thuban occato ottengo 7,6 per quello che riguarda la CPU, ma poi Windows mi figura 5,9 perché come risultato "lui" prende il valore più basso, che può essere dato dalla VGA, dall'HD, dalla RAM.



Edit:

Ma te postavi per questo o per i 22,95 con Cinebench? . Lì fanno un gran parlare, c'è chi dice che è un fake e chi riporta che sarebbe lo stesso risultato di un BD X16 ES a 1,8GHz. Comunque lì riporta 3,5GHz no turbo.