Link all'Articolo: http://www.hwupgrade.it/articoli/business/1177/xeon-3-6-ghz-vs-opteron-250_index.html

Intel ha recentemente introdotto una nuova versione di processore Xeon 3,6 Ghz, dotata di 2 Mbytes di cache L2 integrata on Die. In sistemi biprocessore questa cpu si posiziona a diretta concorrenza con il processore AMD Opteron, soluzione qui provata nella versione 250 a 2,4 GHz di clock

Click sul link per visualizzare l'articolo.

Bellissimo articolo Paolo, me lo sono letteralemte divorato... :D

Perchè i P4 hanno 4GB di ram mentre gli opteron 1GB? (mi riferisco alle img di winXP64)

Spero che nei test abbiate usato quantitativi di memoria uguali :D

ma il coso di una soluzione opteron rispetto ad una xeon come si posiziona?

bravissimi!finalmente un test su piattaforme dual cpu!!!
ottimo articolo me lo sono divorato anche io!ed ho notato come una roccaforte del domino intel degli ultimi anni; il rendering in 3ds Max, sia stata ormai conquistata anche da AMD, e pensare poi che l'opteron testato non è il top di gamma, chissà cosa farà il modello da 2.6ghz!!!!
ancora bravi

Originariamente inviato da Dreadnought
Perchè i P4 hanno 4GB di ram mentre gli opteron 1GB? (mi riferisco alle img di winXP64)

Spero che nei test abbiate usato quantitativi di memoria uguali :D
Sono solo screenshot fatti durante l'installazione; la dotazione era identica nei due sistemi

un opteron vetusto dà la paga in encoding sia xvid e divx a l'ultimo xeon ? :wtf:

strano s'è sempre detto che gli intel vanno meglio in editing video e gli amd nel resto, qua risulta l'opposto.
cmq bella cpu pure sto xeon

credo che sia x il fatto del dual.... gli opteron scalano meglio le prestazioni con l'aumentare dei processori utilizzati

due cose da dire: la prima per fare i complimenti per la recensione :)

la seconda, che finalmente abbiamo un test che chiarisce che alcune volte va meglio intel e altre volte va meglio amd, se ne sentiva il bisogno :D:D:D

io comunque non capirò mai come mai le WU seti siano ottimizzate così tanto per intel

Originariamente inviato da frankie
io comunque non capirò mai come mai le WU seti siano ottimizzate così tanto per intel


vabbè ma seti mica è un applicazione o un benchmark sintetico
imho ha senso solo per valutare overclock o incrementi di prestazioni a parità di piattaforma.

Non mi è chiara un'affermazione alla pagina 7 (http://server.hwupgrade.it/articoli/1177/7.html), che commenta il Cinebench 2003:
La cpu Opteron 250, in modalità single core, si avantaggia leggermente su quella Xeon a 3,6 GHz di clock. Il processore Intel ricupera tutto il divario in configurazione multiple, quindi facendo uso sia del secondo processore fisico installato nel sistema, che degli altri due logici integrati grazie alla tecnologia HyperThreading.
Ma, se l'unità di misura è, come indicato, il tempo, non è l'opposto?

Curiosità: anche sul server del database fate girare SUSE, oppure avete una distro tipo debian?
Magari la suse l'avete usata come test per via dell'installazione veloce?

Originariamente inviato da davidon
ma il coso di una soluzione opteron rispetto ad una xeon come si posiziona?
quoto in pieno davidon...

sò che i vostri server erano in comodato (almeno quello intel era in comodato, se non erro).. però ci sono differenze di prezzo? e se ci sono.. di quanto sono? ;) :cool:

PS: cmq secondo me avete sbagliato una cosa

Pagina 10, Mainconcept MPEG Encoder

Margine di vantaggio di poco superiore al 7% per il sistema AMD Opteron 250 su quello Xeon 3,6 GHz; in questo caso la conversione con tool Mainconcept non permette di sfruttare la seconda cpu montata nel sistema, situazione che svantaggia la cpu Xeon a confronto con quella Opteron.


perche mai dovrebbe essere svantaggiato lo xeon se il test è stato eseguito su una sola cpu? le cpu xeon ha cmq l'hyperthreading che permette di gestire 2 thread al posto di 1 solo dell'amd e quindi dovrebbe essere avvantaggiata (Visto che la compressione mpeg2 è usata in multithread, ottimizzata anche per intel)

...questo solo per fare il pignolo :D

per parita di confronto avrei utilizzato i nuovi opteron 252 ,da 2,6 giga e SSE3

dico solo questo :sbav: e dico anche che OPTERON rulezzz!!! anche se non di molto...imho il distacco aumenterà di parecchio con l'avvento degli Opteron252 :D che spettacolo

Caro Paolo, complimenti per la recensione,
ma secondo me avete perso, per l'ennesima
volta, una buona occasione di postare
un po' di risultati
su test eseguiti raffrontando
entrambe le macchine con Linux a 64bit
(e nella fattispecie con quantititativi
di memoria superiori a 4GB di RAM). Ora che i Nocona supportano l'EM64T non ci sono piu' scuse...

Francamente non riesco a capire perché, pur
avendo provato a installare Linux a 64bit,
vi siete limitati a postare solo alcune
righe circa i test eseguiti con i vostri
DB. Avete quasi dedicato piu' spazio al
testing di un prodotto come Windows 64bit professional
beta che non e' nemmeno ancora sul mercato.
Vi ricordo che ci sono diverse distribuzioni
a 64bit, dalla SuSE alla Mandrakelinux 10.1 X86_64,
alla Debian. C'e' solo l'imbarazzo della scelta.

