Xeon 3,6 Ghz vs Opteron 250

[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?

[midian]

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)

[joe4th]

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

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

ciaoooooooooo

[MaxArt]

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!

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!
Diciamo che la RAM in quel caso sarebbe utile solo come spazio di precaricamento di dati/codice da disco, ma è pura fantainformatica!

[xeal]

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.

[Orsobubu]

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

[Zer|0|]

qualcuno potrebbe rimettere apposto il tasto stampa? GRAZIE..

[filosganga]

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

ciaoooooooooo

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!

[peter2]

Originariamente inviato da filosganga
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?

[MaxArt]

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

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

[peter2]

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?

[cdimauro]

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

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

[peter2]

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

non capisco

[MaxArt]

Originariamente inviato da peter2
non capisco

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.

[peter2]

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

[MaxArt]

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
Però, è quasi ancora fantainformatica, perché quali sono i programmi che stanno tutti nella CACHE? Pressoché nessuno!

[peter2]

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

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

[leoneazzurro]

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

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