[Thread Ufficiale] CPU serie FX: AMD Bulldozer/Piledriver - Aspettando Steamroller

[Randa71]

Originariamente inviato da aldooo

Neanche io sono stupito,
i bench dove i bulldozer mostra la sua vera potenza sono "scatticchiamenti" "il mio programma"...
a quando un bench "sul carico" che fornisca un numero riproducibile?

ma io non mi stavo riferendo a te...
poi come sempre sei liberissimo di non crederci...

aggiungo: come realizzeresti un test per capire come valutare numericamente/oggettivamente il carico su un sistema?
nr di frames di un videogioco a parte?
qual'è il valore oggettivo che ti interesserebbe sapere? perchè a differenza mia, Shellx dei numeri li ha dati...forse te li sei persi

[aldooo]

Originariamente inviato da Randa71

ma io non mi stavo riferendo a te...
poi come sempre sei liberissimo di non crederci...

Hai scelto proprio la parola giusta, "crederci".
Finchè non vedo qualcosa di riproducibile, stiamo facendo religione.

[Randa71]

Originariamente inviato da aldooo

Hai scelto proprio la parola giusta, "crederci".

credimi che qui la fede non c'entra proprio nulla...

[shellx]

Originariamente inviato da OPP

perdonami, dimenticavo che non vedi di buon occhio windows

No non è questo non lo odio, figurati ...ma purtroppo sono forze maggiori.
Quelle poche volte che lo usato mi ha causato una forma di sfogo acuto nel palmo della mano con la quale tengo il mouse, e un prurito che non mi faceva chiudere occhio. Ho fatto le prove allergiche e sono risultato gravemente positivo allo StreptoM$coccus.
E per evitare shock anafilattici devo purtroppo trovare alternative.
Lo so è spiacevole avere certi limiti, ma che ci posso fare, davanti alla salute non si guarda nient'altro.

[aldooo]

Originariamente inviato da Randa71

credimi che qui la fede non c'entra proprio nulla...

Ancora credere? Ma ti rendi conto di quanto spesso usi questa parola?
Io non voglio credere, voglio vedere!

Se shellx ha sviluppato l'applicazione che sta testando,
probabilmente sarà capace di creare un benchmark che dimostri le potenzialità di BD.

[shellx]

Originariamente inviato da aldooo

Hai scelto proprio la parola giusta, "crederci".
Finchè non vedo qualcosa di riproducibile, stiamo facendo religione.

Hai ragione: pero se vuoi levarti il dubbio ti vendo GoCall 2.6 alla modica cifra di € 2200 e te lo provi con il tuo sistema (magari avrai il 2600k).

Se shellx ha sviluppato l'applicazione che sta testando,
probabilmente sarà capace di creare un benchmark che dimostri le potenzialità di BD.

non è una questione di volere, tu credi che io abbia tempo di creare bench per soddisfare la tua diffidenza ?
Soprattutto bench no di videogames (quelli che usi tu) ma di questa tipologia applicativa ?
Mi sono pentito di non aver catturato uno screen deigli 8 core's a 85% ieri mentre smanettavano 80 accessi, ma ero concentrato piu che altro a vedere le potenzialita della mia applicazione e del giudizio dell'azienda acquirente. Il resto per me è fuffa.
Io il test lo fatto piu per testare la mia applicazione che BD (quanto meno il conftonto contro il 2600k, visto che ho gia detto di non averlo per cui non mi esprimo in merito, ma mi esprimo dicendo che è un altro pianeta rispetto thuban in questa tipologia applicativa, che sicuramente per te è arabo ed oscura), poi avuti certi risultati mi sono sentito di volerli condividere dentro il thread. Mica sei obbligato a crederci. Figurati quanto mi frega e che valore ha per me il tuo giudizio.

[Randa71]

Originariamente inviato da shellx

Hai ragione: pero se vuoi levarti il dubbio ti vendo GoCall 2.6 alla modica cifra di € 2200 e te lo provi con il tuo sistema (magari avrai il 2600k).

tutto ha un prezzo giustamente...ed evito di iniziare discorsi (non con te) sulla differenza tra benchmark e carico....
sia per non inquinare il thread;
sia perchè sarebbe fiato sprecato.
CREDIMI