E per queste distribuzioni sono disponibili numerosi
software compilati nativamente, compreso POVRay
che avete utilizzato per i test su Windows.
Fra questi anche software di encoding, come
mplayer/mencoder (le ultime versioni superiori alla
1.0pre6 compilano nativamente anche a 64bit)
con libavcodec, ffmpeg o lame, apache (e di
test per apache ce ne sono un bel po').
Non solo, ma potrete specificare voi stessi
i flag di compilazione (ottimizzando per
ciascun processore). Per non parlare
del classico benchmark di compilazione del kernel
Linux. Mi auguro che quando vi arriveranno
gli Opteron 252 potrete colmare queste lacune.

Ciao.

gran bel lavoro, sono stato incollato fino all'ultima parola al pc! Magari la prossima volta fate qualche test anche con linux, se possibile (pura curiosità, in quanto sistemi del genere non potrei mai permettermeli, ne li sfrutterei a dovere)

Pensavo che l'opteron costasse meno e invece il 250 costa attorno ai 950€, mentre lo xeon 3.6GHz con 1MB di cache sui 900€.

Originariamente inviato da frankie
io comunque non capirò mai come mai le WU seti siano ottimizzate così tanto per intel

Seti non è ottimizzato per intel... invece la cosa è dovuta al fatto che gli xeon hanno l'hyperthreadig e siccome seti@home sfrutta al massimo i sistemi multiprocessori (e quindi utilizza al massimo anche l'HT), il sistema dual xeon dal punto di vista di seti è quasi come se fosse un sistema con 4 processori (vengono svolti 4 thread per volta).
Gli opteron non hanno HT, quindi il sistema basato su amd resta un dual e quindi esegue solo 2 thread per volta...
Non si ha proprio un raddoppio delle prestazioni ma cmq il boost è molto elevato :)

PS: io ormai sono talmente assueffato all'HT, che quando passo ad un sistema senza HT mi ci trovo estremamente male :)

Originariamente inviato da checo
vabbè ma seti mica è un applicazione o un benchmark sintetico
imho ha senso solo per valutare overclock o incrementi di prestazioni a parità di piattaforma.

non mi pare proprio che seti sia stato scritto per l'utilizzo di cui tu vai affermando :O

Originariamente inviato da LASCO
Pensavo che l'opteron costasse meno e invece il 250 costa attorno ai 950€, mentre lo xeon 3.6GHz con 1MB di cache sui 900€.

una volta amd costava molto meno di intel, invece la favola è finita..... ;)

Originariamente inviato da checo
strano s'è sempre detto che gli intel vanno meglio in editing video e gli amd nel resto, qua risulta l'opposto.La risposta è abbastanza semplice: gli Opteron scalano meglio in prestazioni col multiprocessing rispetto allo Xeon. In molti campi la situazione si ribalta. Mi piacerebbe comunque vedere un Seti@home con 2 WU su un sistema dual, e non con 4 WU: si evidenzierebbe molto chiaramente come stanno le cose.
Io comunque avrei aspettato di avere tra le mani un bell'Opteron 252 piuttosto che fare un confronto con un processore "vecchio".

Povray (...) con i processori Opteron 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 test con processore Xeon ha portato addirittura ad un incremento dei tempi di elaborazione, passati da 1667 a 1768 secondi. 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.A quanto pare, invece c'è chi è riuscito a spiegare il motivo di quel decremento. X-bit Labs (http://www.xbitlabs.com/articles/cpu/display/x86-64-rc1_11.html) giustifica:

It is a different story with Pentium 4 processors supporting EM64T technology. (...) Some instructions, such as integer multiplication or shift are performed much slower in 64-bit mode than their 32-bit analogs because of the NetBurst architectural peculiarities. Therefore, porting programs with integer arithmetic for EM64T may sometimes cause their slowing down, even though there are more general-purpose registers involved and the register width is higher.
Mandelbrot benchmark and PovRay 3.6 are exactly the tasks of the kind: both these applications work actively with integers and use multiplication a lot. That is why the results you saw above are absolutely natural.

Quindi, sono alcune operazioni che rendono paradossalmente più lento il P4 a 64 bit di quello a 32.

Originariamente inviato da LASCO
Pensavo che l'opteron costasse meno e invece il 250 costa attorno ai 950€, mentre lo xeon 3.6GHz con 1MB di cache sui 900€.Già, ma quello testato ha 2 MB di cache L2 ;)

Originariamente inviato da riaw
due cose da dire: la prima per fare i complimenti per la recensione :)

la seconda, che finalmente abbiamo un test che chiarisce che alcune volte va meglio intel e altre volte va meglio amd, se ne sentiva il bisogno :D:D:D
questo ke hai detto è indubbio....
nn dimenticare però unacosa.... la makkina INTEL è il top di gamma, la makkina AMDè SOLO un 250...
il 252 ha 200 mhz in + e le sse3.....

x qto riguarda il seti dico solo una cosa... Fast Fourier Transform....
ke si avvantaggia MOLTo x la cahce maggiorata e soprattutto x l'HT... nn è come avere due processori fisici anzikè logici.... però è MOLTO più lineare della maggior parte delle applicazioni, e qdi comporta poki branch misprediction..... acerrimi nemici soprattutto dell'arkitettura INTEL....

cmq concordo con maxart riguardo alle considerazioni sui decrementi prestazionali degli xeon...... una cosa è progettare appositamente un'arkitettura x x86-64 (e tutti noi sappiamo qto tempo amd vi abbia dedicato), altra cosa è riadattare un'arkitettura nata appositamente x scalare bene in freq (kosa ke poi non è avvenuta, come abbiamo visto) x usare le estensioni a 64 bit...

