Newsgroup: it.comp.hardware.cpu
Titolo: Influenza della CPU su una soluzione...

Secondo voi, il tipo di CPU (Athlon XP piuttosto che Pentium Xeon) può
influire sulla soluzione di un modellatore ad elementi finiti?!?
Mi spiego meglio; ho un modello molto grosso da risolvere che, mentre su uno
Xeon girà a meraviglia, sul mio computer dotato di Xp2500+ si pianta sempre
allo stesso punto. Praticamente il software mi dice che si trova di fronte
ad una matrice singolare (con determinante nullo) e quindi non invertibile,
e di conseguenza la soluzione viene arrestata.
Potrebbe dipendere dalle differenze strutturali della CPU?
Grazxie mille a chiunque mi saprà dare un aiuto, ho già provato di tutto,
per venirne a capo...
-- 
Francesco,  Firenze
--------------
On Faz-'99 *Colori&Cazzetti* - XP-2.5@228x11 & M6862
http://community.webshots.com/album/174522647OoiqYl
Togli LE-MANI-DA-LI per rispondermi!!
----------
If everything seems under control, you're not going fast enough - M.Andretti

 
Che esistano delle differenze EFFETTIVE su come cpu diverse (amd/intel, 
ma credo pure processori di stessa marca ma famiglia diversa) è un fatto 
assodato. Di norma si tratta di differenti routine di arrotondamento, ma 
non son da escludere nemmeno banali errori di calcolo. Ricordo ad 
esempio che sul portatile del mio prof una sommatoria di una ventina di 
elementi dava un risultato di uno 0.001 più grande che sul mio. Ho fatto 
il conto a mano e il suo risultato era errato. Se capita con le 
sommatorie non mi stupirei capitasse pure con le matrici...
In definitiva, la cosa è plausibilissima (e pure accertata per quanto mi 
concerne ;) ), bisogna vedere poi se è davvero questo il problema nel 
tuo caso.

 influire sulla soluzione di un modellatore ad elementi finiti?!?
Certo, se si usano le istruzioni "ottimizzate" solitamente non è garantito
il rispetto delle specifiche dell'IEEE, anzi è praticamente escluso.
Di conseguenza architetture diverse possono portare a risultati diversi.
Ciao
Matteo

Mentre /Denise Richards/ abusava di me, *Teo* la interruppe per dirmi:

Grazie ad entrambi per la risposta...Posso chiederti cosa intendi per IEEE?
E sai se è possibilie disabilitare l'uso di istruzioni ottimizzate, e se si
come posso farlo?
Grazie infinite...


 Potrebbe dipendere dalle differenze strutturali della CPU?
Si e' possibile che le differenze tra le cpu causino questo errore. Tempo fa 
e' stato postato un messaggio che riferiva di errori nei calcoli in virgola 
mobile nei P4 (e quindi anche xeon) causati dal'uso delle istruzioni SSE2. 
In effetti queste istruzioni per velocizzare il calcolo diminuiscono la 
precisione e introducono degli arrotondamenti.
Sebbene possa sembrarti strano tra i due quello che fa i calcoli piu' 
corretti e' l'AMD perche' rispetta gli standard IEEE e quindi la sua 
soluzione potrebbe essere corretta. Se puoi vedere la matrice prima che 
venga invertita nell'elaborazone sullo xeon e ne calcoli il determinante a 
mano potresti vedere che si avvicina a zero.
-- 
Ciao
Tomalak 

 mano potresti vedere che si avvicina a zero.
Uno dei miei problemi più grossi è che dal file log non posso vedere quale
nodo mi causa l'errore, quindi non so nemmeno quale sia la matrice....ma
anche se lo sapessi, considerando che il sistema ha circa un milione e mezzo
di gradi di libertà, credo che la mtrice che mi troverei a dover invertire a
mano sarebbe di dimensioni colossali!! ; )
Adesso provo a installare il SO ed il programma su uno dei due Raptor prima
di fare il raid, e provo a farlo girare...IMHO potrebbe dipendere anche
dallo stupido uìndovs, anche se dubito....


 mano sarebbe di dimensioni colossali!! ; )
Fai la prova con una matrice semplice inventata da te e ti calcoli a mano
il determinante come suggeriva Dario e vedi quale dei due "scazza"; poi
posta che è interessante...