[ra-mta]

aldo, shellx aveva già notato che con carichi "stile server" bd rendere molto bene, nulla di nuovo
Non sarebbe credibile se dicesse che in altri ambiti rende meglio della concorrenza smentendo la miriade di test che sono in giro, ma nel suo caso specifico io non faccio nessuna fatica a credergli ed è un campo "di nicchia" quindi poco testato..anche perchè è raro che spende parole buone verso la prima incarnazione di bd

[Randa71]

Originariamente inviato da shellx

Hai ragione: pero se vuoi levarti il dubbio ti vendo GoCall 2.6 alla modica cifra di € 2200 e te lo provi con il tuo sistema (magari avrai il 2600k).



non è una questione di volere, tu credi che io abbia tempo di creare bench per soddisfare la tua diffidenza ?
Io il testlo fatto piu per testare la mia applicazione che BD, poi avuti certi risultati mi sono sentito di volerli condividere dentro il thread. Mica se obbligato a crederci. Figurati quanto mi frega e che valore ha per me il tuo giudizio.

e aggiungo che ancora una volta diciamo che dimostra la sua ingenuità: perchè caro Shellx, tu mi insegni che se vuoi fare un test sul carico che dimostri ciò che stai affermando lo puoi taroccare come e quando vuoi...e per taroccare non sto parlando di alterare gli eventuali print screen con photoshop...quindi il vedere lascia poi il tempo che trova. anche perchè immagino che la tua applicazione, per tua sfortuna, non sia poi così diffusa da poterla riprovare come invece fanno tutti i siti in cui recensiscono software che sono diffusissimi e che quindi i risultati, visto che sono riproducibili da chiunque, non si azzardano, pena credibilità, ad alterarli

[shellx]

Originariamente inviato da Randa71

e aggiungo che ancora una volta diciamo che dimostra la sua ingenuità: perchè caro Shellx, tu mi insegni che se vuoi fare un test sul carico che dimostri ciò che stai affermando lo puoi taroccare come e quando vuoi...e per taroccare non sto parlando di alterare gli eventuali print screen con photoshop...quindi il vedere lascia poi il tempo che trova. anche perchè immagino che la tua applicazione, per tua sfortuna, non sia poi così diffusa da poterla riprovare come invece fanno tutti i siti in cui recensiscono software che sono diffusissimi e che quindi i risultati, visto che sono riproducibili da chiunque, non si azzardano, pena credibilità, ad alterarli

Appunto, sono sicuro che se mi fossi ricordato di catturare unmisero screen qualcuno a caso avrebbe detto che lo taroccato.
Siccome non ho tempo da perdere in queste minc..iate.
E poi proprio io che disprezzo zambesi. Per me il 2600k rimane comunque superiore come processore desktop nell'utilizzo di oltre il 70% di applicazioni e non avendolo non posso giudicarlo sul tipo di carico MT effetuato da me ieri con la mia applicazione. Ma non posso non ammettere che in questa tipologia di carico sto caxxo di 8120 non ha niente a che vedere con il 1055T nonostante quest'ultimo si comporta molte volte meglio nella applicazioni con meno di 4 core.
Quindi ha ragione Paolo quando dice che in MT il suo 8150 lo vede andare meglio rispetto il suo 1100T.
Ora quasi quasi per qualcuno passo pure per fanboy amd.....proprio IOOO? ahahahaha

[ra-mta]

shellx mi spieghi na cosa, o chiunque riesca, una curioistà diciamo

Nel tuo "gocall" ha un carico di 8 thread sul procio, immagino però non troppo pesanti dato che i "core" non sono al 100%..ora mi chiedo, rispetto ad un programma che sfrutta tutti i core al 100% tipo vray, come mai risulta così lento bd? vorrei capire la differenza in prestazioni da un uso "server" a "workstation" a cosa sia imputabile

[shellx]

Originariamente inviato da Randa71