Ma cè un qualche motivo per il quale non inserite in un bellissimo confronto come questo anche un dual g5 con 2x 2,5 ghz ? cosi si darebbe una bellissima risposa alle migliaia di discussioni sull'eterno confronto tra power mac e pc ! è tutto falso lquello che dice la apple sulla potenza che straccia i pentium e gli amd ? o cè qualcosa di vero ? e perche non dimostrare con i piu possibili software esistenti su entrambe le piattaforme quindi sicuramente ottimizzate per entrambi...tipo una bella suite video e programmi di 3d quindi ...programmi che davvero necessitano di potenza spropositata che porta un utente a cercare il dual processor ? cioè ti pongo una mia domanda : io che sono sempre stato pro pc e sempre avverso ai mac ma lavoro con video e grafica 3d stavo facendo un pensierino al dual processor (ovviamente aspetto i dual core ) e sono nel dubbio amletico se convertirmi al mac col dual g5 ma non vorrei ...tipo una bella prova come quella che hai appena fatto con un dual g5 mi avrebbe fugato ogni dubbio :(
mi auguro che la prossima che farai ti ricorderai di me :)

ciao e complimenti per l'ottimo lavoro

Originariamente inviato da aLLaNoN81
non mi pare proprio che seti sia stato scritto per l'utilizzo di cui tu vai affermando :O


:rolleyes: :rolleyes:

Originariamente inviato da aLLaNoN81
una volta amd costava molto meno di intel, invece la favola è finita..... ;)


esxatto anche perchè la cpu testata non è quella citata poco sopra ma una con 2 mb di l2.

per inciso i prezzi????

Originariamente inviato da Mr.Gamer
quoto in pieno davidon...

sò che i vostri server erano in comodato (almeno quello intel era in comodato, se non erro).. però ci sono differenze di prezzo? e se ci sono.. di quanto sono? ;) :cool:

PS: cmq secondo me avete sbagliato una cosa

Pagina 10, Mainconcept MPEG Encoder


perche mai dovrebbe essere svantaggiato lo xeon se il test è stato eseguito su una sola cpu? le cpu xeon ha cmq l'hyperthreading che permette di gestire 2 thread al posto di 1 solo dell'amd e quindi dovrebbe essere avvantaggiata (Visto che la compressione mpeg2 è usata in multithread, ottimizzata anche per intel)

...questo solo per fare il pignolo :D
Ciao,
se è single Thread, lo Xeon utilizza solo 1 processore dei 4 logici presenti nel sistema. Se apri il task manager di Windows vedi la percentuale di occupazione del processore al 25%, non al 50%, tanto per intenderci. HyperThreading non viene sfruttato in questo caso.

Originariamente inviato da jan
per parita di confronto avrei utilizzato i nuovi opteron 252 ,da 2,6 giga e SSE3
E' stato spiegato in più punti il perché siano state adottate quelle configurazioni di test.

Originariamente inviato da joe4th
Caro Paolo, complimenti per la recensione,
ma secondo me avete perso, per l'ennesima
volta, una buona occasione di postare
un po' di risultati
su test eseguiti raffrontando
entrambe le macchine con Linux a 64bit...
Ciao,
ho tagliato il tuo post per non allungare troppo.
Cosa aggiungere: hai ragione. Mi sarebbe piaciuto molto cercare di inserire più test in ambiente Linux, e in ufficio abbiamo fatto parecchie prove interne con distribuzioni a 64bit.
Purtroppo, però, per i soliti arcinoti problemi di tempo non è stato possibile fare di più. Lunedì mattina parto per gli Stati Uniti per partecipare all'Intel Developer Forum; rientro dopo una settimana e riparto quasi subito per il Cebit di Hannover.
Questo avrebbe voluto dire tenere in sospeso questi test per altre 2 settimane, ben sapendo che al ritorno dal Cebit mi ritroverò sommerso da altro lavoro rimasto in sospeso per via delle 2 settimane via dalla redazione.
E' stata una scelta obbligata; a questo aggiungi che le configurazioni in test non possono restare per mesi in redazione, in quanto destinate anche ad altre riviste per effettuare dei test.

Originariamente inviato da D@niel
Ma cè un qualche motivo per il quale non inserite in un bellissimo confronto come questo anche un dual g5 con 2x 2,5 ghz ? cosi si darebbe una bellissima risposa alle migliaia di discussioni sull'eterno confronto tra power mac e pc ! è tutto falso lquello che dice la apple sulla potenza che straccia i pentium e gli amd ? o cè qualcosa di vero ? e perche non dimostrare con i piu possibili software esistenti su entrambe le piattaforme quindi sicuramente ottimizzate per entrambi...tipo una bella suite video e programmi di 3d quindi ...programmi che davvero necessitano di potenza spropositata che porta un utente a cercare il dual processor ? cioè ti pongo una mia domanda : io che sono sempre stato pro pc e sempre avverso ai mac ma lavoro con video e grafica 3d stavo facendo un pensierino al dual processor (ovviamente aspetto i dual core ) e sono nel dubbio amletico se convertirmi al mac col dual g5 ma non vorrei ...tipo una bella prova come quella che hai appena fatto con un dual g5 mi avrebbe fugato ogni dubbio :(
mi auguro che la prossima che farai ti ricorderai di me :)

ciao e complimenti per l'ottimo lavoro
Ciao,
personalmente sono scettico sull'efficacia di un confronto di questo tipo, limitato al solo utilizzo di benchmark. Stiamo parlando di architetture e filosofie software molto differenti tra di loro, alle quali ovviamente bisogna aggiungere anche le potenze di elaborazione che variano da cpu a cpu.
A prescindere da preferenze personali, e dalla continua diatriba tra PC e MAC su quale sia il più veloce-bello-aggiornabile e mettete quello che volete, mi sembra che un confronto di questo tipo tenda a vedere solo un elemento dell'equazione.

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

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

Sinceramente ci sono rimasto un po' male. E' vero che i clock di AMD sono decisamente piu' bassi della concorrenza ma pensavo (sicuramente da ignorante) che le 2 piattaforme fossero molto simili in termini di risultati. Invece lo Xeon sgranocchia secondi su secondi nei test. Alla fine somma secondi di qua secondi di la'... risparmi un bel po' di tempo!