E' un programma che hai creato tu? In questo caso in fase di 
compilazione puoi disabilitare/attivare eventuali ottimizzazioni per le 
istruzioni multimediali, se non ricordo male (però non son sicuro).

 posta che è interessante...
Non posso.... E' un modellatore FEM (per chi è curioso, qua c'è una
spiegazione: 
http://snipurl.com/brrt
), io gli do una geometria discretizzata
con nodi collegati da elementi, e lui mi restituisce dei risultati. COmunque
posso dirti che mi ha dato problemi solo con q    uesto modello, mentre con
altri ha sempre funzionato egregiamente.


 istruzioni multimediali, se non ricordo male (però non son sicuro).
Adesso provo a riguardare sulla guida in linea, ma non ho trovato niente....
Comunque, ho fatto una prova con un HD nuovo, ho installato solo il SO e il
software in questione. NIente, sempre lo stesso errore....
Non so più dove picchiare il capo...


 
Non credo proprio che sia un problema software... mi sa che è davvero un 
problema di computazione relativo alla cpu. Il punto è che a priori non 
puoi stabilire quale delle due soluzioni sia corretta... e se fosse 
esatta quella AMD?
Certo, con un milione e mezzo di gradi di libertà viene difficile fare 
le prove a manina...
Non riesci a ricreare lo stesso errore con un sistema più piccolo, 
magari computabile anche a mano?

 magari computabile anche a mano?
No, questo bastardo di un software non mi dice nemmeno qual'è l'elemento (su
650mila) che non gli piace!
L'unica prova cher mi rimarrebbe da fare sarebbe di buttar su una versione
di Linux, farmi installare il software per linux (che in azienda hanno, ma
che non abbiamo noi in facoltà) e vedere che succede a quel modo....


 che non abbiamo noi in facoltà) e vedere che succede a quel modo....
Loro che macchine hanno?
Puoi vedere se su linux converge sia su amd che intel prima di portarti 
il soft a casa. In questo caso diventa possibile che sia la compilazione 
diversa fra win e linux.
In alternativa se hai voglia e sai smanettare puoi usare uno dei soft di 
emulazione di windows da linux (tipo wine) e vedere che succede facendo 
girare il tutto così.... sarebbe un prova in più assolutamente non 
necessaria, ma come cosa è parecchio interessante ^^ Se emulando il soft 
da linux ancora non converge allora deve per forza essere un problema di 
cpu amd ;)

 girare il tutto così....
Mai usato linux, nonostante l'odio profondo per uìndovs....ma bisognerà che
cominci prima o poi....


 cominci prima o poi....
Ti consiglio prima che poi visto anche che in azienda da dove ti danno i
dati lo usano...;-¶   
Anche io sono niubbo in linux (ma tempo permettendo mi sto dando da fare)
e ti assicuro che è meno complicato di quel che sembra .. sopratutto se
magari un po di dos già lo masticavi

 cominci prima o poi....
Ti consiglio prima che poi visto anche che in azienda da dove ti danno i
dati lo usano...;-¶   
Anche io sono niubbo in linux (ma tempo permettendo mi sto dando da fare)
ma ti assicuro che è meno complicato di quel che sembra ..


IEEE ( Institute of Electrical and Electronics Engineers)
Chiamato anche "I triple E" č l' ente statunitense con sede a New York che
riunisce scienziati, ingegneri e studenti. Nato nel 1963 dalla fusione
dell'IRE (Institute of Radio Engineers) e dell'AIEE (American Institute of
Electrical Engineers), l'IEEE concentra la propria attivitą nella
definizione di standard per il mondo dell'elettronica, in generale, e per i
sistemi da calcolo, in particolare, compreso il formato in virgola mobile.

 cpu amd ;)
Mi intrometto qui , guarda che sotto linux i bug di windows non svaniscono
anzi.........con wine ci ho smanettato un po', sono riuscito anche ad
installare IE6 su slackware,  gira anche decentemente, ma i bug di IE sono
rimasti al 120% ..........
-- 
www.freewebz.com/iosononiubbo/iosononiubbo.htm#quotare
http://distrowatch.com
 (linux e dintorni)