edit:
'Potevo assemblargli io un server identico, avrebbero risparmiato, ma ho preferito affidarmi ad HP, per le aziende è sempre meglio cosi, almeno se hanno problemi se la prendono con HP e no con me.'
ottima cosa..solitamente in questi casi, siccome immagino tu sia un consulente o quasi, il gioco non vale la candela....
per il test hai ritoccato qualche parametro del kernel o tutti standard? immagino che fosse su linux/unix

kernel standard 3.2, os linux sia su server che sui 180 client
ovvio perforza ho dovuto usare linux, per questo motivo: (mi vuoi morto) ?

No non è questo non lo odio, figurati ...ma purtroppo sono forze maggiori.
Quelle poche volte che lo usato mi ha causato una forma di sfogo acuto nel palmo della mano con la quale tengo il mouse, e un prurito che non mi faceva chiudere occhio. Ho fatto le prove allergiche e sono risultato gravemente positivo allo StreptoM$coccus.
E per evitare shock anafilattici devo purtroppo trovare alternative.
Lo so è spiacevole avere certi limiti, ma che ci posso fare, davanti alla salute non si guarda nient'altro.

[shellx]

Originariamente inviato da ra-mta

shellx mi spieghi na cosa, o chiunque riesca, una curioistà diciamo

Nel tuo "gocall" ha un carico di 8 thread sul procio, immagino però non troppo pesanti dato che i "core" non sono al 100%..ora mi chiedo, rispetto ad un programma che sfrutta tutti i core al 100% tipo vray, come mai risulta così lento bd? vorrei capire la differenza in prestazioni da un uso "server" a "workstation" a cosa sia imputabile

Perchè la quantità di carico sui core's non è uguale per tutte le applicazioni. Esistono diversi carichi MT influenzati da diverse tipologie applicative, dipende anche dal tipo di istruzioni che sfruttano queste. Molto probabilemente vray anche se sfrutta tutti i core, utilizza pero delle istruzioni dove intel se la cava meglio. La mia applicazione sfrutta carichi ti tipo LOAD, destinati a tipologie di utilizzi di carattere database (classici utilizzi che avvengono in macchine server, datacenter, e webserver).
Vray se non erro è una applicazione di grafica 3D. Non ha niente a che vedere con il tipo di elaborazione usato sulla mia applicazione.
Server e Workstation non sono la stessa piattaforma.

[Randa71]

Originariamente inviato da shellx

Perchè la quantità di carico sui core's non è uguale per tutte le applicazioni. Esistono diversi carichi MT influenzati da diverse tipologie applicative, dipende anche dal tipo di istruzioni che sfruttano queste. Molto probabilemente vray anche se sfrutta tutti i core, utilizza pero delle istruzioni dove intel se la cava meglio. La mia applicazione sfrutta carichi ti tipo LOAD, destinati a tipologie di utilizzi di carattere database (classici utilizzi che avvengono in macchine server, datacenter, e webserver).
Vray se non erro è una applicazione di grafica 3D. Non ha niente a che vedere con il tipo di elaborazione usato sulla mia applicazione.
Server e Workstation non sono la stessa piattaforma.