Ma e' solo una questione di potenza pura del processore o anche di software che non sono ottimizzati per AMD ed invece lo sono per INTEL ?

Bè come è già stato detto l'ht avvantaggia con alcune applicazioni lo Xeon rispetto all'Opteron, che peraltro, come già evidenziato, non è il top di gamma AMD.

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.

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.

...in effetti mi pare un bel po' più prestazionale lo xeon, se costano più o meno la stessa cifra si può tranquillamente dire che l'opteron non conviene una mazza, condivido che ci si poteva sbilanciare nettamente in favore di xeon nelle conclusioni.

Costi: il costo dell'Opteron 252 e' lo stesso
di quello che aveva l'Opteron 250 prima che
uscisse l'Opteron 252, ovvero 851 dollari.
Lo Xeon DP 3.6GHz con 2MB di cache non
ho trovato dati certi, ma forse costa proprio
851 dollari.

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...

Che il raddoppio nella
cache (sarebbe quindi interessante allora
vedere che effetto fa nella versione
Xeon MP con 8MB di cache...) porti dei
notevoli benefici agli Xeon 3.6 e' indubbio,
ma gli Opteron (perfino il vecchio
250...) onestamente non mi sembrano
superati.

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...

Perche' quando ci sono articoli con i bench
del tipo "King Kong vs Godzilla" o "Goldrake
vs Mazinga" non postate anche i benchmark normalizzati
(per esempio messi in modo da
visualizzarli quando vengono cliccati). Ovvero
si assegna il valore di 1 (100%) al piu'
veloce e l'altro si rappresenta in proporzione.

Originariamente inviato da Paolo Corsini
Ciao,
personalmente sono scettico sull'efficacia di un confronto di questo tipo, limitato al solo utilizzo di benchmark. Stiamo parlando di architetture e filosofie software molto differenti tra di loro, alle quali ovviamente bisogna aggiungere anche le potenze di elaborazione che variano da cpu a cpu.
A prescindere da preferenze personali, e dalla continua diatriba tra PC e MAC su quale sia il più veloce-bello-aggiornabile e mettete quello che volete, mi sembra che un confronto di questo tipo tenda a vedere solo un elemento dell'equazione.

cmq non chiedevo di fare dei benchmark sui giochi o un super pi , che in definitiva non me ne frega , ma ti parlavo ti testarli in ambito prettamente professionale , cioe con i software che rsupportano i multiprocessori anche i due link su messi sul confronto g5 vs pc non mi soddisfano , e come guardare quelli sul sito apple , ma una recenzione del genere mi avrebbe schiarito le idee , cioe prima di fare un passo del genere vorrei esserne certo e un dual g5 lo ha comprato un mio amico appena arriva ci smanettero un bel po ma io per ora ho il notebook solo quindi sarei davvero curioso di confrontare con un sitema dual xeon e opteron i risultati di rendering ( io uso molto after , maya , photoshop , premiere poser bryce ecc e vari prog di encoding ) quindi dovro farla sta spesa per un dual processor anche se mi conviene apsettare i dual core ....e chissa se non tarda tanto il cell :)

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.

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.

SETI è un programma che, per quanto utile, non è il (solo) target di queste macchine. Stesso discorso per Lightwave e compagnia bella: sono test di rendering, che quindi (a parte che sono applicazioni da workstation e non da server) rispecchiano solo un campo molto ristretto di utilizzo (e tra l'altro fino a pochissimo tempo fa ad esempio su programmi come Maya la situazione era esattamente opposta, e su programmi CAD come ad esempio Solidworks e PRO/E le cifre sono ben differenti). I compiti server sono soprattutto altri, come gestione database, file server, server web, e via dicendo. Infatti se un appunto si può muovere a questo articolo è che ha fatto una selezione molto scarna di test, e per giunta tutte tradizionalmente tra le più favorevoli all'architettura Netburst (rendering, multimedia) e sotto un unico sistema operativo, che non è detto che sia il più utilizzato in ambito server. Quindi volerci andare a trovare la parzialità a favore di AMD è quantomeno forzato ;) Tanto è vero che anche lo staff ha palesato l'intenzione di voler ampliare la suite di test per questo motivo. Ed è proprio per questo motivo che la redazione non si è sbilanciata a dire "Xeon ora va meglio di Opteron" in base a quei test: sono troppo pochi e male bilanciati (Non vuole esser euna critica, capisco la mancanza di tempo)
Ad ogni modo, sicuramente il confronto andrebbe fatto tra le versioni 252 e 3,6, e si dovrebbe anche fare qualche test a 4 vie, dato che in quel caso si andrebbe a verificare la scalabilità ulteriore dei sistemi, oltre a fare dei test sotto Linux e 64 bit per valutare l'impatto delle future tecnologie sulle prestazioni dei sistemi. Sicuramente toccherà lavorare di più, per cui non uccidetemi ;)

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!!

Bisogna giusto intendersi sui termini. Potremmo parlare allora di "un decremento dei tempi di esecuzione del 20%" :rolleyes:
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 (http://www.xbitlabs.com/articles/cpu/display/x86-64-rc1_10.html) ;)

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.....

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

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.

appunto...

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 :)

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...

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.

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.

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

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

http://www.barefeats.com/mac2pc.html
http://forum.hwupgrade.it/showthread.php?s=&threadid=847300&perpage=20&highlight=&pagenumber=10

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

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!!

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.

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.)

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

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.

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).

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...

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è.

comunque sicuri ci siano differenze fra usare la versione 7 e la 8 ?

cioè se faccio un test con winrar, se uso la versione 3.1 oppure 3.4 la prestazioni dei due processori rimangono le stesse così come i risultati, o no?

complimenti per il test,davvero ottimo e ben organizzato
comunque, avete provato a verificare le prestazioni di codeste caratteristiche sia in ambiente linux che windows?
(perchè su una rivista ho letto che windows sarebbe piu veloce di linux..mah)

