View previous topic :: View next topic |
Author |
Message |
Cazzantonio Bodhisattva


Joined: 20 Mar 2004 Posts: 4514 Location: Somewere around the world
|
Posted: Tue Jul 17, 2007 3:32 pm Post subject: [GCC]Ottimizzazioni cambiano la precisione numerica[RISOLTO] |
|
|
Sto sperimentando uno strano comportamento del compilatore gcc.
Nello specifico sto parlando del compilatore fortran incluso nelle seguenti versioni di gcc:
3.4.6-r2 (g77)
4.1.2 (gfortran)
Ho un codice scritto in fortran77 ma perfettamente compatibile col 95, pertanto compilabile senza problemi o warning di sorta col g77 o con il gfortran. Tendo a preferire il g77 perché genera codice molto più veloce...
Il problema nasce quando provo ad usare le opzioni di ottimizzazione ed è identico sia per il g77 che per il gfortran:
Se provo a compilarlo senza opzioni di ottimizzazione oppure provo a passare a mano tutte le opzioni di ottimizzazione implicate dai vari livelli (-O1, -O2 etc...) allora ottengo certi risultati (il codice fa dei conti all'atto pratico) e ci mette un certo tempo. Metterci le ottimizzazioni non cambia il tempo di run anzi, se possibile lo peggiora leggermente.
Se provo a passare direttamente i livelli di ottimizzazione (-O1, -O2 etc...) allora ottengo si codice MOLTO più veloce (anche di un fattore 5) ma la precisione numerica dei risultati cambia. Per fare un esempio un numero che prima era 0.89725265 diventa 0.90752749... quasi lo stesso ma MOOOLTO diverso se cerchi una precisione elevata dei conti.
Che accidenti succede nell'ottimizzazione? Ho provato, come detto prima, a passare a mano tutte le opzioni che dovrebbero essere implicate da -Ox e ho scoperto che l'unica che cambia la precisione del codice è "-frerun-cse-after-loop". In ogni caso se passo anche tutte le opzioni a mano il codice non viene ottimizzato (stessi tempi di run, più o meno) mentre c'è un boost prestazionale solo dichiarando esplicitamente -Ox.
COME MAI??
Qualcuno ha una risposta per questo bizzarro comportamento? _________________ Any mans death diminishes me, because I am involved in Mankinde; and therefore never send to know for whom the bell tolls; It tolls for thee.
-John Donne
Last edited by Cazzantonio on Wed Jul 18, 2007 11:21 am; edited 1 time in total |
|
Back to top |
|
 |
gutter Bodhisattva


Joined: 13 Mar 2004 Posts: 7162 Location: Aarau, Aargau, Switzerland
|
Posted: Wed Jul 18, 2007 8:56 am Post subject: |
|
|
Non mi sembra una cosa bella.
Ma il problema si presenta sia con il 3.X che con il 4.X
Quello che sapevo è che era sconsigliato usare fast-math dal momento che si potevano presentare dei problemi simili ai tuoi. Per il resto non saprei. _________________ Registered as User #281564 and Machines #163761 |
|
Back to top |
|
 |
Cazzantonio Bodhisattva


Joined: 20 Mar 2004 Posts: 4514 Location: Somewere around the world
|
Posted: Wed Jul 18, 2007 9:35 am Post subject: |
|
|
Si presenta con tutte le versioni del gcc che ho provato.
-ffast-math infatti non l'avevo nemmeno considerato... il fatto è che anche un misero -O1 mi da risultati diversi
Mica per altro ma quando lanci dei run che durano settimane una velocizzazione di un fattore 5 mica la butti via a priori  _________________ Any mans death diminishes me, because I am involved in Mankinde; and therefore never send to know for whom the bell tolls; It tolls for thee.
-John Donne |
|
Back to top |
|
 |
Cazzantonio Bodhisattva


Joined: 20 Mar 2004 Posts: 4514 Location: Somewere around the world
|
Posted: Wed Jul 18, 2007 11:20 am Post subject: |
|
|
Ho scoperto che la flag "-ffloat-store" risolve magicamente il problema!
Cito testualmente dal man di gcc:
man gcc wrote: | -ffloat-store
Might help a Fortran program that depends on exact IEEE conformance
on some machines, but might slow down a program that doesn't.
This option is effective when the floating-point unit is set to
work in IEEE 854 `extended precision'---as it typically is on x86
and m68k GNU systems---rather than IEEE 754 double precision.
-ffloat-store tries to remove the extra precision by spilling data
from floating-point registers into memory and this typically
involves a big performance hit. However, it doesn't affect inter-
mediate results, so that it is only partially effective. `Excess
precision' is avoided in code like:
a = b + c
d = a * e
but not in code like:
d = (b + c) * e
For another, potentially better, way of controlling the precision,
see Floating-point precision. |
Con questa flag abilitata (e la flag di ottimizzazione -O2) ottengo risultati identici al programma non ottimizzato, solo che adesso ho davvero un boost prestazionale notevole! Un run che finiva in una settimana adresso dovrebbe girare in due giorni scarsi. Inoltre run da oltre un mese ora forse riesco a farli in una settimana!!  _________________ Any mans death diminishes me, because I am involved in Mankinde; and therefore never send to know for whom the bell tolls; It tolls for thee.
-John Donne |
|
Back to top |
|
 |
gutter Bodhisattva


Joined: 13 Mar 2004 Posts: 7162 Location: Aarau, Aargau, Switzerland
|
Posted: Wed Jul 18, 2007 3:36 pm Post subject: |
|
|
Complimenti  _________________ Registered as User #281564 and Machines #163761 |
|
Back to top |
|
 |
Cazzantonio Bodhisattva


Joined: 20 Mar 2004 Posts: 4514 Location: Somewere around the world
|
Posted: Wed Jul 18, 2007 10:10 pm Post subject: |
|
|
gutter wrote: | Complimenti  |
Ah io mica ho fatto niente di particolare...
Sono andato assolutamente alla cieca provando un po' tutte le opzioni che trovavo  _________________ Any mans death diminishes me, because I am involved in Mankinde; and therefore never send to know for whom the bell tolls; It tolls for thee.
-John Donne |
|
Back to top |
|
 |
gutter Bodhisattva


Joined: 13 Mar 2004 Posts: 7162 Location: Aarau, Aargau, Switzerland
|
Posted: Thu Jul 19, 2007 7:15 am Post subject: |
|
|
Cazzantonio wrote: |
Sono andato assolutamente alla cieca provando un po' tutte le opzioni che trovavo  |
Anche questo è un approccio scientifico al problema  _________________ Registered as User #281564 and Machines #163761 |
|
Back to top |
|
 |
|