aggiungo che quanto detto da Shellx non è che la macchina è + veloce di X ma che è + reattiva al presentarsi di 80 connessioni contemporanee rispetto alle altre da lui provate.....mentre invece sia phenom che 920 cedono il passo...cioè macchina non reattiva....o lenta..
che è diverso dal discorso prestazioni....faccio un esempio: magari il 920 con 40 connessioni impiega 2 minuti a gestirle...8120 magari ce ne impiega di + es 3 minuti...ma nel momento in cui le connessioni diventano 80 cmq 8120 è sempre reattiva...cioè navighi nella sua applicazione fluidamente mentre con le altre CPU da lui provate, quando schiaccia un pulsante della sua app, utente aspetta aspetta e aspetta... (penso che sia così...Shellx ovviamente mi deve correggere se non è cosi)
questo diverso comporamento di BD per me è in gran parte dovuto sia ai 16mb di cache (se ci fate caso tutte le cpu server hanno quintalate di cache)....sia al fatto che cmq le risorse per gli interi sono duplicate..quindi cmq riesce lo stesso a star dietro alle richieste che gli provengono dall'applicazione....perchè cmq le potenza di calcoli dei singoli CMT è sufficiente per gestire al meglio la sua app.....pur essendo inferiore nel confronto diretto con nehalem/phenom in termini di perf pure.
per rispondere alla tua domanda: vray penso che usi molto le FPU (e li sono 4 non 8..quindi diciamo che in virgola mobile il CMT perde il suo vantaggio)ma questo non toglie che cmq anche se il risultato è inferiore rispetto alle altre cpu, non è detto che in termini di reattività della macchina non si verifichi la stessa cosa...perchè? perchè ha molta cache, perchè ha 8 unità sugli interi anche se molto + lente rispetto alla concorrenza, ma + che sufficienti a gestire la maggior parte dei carichi..quindi smaltiscono velocemente i thread, e sotto con il prossimo thread....
cosa vuol dire: che se dopo aver lanciato vray, su unix lancio un awk o un confronto tra stringhe o una grep, cmq la CPU ha risorse libere da dedicare... (questo giustifica 85% di utilizzo della CPU nell'esempio di Shellx nonostante il nr elevato di connessioni....mi aspetto che con le altre macchine fosse al 99% o quasi)
è come se in un pc hai 4 dischi veloci
o 8 dischi più lenti.....
quando mandi 8 richieste di lettura o i 4 dischi + veloci sono talmente veloci da gestirle tutte, altrimenti aspetti....
mentre negli 8 dischi possono cmq essere spalmate..magari il dato richiesto arriverà qualche millisecondo dopo, ma cmq avrai risorse a cui mandare ulteriori richieste...
bisognerebbe caricare la cpu al 100% e poi lanciare in unix/linux un qualunque comando preceduto dal comando 'time' così li si vede la durata del processo e si possono vedere le differenze
questa è la mia idea
magari sono tutte sciocchezze...
dispostissimo a capire se sbaglio dove sbaglio

[ra-mta]

uhm quindi cambia il tipo di carico e di istruzioni..grazie, pensavo potesse dipendere da questo ma il dubbio c'era comunque
Che un server non sia una workstation lo sapevo

grazie anche a te randa, sul rapporto tempo-carico mi ero fatto qualche idea sulle esperienze lette (sia tue che di paolo)

[shellx]

Esatto.
Per fare un paragone alla portata di tutti:
immaginate di avere su un percorso 8 levrieri da una parte e 8 asky siberiani da slitta dall'altra. Devono entrambi percorrere un percorso sia in velocità che in resistenza.
Gli 8 levrieri sono sicuramente piu veloci degli 8 asky, ma gli asky tirano con se una slitta e persone a bordo a questa.
I levrieri arriveranno al traguardo molto prima degli asky, ma gli asky anche se piu lenti puoi caricargli quanta roba e pesi vuoi da tirare, loro cederanno molto dopo dei levrieri.
Prova a far tirare una slitta con una persona a bordo dietro ad un levriero, dopo 100 metri non ce la fa piu, perchè ha la forma fisica ed è addestrato nella velocità nel gareggiare da solo senza pesi, l'asky invece come gli asini è da tiro e da resistenza.
Ecco, adesso la slitta è il mio GoCall 2.6, le persone a bordo ad essa sono gli 80 accessi, e gli 8 asky siberiani sono gli 8 cluster (core) dentro il mio 8120.
I 6 core di thuban sono come levrieri corrono piu veloci, ma se li carichi di pesi si arrendono prima di zambesi.
Mi resta da capire invece i core sandy bridge che comportamento hanno. E avro modo di capirlo molto presto.

Originariamente inviato da Randa71

cosa vuol dire: che se dopo aver lanciato vray, su unix lancio un awk o un confronto tra stringhe o una grep, cmq la CPU ha risorse libere da dedicare... (questo giustifica 85% di utilizzo della CPU nell'esempio di Shellx nonostante il nr elevato di connessioni....mi aspetto che con le altre macchine fosse al 99% o quasi)

Con il 1055T al trentaciquesimo accesso i 6 core erano stallati al 100%, e il trentaseiesimo user non riusciva nemmeno ad effettuare il login.

è come se in un pc hai 4 dischi veloci
o 8 dischi più lenti.....
quando mandi 8 richieste di lettura o i 4 dischi + veloci sono talmente veloci da gestirle tutte, altrimenti aspetti....
mentre negli 8 dischi possono cmq essere spalmate..magari il dato richiesto arriverà qualche millisecondo dopo, ma cmq avrai risorse a cui mandare ulteriori richieste...

esatto, uguale al mio paragone dei levrieri ed asky...è quello il concetto che ho avuto modo di constatare ieri.

bisognerebbe caricare la cpu al 100% e poi lanciare in unix/linux un qualunque comando preceduto dal comando 'time' così li si vede la durata del processo e si possono vedere le differenze
questa è la mia idea
magari sono tutte sciocchezze...
dispostissimo a capire se sbaglio dove sbaglio

Le tempistiche dei processi vengono smaltite da Zambesi in maniera costante e reattiva con 80 interrogazioni sull'applicazione.
35 accessi su thuban venivano smaltite piu rapidamente di zambesi fino al quindicesimo, la costanza ha perso effetti dal 26esimo accesso,avendo reattivita sempre piu inferiori fino al 35esimo accesso, per poi rimanere in stallo come freezato al 36esimo. Tanto che il 36esimo user non riusciva nemmeno ad effettuare il login, il formato login di GoCall dopo l'inserimento dati e l'avvio all'accesso, gli restava in precaricamento per minuti e minuti.

[bjt2]

Originariamente inviato da aldooo

Quali sono i vantaggi e gli svantaggi? (ogni scelta ha pro e contro)

Originariamente inviato da capitan_crasy

Ma direi che modificare uno scheduler con una semplice patch non è la stessa cosa di avere a disposizione una versione più aggiornata e ottimizzata...



Una spiegazione per noi comuni mortali?



Credo che sia naturale che lo scheduler di Win8 sia "migliore" di qualche punto percentuale se paragonato al Win7; con ogni probabilità gli stessi benefici dovrebbe averne anche le CPU Intel...

Scusate il ritardo...
Allora. Normalmente gli algoritmi di divisione e radice quadrata sono iterativi, calcolando un tot di bit a iterazione. I primi divisori calcolavano un bit alla volta. Attualmente nei processori AMD e INTEL se ne calcolano 2 (raddoppiando quindi la velocità rispetto alle soluzioni a 1 bit). Questo ne calcola 3 bit per ciclo. Ovviamente lo svantaggio è una maggiore complessità e occupazione di area. Ma il vantaggio è la maggiore velocità.

[Randa71]

@Shellx: ti scasso con alcune domande:
1) non con il cliente ma nelle tue prove tutte le CPU erano a def o no?;
2) mi interessa molto il 920...lui dove si fermava rispetto al phenom??
3) con 80 connessioni la tua sensazione era che la cpu era al limite o potevi arrivare anche a 100 ad esempio e avrebbe resistito?
4) te lo chiedo perchè è interessante capire il limite di zambesi e quando avrai 2600k buttargli su lo stesso nr di connessioni e vedere come si comporta SB....considerato che 2600k costa circa 120€ in più rispetto al 8120..e che 8120 non è cmq il top di zambesi perchè il livello di clock tra 2600 e il 2700 100mhz è molto minore tra 8120 e 8150