Originariamente inviato da MiKeLezZ
comunque sicuri ci siano differenze fra usare la versione 7 e la 8 ?

cioè se faccio un test con winrar, se uso la versione 3.1 oppure 3.4 la prestazioni dei due processori rimangono le stesse così come i risultati, o no?

Dipende dal software, se un software e' ottimizzato per un particolare
processore con particolari dimensioni di cache.
Le mie osservazioni riguardavano il fatto che il radiosity
potrebbe essere particolarmente ottimizzato per SSE2 e
per l'architettura P4.

Ti posso citare alcuni esempi: usare per esempio con l'Intel C 8.X o Fortran 8.X
Compiler con le ottimizzazioni selvaggie a manetta per il
P4, posso ottenere degli eseguibili che su Opteron danno
dei risultati ben peggiori di quanto
invece delle ottimizzazioni selvaggie per P4 uso quelle generiche.
Un classico esempio sono le librerie ATLAS (ho comunque
il sospetto che il gcc3.4.3 e 4.0 per Opteron abbiano
ormai superato il PathScale e l'Intel compiler in quanto a
ottimizzazioni).

Per quanto riguarda Lightwave, comunque ne hanno annunciata
una versione nativa a 64bit (chissa' se ottimizzata per Opteron o P4)
qualche mese fa. Pare aspettino Windows XP 64bit Pro per farla
uscire...

mi sorge un dubbio: se devo far girare un codice che occupa X mega di ram, e lo faccio girare su un procio con Y mega di cache, con Y>X, allora c'è la possibilità di farlo girare senza che acceda alla ram di sistema ma solo alla sua cache?
se dico stupidaggini fermatemiiiiiiiiiii........:D

ciaoooooooooo

Originariamente inviato da joe4th
Ti posso citare alcuni esempi: usare per esempio con l'Intel C 8.X o Fortran 8.X
Compiler con le ottimizzazioni selvaggie a manetta per il
P4, posso ottenere degli eseguibili che su Opteron danno
dei risultati ben peggiori di quanto
invece delle ottimizzazioni selvaggie per P4 uso quelle generiche.Perdonami, l'ho letta almeno 4 volte ma non sono riuscito a capire cos'hai scritto! :boh:

Originariamente inviato da peter2
mi sorge un dubbio: se devo far girare un codice che occupa X mega di ram, e lo faccio girare su un procio con Y mega di cache, con Y>X, allora c'è la possibilità di farlo girare senza che acceda alla ram di sistema ma solo alla sua cache?Ahahah! :asd:
Diciamo che la RAM in quel caso sarebbe utile solo come spazio di precaricamento di dati/codice da disco, ma è pura fantainformatica!

Originariamente inviato da MaxArt
Perdonami, l'ho letta almeno 4 volte ma non sono riuscito a capire cos'hai scritto!

Provo a farti un esempio. Come saprai alcune applicazioni sono ottimizzate (adesso) per sfruttare le SSE3, presenti attualmente solo sui processori Intel più recenti. Un compilatore (prodotto da chiunque) può permetterti (a seconda delle scelte operate dallo sviluppatore, ovvero della sua "qualità" ) di ottimizzare il codice per una certa architettura: in questo caso, potresti decidere di voler sfruttare le SSE3 e impostare i flag del compilatore per farlo. Il codice prodotto verrà eseguito più rapidamente sulle cpu che possiedono queste istruzioni, ma potrebbe mandare in crash sistemi basati su altre cpu. Per ovviare a questo problema si introducono porzioni di codice generico (che sfrutta solo le istruzioni e le unità di calcolo sicuramente presenti su tutti i processori x86) da sostituire all'occorrenza (sostanzialmente il programma riconoscerà il processore e sceglierà la "versione" da utilizzare): ad esempio, si potrebbero sostituire le istruzioni delle SSEx che sostituiscono e accelerano il calcolo di una radice con delle istruzioni più "tradizionali" affidate alla cpu. A questo devi aggiungere che i compilatori Intel potrebbero produrre un codice generico (non ottimizzato per una particolare architettura) poco efficiente per cpu non Intel (questa non vuol essere una critica: avrebbe poco senso per la Intel investire tempo e denaro nella progettazione di un compilatore che produca un codice che avvantaggi la concorrenza), prova ne sia che alcune patch (non proprio "ortodosse" ) rimuovono il riconoscimento dei processori non Intel e "sbloccano" le ottimizzazioni. Se invece non ottimizzi il codice per una certa architettura, i risultati dovrebbero essere allineati (ipotizzando una migliore qualità del codice prodotto generico per i P4 dai compilatori Intel e considerando la maggiore efficienza dell'unità in virgola mobile degli AMD i conti tornano, anche con qualche piccolo vantaggio per i Pentium - sempre parlando dei compilatori Intel).

Originariamente inviato da MiKeLezZ
cioè se faccio un test con winrar, se uso la versione 3.1 oppure 3.4 la prestazioni dei due processori rimangono le stesse così come i risultati, o no?

Dipende dalla natura delle modifiche: se ritoccano solo l'interfaccia e aggiungono/migliorano qualche feature, oltre a risolvere qualche bug, no. Se invece toccano anche gli algoritmi "di lavoro" (nel caso di winrar, l'implementazione dell'algoritmo di compressione), i risultati potrebbero variare a seconda delle ottimizzazioni effettuate (entra in gioco il discorso di joe4th).

Bye.

Quoto quanto appena detto da Joe4th e Xeal, ed aggiungo per Mikelezz: in effetti non ci è dato di sapere quanto a livello di ottimizzazione sia cambiato dalla rel 7 alla 8. In genere quando viene rilasciata una patch si segnalano i vari bug fix, con le ventuali funzioni aggiunte, ma le ottimizzazioni vengono chiaramente solo accennate, tipo "improve render quality..." o "render with radiosity is 15% faster...". Per approfondire sarebbe utile dare un occhio ai vari readme delle release rilasciate...

