Xeon 3,6 Ghz vs Opteron 250

[Hyperion]

Dall'articolo:

il tempo di elaborazione della scena benchmark è passato da 1636 secondi a 1302 secondi, un miglioramento di poco superiore al 20% dei tempi di elaborazione,

Il miglioramento è del 25% non del 20.

il 20 % viene come risultato di:
(1636-1302)/1636
che è sbagliato.
Se infatti il numero fosse 1 invece che 1302, il miglioramento così calcolato sarebbe il 100%, ovvero andrebbe il doppio, quando invece la logica dice che andrebbe 1636 volte.

La relazione giusta è:
(1636-1302)/1302.

Credo che l'errore non sia soltanto in quel passaggio, molto probabilmente è stato ripetuto altre volte.

Per il resto ottima recensione.



Ciao!!

[MaxArt]

Bisogna giusto intendersi sui termini. Potremmo parlare allora di "un decremento dei tempi di esecuzione del 20%"
Però, sono d'accordo a parlare di "incremento delle prestazioni del 25%", e tra l'altro è un valore estremamente vicino a quello rilevato da X-bit Labs

[^TiGeRShArK^]

Originariamente inviato da MiKeLezZ
Carini i test G5 vs. PC...

Dall'articolo di Corsini sono uscite due cose interessanti:
- Lo Xeon è mediamente più prestante (il fatto l'Opteron vada peggio perchè si è testato non la versione con 200MHz in più mi sa tanto di scusa..), però immagino costi anche molto di più (purtroppo non è stata fatta menzione del prezzo)
- L'Hyperthreading è più utile di quanto si pensi (sono stufo di sentire gli AMDisti che dicono che non serve ad una seppia, in ambito desktop io la differenza la sento, eccome).
Una cosa che invece manca è quanto dissipano i due sistemi (quindi il loro consumo) che può tornare utile se si vogliono fare investimenti in grossi cluster, ecc.

l'incremento sarebbe di 200 mhz X PROCESSORE e in un'arkitettura efficiente come l'opteron credo sappiamo tutti ke il guadagno prestazionale ottenibile sia tutt'altro ke trascurabile....
inoltre, nonostante i test scelti siano praticamente solo quelli favorevoli all'arkitettura netburst(rendering e multimedia), vediamo ke a volte il 250 riesce pure a sopravanzare lo xeon top di gamma....
x quanto riguarda l'ht imho il suo effetto si sente molto di più su una makkina single processor ke su una dual x via dell'overhead.... cmq a questo proposito sarebbero interessanti dei test ke confrontano i guadagni ottenuti con ht abilitato su un single processor e su un dual.....

La cosa che mi ha lasciato un po' l'amaro in bocca sono alcuni commenti fuorvianti, come ad esempio quando si parla di Seti: "il divario tra i due sistemi è di poco superiore al 35%", quel "di poco" è proprio a sproposito, non dà la giusta enfasi al risultato, poichè 35% è un risultato davvero abnorme che andrebbe un attimino più sottolineato (cavolo se mi compro un server solo per quello, pago più o meno la stessa cifra e mi ritrovo prestazioni minori del 35% mi incazzo un attimino.. visto che comunque i server sono spesso dedicato solo per uno o due pacchetti software quindi la scelta deve esser sempre mirata).
Stesso dicasi con i test su Lightwave, anche lì siamo mediamente sul 30% a favore dello Xeon su parecchi test e tutto questo viene semplicemente bollato con un "chiari margini di vantaggio con tempi variabilmente inferiori" (e viene poi oltretutto ripetuto il concetto nella frase seguente "con margini variabili a seconda del tipo di scena" errore linguistisco quindi oltre che concettuale), invece nell'unico test a favore dell'Opteron si tirano fuori paroloni come "il sistema Opteron 250 si avantaggia nettamente su quello Xeon 3,6 GHz di poco meno del 30%" e qua salta fuori pure la % ...

p.s. siete riusciti a legger fra le righe.. ?

Un attimino più di imparzialità secondo me non avrebbe guastato.. come invece è immancabilmente presente nelle conclusioni (della serie non mi sbilancio né di qua né di là). Per il resto buon articolo, anche se qualche test in più con i 64bit non penso avrebbe guastato.

e su queste frasi lasciamo perdere....
come ho già detto sono stati fatti solo test ke avvantaggiano lo xeon (x mancanza d tempo come ha già spiegato il buon corsini) e tu tacci di parzialità il suo lavoro????

E' evidente che la causa di questo risultato sia legata al software utilizzato, e non all'architettura hardware: per quanto possa essere poco efficace un'implementazione a 64bit all'interno di un processore, non ha infatti senso che una cpu operi più lentamente con codice a 64bit che con quello a 32bit.

se fosse stato un articolo fatto apposta x sminuire lo xeon come mi spieghi questa frase ke giustifica i pessimi risultati ottenuti dalla cpu intel???? io partendo da questo quote e dal ragionamento fatto prima sui test potrei dire benissimo ke hwu ha fatto l'articolo di proposito x far apparire lo xeon migliore di quello ke è...... ma IO invece non penso affatto ke il lavoro di hwu non sia imparziale...... cosa ke invece tu ti 6 messo ad insinuare.....

Alla fine secondo me sono i risultati ke contano ed è inutile mettersi a criticare i commenti dei redattori, ke immagino non abbiano poi avuto moltissimo tempo a disposizione x completare il loro lavoro.....

[MiKeLezZ]

Io commento sulla base delle informazioni che ho.
Se hanno fatto i test che avvantaggiano l'architettura Intel non è colpa mia... Decidetevi.. O sono i test che fan schifo oppure è lo Xeon più prestante

[MaxArt]

Originariamente inviato da MiKeLezZ
O sono i test che fan schifo oppure è lo Xeon più prestante

Non sono i test a far schifo, è la scelta che è magra. Tra un paio di settimane, magari uscirà qualcosa di più approfondito.

[^TiGeRShArK^]

appunto...

[xeal]

Originariamente inviato da MiKeLezZ
"il divario tra i due sistemi è di poco superiore al 35%"

Non vedo cosa ci sia di scandaloso in questa affermazione: la cifra parla da sola e quel "di poco superiore" ne aumenta il peso nell'ottica comunque di un giudizio obiettivo, enfatizzato ma non troppo.

"il sistema Opteron 250 si avantaggia nettamente su quello Xeon 3,6 GHz di poco meno del 30%" e qua salta fuori pure la % ...

Lo Xeon guadagna circa il 30% nel primo test (radiosity), circa il 10,4% nel secondo (raytrace), circa il 22% in nebulae e circa il 4,5% nell'ultimo (stime arrotondate, di poco, per eccesso). La media è del 16.7% (considerando i soli risultati positivi, comunque quasi la metà rispetto al 30% direi). La conclusione al riguardo è:

Il rendering con Lightwave mostra chiari margini di vantaggio per la piattaforma Xeon 3,6 GHz, nuovamente grazie alla tecnologia HyperThreading che in questo genere di applicazioni può essere sfruttata al massimo delle sue potenzialità. I tempi di rendering sono sempre inferiori a quelli dei processori AMD Opteron 250, con margini variabili a seconda del tipo di scena.

Onestamente mi sembra una conclusione obiettiva; è vero che si da una certa enfasi alla percentuale "strappata" dall'Opteron 250, però a mio avviso tale enfasi è del tutto giustificabile per due semplicissimi motivi:
a) Hw Upgrade è pur sempre una rivista online, quindi è giusto che ci sia un po' di enfasi a sottolineare risultati in un certo qual modo "clamorosi" (e non è vero che non si da enfasi ai risultati dello Xeon, semplicemente non vi è nessuno sbilanciamento "eccessivo" né da una parte, né dall'altra);
b) il risultato ottenuto dal 250 in quel test non può non attirare l'attenzione e stupire, poichè si tratta di un'applicazione (Lightwave) nettamente sfavorevole alle cpu opteron (lo dicono i risultati), il cui bench presenta ben quattro risultati nettamente sfavorevoli (in misura variabile, e in media ben al di sotto del 30% - il 7,4% considerando anche il test a favore dell'Opteron, per quanto possa valere una media non pesata sulla "frequenza reale" degli scenari d'uso proposti nei test) su cinque test: è quanto meno curioso che il 250 riesca a strappare un 30% in uno dei test, l'enfasi ci sta tutta. Riportare in percentuale il divario per tutti i test appesantirebbe solo la lettura, l'articolo ha carattere tecnico-divulgativo, in fondo.