edit: cmq vedete che il discorso carico non sono balle...se il 36° non riesce a fare la login mentre con 80 quelli giravano tranquillamente...la differenza è abissale...pensate e mettetevi nei panni di uno sviluppatore: se l'app di Shellx doveva girare per forza sul phenom, avrebbe dovuto modificarla..oltre a dover capire quale parte del codice diventava collo di bottiglia per la CPU...insomma ci avrebbe perso un bel po' di tempo/soldi....mi ricordo di un'app che io e altri ci abbiamo perso 3 gg per capire come mai un server Itanium2 si piantava.....capire sei il collo di bottiglia erano i dischi o la cpu...e poi era una cacchio/malefica query, annegata in un mare di codice, fatta apposta male da uno che era stato cacciato...chissà come gli sono fischiate le orecchie quel giorno
quando ero all'IT della banca in cui ho lavorato e il server di turno non rispondeva neanche alle login degli applicativi all'improvviso la banca diventava una caserma

[paolo.oliva2]

Vorrei aggiungere questo:

il VERO punto debole di BD è la potenza ST al momento, e di conseguenza la potenza bruta.

In questo contesto, BD non puo' soddisfare un'aspettativa di potenze brute al vertice, sia in ST che MT, sia nei confronti del Thuban che della concorrenza.