qualcuno potrebbe rimettere apposto il tasto stampa? GRAZIE..

Originariamente inviato da peter2
mi sorge un dubbio: se devo far girare un codice che occupa X mega di ram, e lo faccio girare su un procio con Y mega di cache, con Y>X, allora c'è la possibilità di farlo girare senza che acceda alla ram di sistema ma solo alla sua cache?
se dico stupidaggini fermatemiiiiiiiiiii........:D

ciaoooooooooo

:muro: Se la cache potesse essere grande come la ram quest'ultima nn avrebbe modivo di esistere!

L'unico motivo xké esista la cache è ke quest'ultima è molto + veloce della ram ma anke moooooolto + costosa!

Originariamente inviato da filosganga
:muro: Se la cache potesse essere grande come la ram quest'ultima nn avrebbe modivo di esistere!

L'unico motivo xké esista la cache è ke quest'ultima è molto + veloce della ram ma anke moooooolto + costosa!


appunto, ma se io ho un prog che occupa 1 MB e un procio con 2 MB di cache allora c'è la possiblità che non scambi dati con la ram?

Originariamente inviato da peter2
appunto, ma se io ho un prog che occupa 1 MB e un procio con 2 MB di cache allora c'è la possiblità che non scambi dati con la ram? La possibilità, sì, se il processore ha tutti i dati che gli servono all'interno del suo stesso eseguibile e se la cache non è già occupata abbastanza da altri processi :rolleyes:

x peter2. Dipende da quel che fa il programma: se manipola dati, molto probabilmente continuerà ad accedere alla ram, anche se il codice sta tutto nella cache...

Originariamente inviato da cdimauro
x peter2. Dipende da quel che fa il programma: se manipola dati, molto probabilmente continuerà ad accedere alla ram, anche se il codice sta tutto nella cache...

beh certo che manipola i dati....quale applicazione non lo fa? :D

Sì, ma i dati possono anche rimanere interamente nella cache, se sono pochi... ;)

EDIT: C'era un "se" di troppo all'inizio... :p

Originariamente inviato da cdimauro
Sì, ma se i dati possono anche rimanere interamente nella cache, se sono pochi... ;)

non capisco:confused:

Originariamente inviato da peter2
non capisco:confused: Ogni programma ha bisogno di un certo quantitativo di memoria per eseguire le sue operazioni. Se questo quantitativo è inferiore alle dimensioni della cache, allora non ha bisogno di ulteriori accessi alla RAM.

Originariamente inviato da MaxArt
Ogni programma ha bisogno di un certo quantitativo di memoria per eseguire le sue operazioni. Se questo quantitativo è inferiore alle dimensioni della cache, allora non ha bisogno di ulteriori accessi alla RAM.


esattamente quello che dicevo io... ma allora perchè dicevi:"....ma è pura fantainformatica!"?

ciao

Originariamente inviato da peter2
esattamente quello che dicevo io... ma allora perchè dicevi:"....ma è pura fantainformatica!"?Perché avevo travisato, ho letto di un sistema con più cache che RAM :rolleyes:
Però, è quasi ancora fantainformatica, perché quali sono i programmi che stanno tutti nella CACHE? Pressoché nessuno! :p

Originariamente inviato da MaxArt
Perché avevo travisato, ho letto di un sistema con più cache che RAM :rolleyes:
Però, è quasi ancora fantainformatica, perché quali sono i programmi che stanno tutti nella CACHE? Pressoché nessuno! :p

il codice numerico scritto da me per la tesi occupa 2048 byte... su che procio potrei provarlo? :boxe: :boxe:

Originariamente inviato da MaxArt
Perché avevo travisato, ho letto di un sistema con più cache che RAM :rolleyes:
Però, è quasi ancora fantainformatica, perché quali sono i programmi che stanno tutti nella CACHE? Pressoché nessuno! :p

Super PI? Occupa circa 1,5 mega, ed anche i dati su cui opera possono essere contenuti nella cache.
Ragione per cui sui Dothan andava circa il 30% in più che non sui Banias ;)

Originariamente inviato da leoneazzurro
Super PI? Occupa circa 1,5 mega, ed anche i dati su cui opera possono essere contenuti nella cache.
Ragione per cui sui Dothan andava circa il 30% in più che non sui Banias ;)


e a livello di programmazione/compilazione bisogna adottare qualche procedimeto particolare per farlo lavorare solo su cache?

Originariamente inviato da leoneazzurro
Super PI? Occupa circa 1,5 mega, ed anche i dati su cui opera possono essere contenuti nella cache.
Ragione per cui sui Dothan andava circa il 30% in più che non sui Banias ;) Ho detto pressoché nessuno, non proprio nessuno :)
Se è per questo, uno se lo può far da solo un programmino che sta tutto in cache.

Originariamente inviato da peter2
e a livello di programmazione/compilazione bisogna adottare qualche procedimeto particolare per farlo lavorare solo su cache?

Non credo, ma non essendone sicuro giro la palla al Dott. Di Mauro, che di programmazione ne capisce parecchio più di me :D

Originariamente inviato da peter2
non capisco:confused:
Mea culpa: ho messo un "se" di troppo... :(

Originariamente inviato da peter2
il codice numerico scritto da me per la tesi occupa 2048 byte... su che procio potrei provarlo? :boxe: :boxe:
Puoi provare su un Commodore VIC20, che monta un 6502... :D

Originariamente inviato da peter2
e a livello di programmazione/compilazione bisogna adottare qualche procedimeto particolare per farlo lavorare solo su cache?
L'esperienza.
Un buon programmatore può capire in che modo lavorerà il codice (nel caso migliore, in quello peggiore, e in quello medio, che è quello più importante), e cercare di scriverlo in modo che tenga in considerazione il fattore cache.

Ci sono delle cose, però, da considerare:
1) non si conosce la quantità di cache dei sistemi su cui girerà il codice;
2) non è facile né è detto che sia sempre possibile realizzare programmi che girino sempre nella cache;
3) normalmente non ha senso perdere tempo su questo cose, a meno che non ci si trovi in particolari ambiti applicativi in cui l'efficienza e la velocità sono gli obiettivi più importanti (dopo il corretto funzionamento del codice :D).