Quanto alla "teoria" poco convincente dei 200 MHz in meno rispetto al 252, come già evidenziato da altri, vanno riferiti a entrambe le cpu, quindi non possono non incidere; ma aggiungerei anche che vi è (per ciascuna cpu) anche una differenza di 200 Mhz sul bus hyper transport, che sicuramente incide nelle comunicazioni tra le due cpu e nell'accesso di ciascuna a dati eventualmente presenti nella memoria dedicata all'altra (naturalmente non mi aspetto dei miglioramenti generali, in tutti i test, solo per la maggiore frequenza dell'ht).




x Corsini

Una curiosità sulle anomalie nei test a 64 bit: non potrebbe esserci un qualche problema nella beta relativamente alla gestione di più core logici in un sistema con più di una cpu fisica (è un'idea magari "strampalata" che mi è venuta in mente, probabilmente sono fuori strada...)? Capisco che un nuovo test a 32 e 64 bit con HT disabilitato sarebbe chiedere troppo...

Ciao a tutti

[criminal187]

Scusate ma nn mi sembra un test equo, è stata confontata una cpu con supporto sse3 contro una ke nn supporta le sse3... forse dovevate confrontare lo xeon 3,6 con l'operton 252 non con il 250...

[Paolo Corsini]

Originariamente inviato da criminal187
Scusate ma nn mi sembra un test equo, è stata confontata una cpu con supporto sse3 contro una ke nn supporta le sse3... forse dovevate confrontare lo xeon 3,6 con l'operton 252 non con il 250...

Ciao,
premesso che l'incidenza delle SSE3 è molto ridotto, o per meglio dire limitato solo ad alcune particolari applicazioni, è stato spiegato più volte perché è stata adottata una cpu Opteron 250 e non il modello 252.

[Paolo Corsini]

Originariamente inviato da Hyperion
Dall'articolo:

il tempo di elaborazione della scena benchmark è passato da 1636 secondi a 1302 secondi, un miglioramento di poco superiore al 20% dei tempi di elaborazione,

Il miglioramento è del 25% non del 20.

il 20 % viene come risultato di:
(1636-1302)/1636
che è sbagliato.
Se infatti il numero fosse 1 invece che 1302, il miglioramento così calcolato sarebbe il 100%, ovvero andrebbe il doppio, quando invece la logica dice che andrebbe 1636 volte.

La relazione giusta è:
(1636-1302)/1302.

Credo che l'errore non sia soltanto in quel passaggio, molto probabilmente è stato ripetuto altre volte.

Per il resto ottima recensione.



Ciao!!

Ciao,
considera che in questo caso il risultato migliore è quello più basso, non quello più alto.
Se per fare un calcolo tu impieghi 1636 secondi, e io 1302, si può dire che io ci metto circa il 20% in meno. Infatti, 1636 - 20% di 1636 (327,2)= 1308.

Sarebbe stato del 25%, come tu hai indicato, se fossi partito da 1302 e terminato a 1636, ipotizzando che questi valori non siano tempi (dove il risultato superiore è peggiore) ma ad esempio punti di un test, dove al risultato superiore corrisponde una migliore prestazione.

Probabilmente sarebbe stato meglio scrivere quella frase come

il tempo di elaborazione della scena benchmark è passato da 1636 secondi a 1302 secondi,: si tratta di un risultato inferiore del 20% rispetto a quanto registrato con codice a 32bit.

Probabilmente messa in questo modo avrebbe evitato malintesi. Ho verificato le altre percentuali, comunque, a me risultano tutte corrette.

[DioBrando]

un articolo molto curato anche se mi sarebbe piaciuto vedere qlc test sia utilizzando dei DBMS ( 32 e 64 bit), sia con linux ( e mi associo a joeth), anche perchè IMHO questi sn utilizzi molto + papabili per simili piattaforme rispetto per esempio all'encoding ( cioè uno n si compra un Dual Opteron per rippare un DVD, si compra al max un P4 se vuole rimanere sull'Intel ).
Alla fine cmq servono a valutare un certo tipo di prestazioni e capisco anche la tirannia del tempo.

Spero però ci sia maggior posto in futuro perchè IMHO questi test sn come "il cacio sui maccheroni" per confronti tra Win e linux e sw ad hoc per gestire database...e potrebbero risultare utili anche per chi deve aggiornare il proprio comparto server.


Detto questo, ripeto, un buon lavoro ( anche perchè smentisce parzialmente l'ultima comparativa di Anandtech, apparsa a + persone un pò incompleta e frettolosa forse).


Saluti

[cdimauro]

Originariamente inviato da Norbornano
http://www.barefeats.com/macvpc.html

http://www.barefeats.com/mac2pc.html

http://forum.hwupgrade.it/showthread...&pagenumber=10

Peccato che non siano più disponibili la maggior parte dei messaggi di questo forum.

[Hyperion]

Originariamente inviato da Paolo Corsini
Ciao,
considera che in questo caso il risultato migliore è quello più basso, non quello più alto.
Se per fare un calcolo tu impieghi 1636 secondi, e io 1302, si può dire che io ci metto circa il 20% in meno. Infatti, 1636 - 20% di 1636 (327,2)= 1308.

Sarebbe stato del 25%, come tu hai indicato, se fossi partito da 1302 e terminato a 1636, ipotizzando che questi valori non siano tempi (dove il risultato superiore è peggiore) ma ad esempio punti di un test, dove al risultato superiore corrisponde una migliore prestazione.

Probabilmente sarebbe stato meglio scrivere quella frase come

il tempo di elaborazione della scena benchmark è passato da 1636 secondi a 1302 secondi,: si tratta di un risultato inferiore del 20% rispetto a quanto registrato con codice a 32bit.

Probabilmente messa in questo modo avrebbe evitato malintesi. Ho verificato le altre percentuali, comunque, a me risultano tutte corrette.

No Paolo, anche così rimane l'errore nel calcolo della percentuale, ed i motivi sono espressi nel post precedente; non c'entra da chi si parte, è una questione di matematica.

In dettaglio, se c'è di mezzo valori che più alti sono più veloce è il sistema, per il calcolo di quanto A va più di B (meno se viene negativo) il conto è:

(A-B)/B

Mentre se ci sono dati di frequenza, ovvero quanto tempo per effettuare qualcosa, per calcolare quanto A va più di B il conto è:

(A-B)/A

E se scrivi così:

il tempo di elaborazione della scena benchmark è passato da 1636 secondi a 1302 secondi,: si tratta di un risultato inferiore del 20% rispetto a quanto registrato con codice a 32bit.

I conti sono corretti, ma manca il dato significativo del test, ovvero di quanto è più veloce, che non è il 20, ma il 25%.



Ciao!!

[Orsobubu]

Originariamente inviato da joe4th
Quanto all'influenza dell'HyperThread, per vedere
dei dati oggettivi, e non soggettivi basati
su sensazioni o tifo, basterebbe rifare
i test con l'hyperthread disabilitato, in modo che
anziche' vedere 4 CPU logiche il sistema ne
vede solo 2 fisiche...

Esattamente. Posso confermare che l'HT porta un interessante margine di vantaggio quando è abilitato (in alcune applicazioni in particolare, vedi lw)
Se a qualcuno interessa posso postare un paio di bench miei, anche se in rete ce ne sono già un'infinità...

Parziale e' invece considerare
benchmark di vecchi programmi
come Lightwave 7.5 (ma di quanti anni fa
e'? 4?) compilati e ottimizzati per SSE2
(e il Radiosity e' noto che lo e') e per
le dimensioni delle pipeline del P4 come significativi...

Parziale sarebbe valutare questi processori senza testarli con programmi come questi, visto che sono tra i programmi più utilizzati. Cmq per la cronaca lw7.5 avrà si e no un annetto (sono usciti con la 8 qualche mese fa e da uno o due mesi con la 8.2), un sw tutt'altro che vecchio.

[MaxArt]

Originariamente inviato da Hyperion
No Paolo, anche così rimane l'errore nel calcolo della percentuale, ed i motivi sono espressi nel post precedente; non c'entra da chi si parte, è una questione di matematica.

Non sono d'accordo. Paolo ha chiarito bene cosa voleva dire, e dire che c'è stato un decremento dei tempi del 20% è corretto.
(Un decremento del 100% equivale all'azzeramento dei tempi, per togliere ulteriori dubbi. Ed ad un aumento infinito delle prestazioni.)

[MiKeLezZ]

Non ha senso fare i test senza HT.
E' una prerogativa della CPU ed è giusto usarla.. Sarebbe come fare i test dimezzando la cache (ipotizzando la sua possibilità).. non ha senso

[MaxArt]

Originariamente inviato da MiKeLezZ
Non ha senso fare i test senza HT.
E' una prerogativa della CPU ed è giusto usarla.. Sarebbe come fare i test dimezzando la cache (ipotizzando la sua possibilità).. non ha senso

Un senso ce l'ha eccome! Non venirmi a dire che non hai mai visto test in cui l'HT abilitato faceva perdere prestazioni!
Quel che si vuole sapere non è un raffronto diretto senza HT, ma una pura speculazione sull'efficienza di questa tecnologia allo scalare del numero dei processori. E' da tanto che non vediamo niente del genere.

[Orsobubu]

Originariamente inviato da MaxArt
Un senso ce l'ha eccome! Non venirmi a dire che non hai mai visto test in cui l'HT abilitato faceva perdere prestazioni!
Quel che si vuole sapere non è un raffronto diretto senza HT, ma una pura speculazione sull'efficienza di questa tecnologia allo scalare del numero dei processori. E' da tanto che non vediamo niente del genere.

Non ti si può dar torto, soprattutto se si considera che l'HT è cmq un'opzione -disabilitabile-, che sebbene porti ad incrementare la performance con alcune applicazioni (imho infatti è un'ottima funzione), non incontra proprio il favore di tutti (es. vedi DELL che nella configurazione di ws e server chiede se si vuole abilitare o meno l'HT).

[joe4th]

Originariamente inviato da Orsobubu
Esattamente. Posso confermare che l'HT porta un interessante margine di vantaggio quando è abilitato (in alcune applicazioni in particolare, vedi lw)
Se a qualcuno interessa posso postare un paio di bench miei, anche se in rete ce ne sono già un'infinità...

Onestamente sotto Linux, usando kernel SMP (che vede le
2 CPU logiche) su un singolo P4-3.0 800FSB,
l'influenza dell'HT a me e' praticamente NULLA, anzi in alcuni
casi peggiora rispetto a usare un kernel UP che vede 1 ed una sola CPU
(logica e fisica).

Parziale sarebbe valutare questi processori senza testarli con programmi come questi, visto che sono tra i programmi più utilizzati. Cmq per la cronaca lw7.5 avrà si e no un annetto (sono usciti con la 8 qualche mese fa e da uno o due mesi con la 8.2), un sw tutt'altro che vecchio.

Forse non e' 7.5 ma 7.5d, anche perche'
mi sembra difficile pensare che LW7.5 abbia un annetto
quando l'aggiornamento 7.5->7.5b (scaricabile dal sito di NewTek)
e' di ben 3 anni fa...

[Orsobubu]

Originariamente inviato da joe4th
Onestamente sotto Linux, usando kernel SMP (che vede le
2 CPU logiche) su un singolo P4-3.0 800FSB,
l'influenza dell'HT a me e' praticamente NULLA, anzi in alcuni
casi peggiora rispetto a usare un kernel UP che vede 1 ed una sola CPU
(logica e fisica).

Con buona probabilità ci sono di mezzo delle ottimizzazioni a livello s.o. - purtroppo, o per fortuna, a seconda dei casi.

Forse non e' 7.5 da 7.5d, anche perche'
mi sembra difficile pensare che LW7.5 abbia un annetto
quando l'aggiornamento 7.5->7.5b (scaricabile dal sito di NewTek)
e' di ben 3 anni fa...

Lapsus mio: devo aver confuso un'altra release uscita anno fa con l'uscita di lw 7.5.
Cmq si, effettivamente la 7.5 liscia dovrebbe essere uscita a metà 2002: non sono 4 anni ma effettivamente non è nemmeno l'altro ieri.

edit: il fatto di non usare le utlimissime release di determinati sw credo sia dovuta ad una scelta redazionale, non saprei, magari è questione di coerenza con le prove eseguite in precedenza (o ancora in corso) oppure perchè una determinata versione è ancora la più utilizzata. Ad ogni modo, solo Corsini può spiegarci il perchè.