Non metto in dubbio che c'è chi puo' essere deluso di aver speso X soldi per aver upgradato dal Thuban all'8150 (io no... perchè la scimmia per testare il nuovo è forte... ed anche perchè, ad esempio, un 1100T mi ha dato di meno di un 1090T, quindi rischio e scimmia vanno a braccetto e si accettano i rischi"), ma questo non equivale a dire che chi ha un 8150 tornerebbe indietro al Thuban...

Cosa ho sempre detto? Che la differenza di prestazioni tra un 8150 ed un Thuban non puo' essere interpretata attraverso i risultati dei bench di cui siamo sommersi.

Vi faccio un esempio... quando passiamo da un portatile al computer fisso di casa, cosa notiamo IMMEDIATAMENTE? La potenza del sistema sull'uso normale? Certamente no, la potenza sulla singola applicazione? In parte o comunque se fortemente MT... Quello che notiamo immediatamente è che un portatile non puo' essere fluido come il PC di casa e caricando più applicazioni il portatile si siede immediatamente.

L'8150 è superiore in MT ed inferiore in ST rispetto al Thuban e diciamo che sul singolo programma sarebbe difficile per chi ci sta sopra capire se dentro al PC ci sia un 8150 o un Thuban. Ma se cominci a caricarlo, allora si che lo capisci immediatamente e fra un 8150 ed un Thuban c'è una galassia di differenza.

Forse è per questo che ci sono tutte ste incomprensioni tra chi ha un 8150 e chi lo giudica senza averlo... perchè chi lo difende non lo fa per bandiera o per l'acquisto fatto e chi lo denigra lo fa sulla base dei bench che non riflettono appieno il comportamento di BD. Se dovessi scegliere tra un 8150 più potente del +5% ma un comportamento in carico come il Thuban, sinceramente lo preferirei come è adesso. Naturalmente la speranza è che un Vishera aumenti la potenza in modo marcato sull'8150, perchè il resto va bene cosi' com'è.

[Randa71]

Originariamente inviato da shellx

Esatto.
................


Le tempistiche dei processi vengono smaltite da Zambesi in maniera costante e reattiva con 80 interrogazioni sull'applicazione.
35 accessi su thuban venivano smaltite piu rapidamente di zambesi fino al quindicesimo, la costanza ha perso effetti dal 26esimo accesso,avendo reattivita sempre piu inferiori fino al 35esimo accesso, per poi rimanere in stallo come freezato al 36esimo. Tanto che il 36esimo user non riusciva nemmeno ad effettuare il login, il formato login di GoCall dopo l'inserimento dati e l'avvio all'accesso, gli restava in precaricamento per minuti e minuti.

e questo per me accade perchè in zambesi ci sono molte + risorse duplicate e grosse rispetto a thuban.......
una cpu si pianta quando tutte le risorse al suo interno sono full (thuban)...ma se le duplichi o sono + grosse (la cache o il CMT - zambesi) hai risorse libere e quindi non il blocco dell'applicativo..ad esempio: con thuban se non ricordo male la cache di 2° livello è di 512kb...con BD sono 2 MB...e per quanto lenta, sarà sempre + veloce che andare a cercarsi i dati in ram coinvolgendo IMC e il canale RAM..anche perchè poi il canale ram non è che lo usa solo un core ma è condiviso tra tutti e 6 thread (8 nel caso di zambesi) e avere già il dato in cache penso che sia un bel vantaggio..
certo se poi lo usi solo con un app single thread o quasi, cioè non lo carichi come si deve, questo vantaggio sparisce, anzi diventa all'opposto quasi un problema (dimensioni del die, consumi e calore)....