Originariamente inviato da MaxArt
Se è per questo, uno se lo può far da solo un programmino che sta tutto in cache.
Vedi sopra: non sempre questo è possibile. ;)

Originariamente inviato da cdimauro
Vedi sopra: non sempre questo è possibile. ;) Non sempre, questo è vero. Ma se uno vuol fare un programma il cui unico scopo è girare nella cache... beh, non vedo che impedimenti ci siano :D
Poi, basti pensare al mondo x86 dove, come minimo, abbiamo 192 KB di cache tra L1 ed L2.

Originariamente inviato da MaxArt
Non sempre, questo è vero. Ma se uno vuol fare un programma il cui unico scopo è girare nella cache... beh, non vedo che impedimenti ci siano :D
Poi, basti pensare al mondo x86 dove, come minimo, abbiamo 192 KB di cache tra L1 ed L2.

Se stiamo parlando di CPU uscite negli ultimi 5 anni, il minimo è intorno a 160 KB :D

Originariamente inviato da leoneazzurro
Se stiamo parlando di CPU uscite negli ultimi 5 anni, il minimo è intorno a 160 KB :D Ah, sì, dimenticavo il primo Celeron derivato dai P4... :Puke:

Originariamente inviato da MaxArt
Non sempre, questo è vero. Ma se uno vuol fare un programma il cui unico scopo è girare nella cache... beh, non vedo che impedimenti ci siano :D
Poi, basti pensare al mondo x86 dove, come minimo, abbiamo 192 KB di cache tra L1 ed L2.

Comunque ragazzi nn so ki di vuoi ha studiato Sistemi operativi ma l'utilizzo della cache è sconosciuto al programmatore il sistema operativo si occupa di usarla come meglio crede secondo vari algoritmi ora purtroppo non mi trovo il libro si SO sotto mano, per esempio il linux usa l'algoritmo dell'orologio o una variazione di esso anke se è possibile usare altri algoritmi in fase di compilazione del kernel quindi tutto dipende dal SO usato e dal numero di accessi fatti ad una stessa pagina. se il vodtro programma è anke minuscolo ma accede a dati ke stanno su pagine di memoria lontane fra loro è facile ke fra un tempo di esecuzione del processo e il successivo quella pagina non risieda più in cache. quindi la relazione fra ram e cache nn è così facile e dipende dal sistema operativo. Cmq un qualsiasi sistema operativo moderno in esecuzione okkupa di gran lunga + di 1 o 2 mb e nn si puo evitare di farlo girare :)

Originariamente inviato da MaxArt
Non sempre, questo è vero.
Appunto. Ho detto che non sempre è possibile... ;)
Ma se uno vuol fare un programma il cui unico scopo è girare nella cache... beh, non vedo che impedimenti ci siano :D
Indubbiamente. Ma in generale, non è questo il caso... ;)
Poi, basti pensare al mondo x86 dove, come minimo, abbiamo 192 KB di cache tra L1 ed L2.
Solo di recente... Perché fino al 386 nessun processore x86 è stato dotato di cache: né L1 né tanto meno L2... :p

Originariamente inviato da MaxArt
Ah, sì, dimenticavo il primo Celeron derivato dai P4... :Puke:
Forse non ricordi il primo Celeron (in assoluto): non aveva cache L2!!! :D :D :D

Originariamente inviato da filosganga
Comunque ragazzi nn so ki di vuoi ha studiato Sistemi operativi
;)
ma l'utilizzo della cache è sconosciuto al programmatore il sistema operativo si occupa di usarla come meglio crede secondo vari algoritmi ora purtroppo non mi trovo il libro si SO sotto mano, per esempio il linux usa l'algoritmo dell'orologio o una variazione di esso anke se è possibile usare altri algoritmi in fase di compilazione del kernel quindi tutto dipende dal SO usato e dal numero di accessi fatti ad una stessa pagina. se il vodtro programma è anke minuscolo ma accede a dati ke stanno su pagine di memoria lontane fra loro è facile ke fra un tempo di esecuzione del processo e il successivo quella pagina non risieda più in cache. quindi la relazione fra ram e cache nn è così facile e dipende dal sistema operativo.
Ti stai confondendo: ti riferisci alla cache delle pagine presenti in memoria, ossia quelle che il s.o. ha mappato come "presenti", e che quindi utilizzano la ram di sistema.

Noi parlavamo invece delle varie cache presenti nei processori (L1, L2, L3), che non sono controllate dal s.o. Oltre a queste i processori dotati di PMMU hanno anche una "cache di traslazione degli indirizzi" (chiamata TLB), che effettua il caching degli indirizzi delle pagine usate più di recente, in modo che si eviti ogni volta l'attraversamento dell'albero delle pagine quando si deve tradurre l'indirizzo virtuale nell'indirizzo fisico.
In ogni caso, tutti questi tipi di cache non sono sotto il diretto controllo del s.o.: al più un s.o. esegue il flushing delle cache quando esegue particolari operazioni (esempio: quando ha appena caricato in memoria un eseguibile).
Cmq un qualsiasi sistema operativo moderno in esecuzione okkupa di gran lunga + di 1 o 2 mb e nn si puo evitare di farlo girare :)
Certamente, ma non è necessario tenere in cache tutto il suo codice... ;)