www.slacky.it/tutorial/slackware_for_dummies/slackware_for_dummies.txt
46=pilota che vince ! 

 e se si come posso farlo?
Difficile.....  se il software (come ho letto sopra) e' stato compilato con
ottimizzazioni particolari per gli xeon (magari sotto linux) .........
io di programmazione non capisco una mazza, pero' qualcosina la compilo a
manina sotto linux ed hai la possibilita di personalizzare parecchio per la
tua macchina.........
un'esempio :
./configure --with-cross=arm-linux- --with-kernel=/home/ipaq/kernel/linux'
non mi chiedere che roba e' !



Occhio che se il software utilizzato seleziona automaticamente le librerie
in base alle estensioni presenti, potrebbe anche essere che con l'XP 2500+
vengono utilizzate librerie ottimizzate SSE (float a 32bit) mentre per i P4
vengono utilizzate quelle ottimizzate SSE2 (float a 64bit).
Se si hanno dubbi la cosa migliore e' vedere se si puo forzare la
cpu ad usare le "vecchie" istruzioni FPU x87 (quelle che permettono
di avere la "rappresentazione" piu dettagliata dei float).
N.B.: la precisione del calcolo dipende anche da come si eseguono
le operazioni e gli arrotondamenti, e' quella la precisione "vera", mentre
la precisione con cui i numeri vengono *rappresentati* indica solo
il massimo a cui si puo arrivare con la precisione del calcolo.
Per molta roba i float a 32bit sarebbero in teoria sufficienti, ma
purtroppo a volte sembra che troppa gente creda che i float siano
dei numeri reali (totalmente errato, sono una rappresentazione
con errore assoluto a crescita *esponenziale* man mano che ci si
allontana dallo zero), in tal caso un formato con significanti ed
esponenti con range piu ampio riduce parzialmente i problemi.
Cercando con google le pubblicazioni e gli appunti per le lezioni
del Prof. W. Kahan ci si puo fare un idea di cosa ci sia sotto
e di quanto gli standard IEEE 754 e successivi siano stati messi
a punto con cura in modo da avere dei float "affidabili" e di come
invece chi si occupa di linguaggi di programmazione e di compilatori
abbia sottovalutato il lavoro svolto in proposito.
L. Micheletto

 
Ma infatti il bug non è di windows ma della cpu (eventualmente). E' 
possibile che la diversa compilazione fra win e linux porti a diversi 
risultati... facendo girare del software windows su macchina linux si 
dovrebbe ruscire a capire se è la compilazione o proprio la cpu :)

 soluzione potrebbe essere corretta.
Questo è vero, se però non prendi in considerazione le istruzioni SIMD. 
Non credo che ne' intel ne' amd abbiano introdotto i quattro algoritmi 
di arrotondamento sulle SIMD, ma usino solo il troncamento. Con le 
3dnow! era così, poi non so...

 paura che sia il mio Bartolino che è in fallo... : ((
Uhm! Ad occhio e croce sembra proprio un problema dovuto a librerie
o funzioni ottimizzate selezionate a runtime.
Agli Athlon XP supportano le SSE (ottimizzate per operazioni SIMD
su float a 32bit) mentre i P4 e gli Xeon derivati da essi supportano
le SSE2 (che supportano anche operazioni SIMD su float a 64bit).
Controlla se il programma che usi ha qualche opzioni
(parametri sulla riga di comando, file di configurazione o altro)
per forzare l' uso della FPU x87 (che garantisce l'uso di un formato
float extended precision ad 80bit) e vedi se cambia qualcosa.
L. Micheletto

 3dnow! era così, poi non so...
Il registro MXCSR permette di settare la modalita di arrotondamento
delle istruzioni SSE/SSE2 nei 4 modi dello standard IEEE-754, ma se
si usano solo le istruzione SSE (float a 32bit) Intel stessa consigliava
di usare il troncamento perche permette (almeno nei PIII) di ottenere
prestazioni piu elevate.
L. Micheletto

Lorenzo Micheletto ha scritto:

Ah! Ok! Ho lavorato molto poco con le SSE, mentre conosco meglio le 
3dNow!. E comunque a titolo personale trovo molto più pulite e pratiche 
(ed anche performanti) le 3dNow! a 64 bit piuttosto che le SSE a 128 bit.