Originariamente inviato da cdimauro
Forse non ricordi il primo Celeron (in assoluto): non aveva cache L2!!! :D :D :D E vabbé, ma quanti Covington pensi che circolino ancora? :asd: Io lo userei come fermacarte!
No, a parte gli scherzi: mi riferivo più che altro ai processori degli ultimi 5 anni, sto dando per ipotesi che quelli ancora più vecchi ancora in funzione siano in quantità non rilevante. ;)

Originariamente inviato da cdimauro
;)

Ti stai confondendo: ti riferisci alla cache delle pagine presenti in memoria, ossia quelle che il s.o. ha mappato come "presenti", e che quindi utilizzano la ram di sistema.

Noi parlavamo invece delle varie cache presenti nei processori (L1, L2, L3), che non sono controllate dal s.o. Oltre a queste i processori dotati di PMMU hanno anche una "cache di traslazione degli indirizzi" (chiamata TLB), che effettua il caching degli indirizzi delle pagine usate più di recente, in modo che si eviti ogni volta l'attraversamento dell'albero delle pagine quando si deve tradurre l'indirizzo virtuale nell'indirizzo fisico.
In ogni caso, tutti questi tipi di cache non sono sotto il diretto controllo del s.o.: al più un s.o. esegue il flushing delle cache quando esegue particolari operazioni (esempio: quando ha appena caricato in memoria un eseguibile).

Certamente, ma non è necessario tenere in cache tutto il suo codice... ;)

Uhmm... grazie della delucidazione sull'argomento la TLB la conoscevo. Quindi se non sbaglio la cache di cui parlate è controllata direttamente dal procio.

Ma anke in questo caso il suo contenuto non dipende dalla frequenza di utilizzo delle pagine in memoria? e quindi indirettamente anke dai processi in esecuzione e dalla loro priorità?

ragazzi mi fa piacere imparare cose nuove riguardo all'elettronica(di mauro credo sia un esperto...) ma in definitiva il mio programma ce la farebbe a girare solo sulla cache o accede alla ram su un procio con....3 MB di cache (ammesso che esista)?
ciao

Originariamente inviato da filosganga
Uhmm... grazie della delucidazione sull'argomento la TLB la conoscevo. Quindi se non sbaglio la cache di cui parlate è controllata direttamente dal procio.
Esattamente.
Ma anke in questo caso il suo contenuto non dipende dalla frequenza di utilizzo delle pagine in memoria? e quindi indirettamente anke dai processi in esecuzione e dalla loro priorità?
Certamente, però è legato in particolare al processo correntemente in esecuzione, e non a tutti i processi: con questi può condividere al più delle zone di memoria in comune. Quindi per lo più in cache si trovano codice e dati del processo corrente.

La politica di allocazione delle pagine di memoria operata dal s.o. può influenzarne il contenuto delle cache, ma limitatamente al fatto che il processore possa trovare una pagina avente o meno i dati che li servono.

x MaxArt: purtroppo processori vecchi se ne trovano ancora parecchi in giro...

Originariamente inviato da peter2
ragazzi mi fa piacere imparare cose nuove riguardo all'elettronica(di mauro credo sia un esperto...)
Il mio ramo è l'informatica. ;)
ma in definitiva il mio programma ce la farebbe a girare solo sulla cache o accede alla ram su un procio con....3 MB di cache (ammesso che esista)?
ciao
Il tuo programma cosa dovrebbe fare?

Originariamente inviato da cdimauro

Il tuo programma cosa dovrebbe fare?
è un modellino numerico di simulazione idraulica: legge una "matriciona" immensa , lo elabora per circa un ora su un p4 3.2 ghz, e sputa fuori un'altra serie di matricione, ma durante l'elaborazione non accede a nessun altro dato su disco (a meno che non gli dico di scrivermi su file dei risultati parziali durante l'elaborazione).
mentre gira l'occupazione di memoria è di 2040KB (da task manager di windows).

Originariamente inviato da peter2
mentre gira l'occupazione di memoria è di 2040KB (da task manager di windows). E pensi stia tutto in una cache da 2 MB? Non ci sperare. :)
Ricorda che la cache la usano anche altri processi in esecuzione.

Originariamente inviato da MaxArt
E pensi stia tutto in una cache da 2 MB? Non ci sperare. :)
Ricorda che la cache la usano anche altri processi in esecuzione.

quello che interessava capire a me è se "in via teorica" ciò fosse possibile...

Originariamente inviato da peter2
è un modellino numerico di simulazione idraulica: legge una "matriciona" immensa , lo elabora per circa un ora su un p4 3.2 ghz, e sputa fuori un'altra serie di matricione, ma durante l'elaborazione non accede a nessun altro dato su disco (a meno che non gli dico di scrivermi su file dei risultati parziali durante l'elaborazione).
mentre gira l'occupazione di memoria è di 2040KB (da task manager di windows).
Se occupa "solo" 2040KB, vuol dire che tanto grandi non sono queste matrici, no? ;)

In linea teorica il tuo programma potrebbe anche stare interamente in una cache L2 da 2MB.

Originariamente inviato da MaxArt
E pensi stia tutto in una cache da 2 MB? Non ci sperare. :)
Ricorda che la cache la usano anche altri processi in esecuzione.
Non vuol dire niente: nel momento in cui c'è un context switch e il suo processo diventa quello attivo, la cache la può riempire interamente coi suoi dati, "buttando" tutti gli altri.
Questo è ciò che normalmente avviene. Poi è anche possibile "bloccare" delle linee di cache, in modo che non vengano alterate, ma non mi sembra che sia una cosa utilizzata.

Originariamente inviato da cdimauro
Se occupa "solo" 2040KB, vuol dire che tanto grandi non sono queste matrici, no? ;)

In linea teorica il tuo programma potrebbe anche stare interamente in una cache L2 da 2MB.

ok..è quello che volevo sentirmi dire!!! :D ;)

sono circa 6 matrici 208*219 di reali (singola precisione) piu varie matrici e vettori di interi...