[Fortran 77] Effets de l'optimisation à la compilation

Bonjour,
j'ai une question concernant l'option d'optimisation à la compilation.
J'ai un code volumes finis écrit en fortran 77.
J'utilise Visual Fortran pour la compilation et le développement.
Mon problème est que lorsque je compile en mode "Release", c'est a dire avec l'option "Full Optimisation", j'ai des résultats un peu différents que lorsque je compile en mode "Debug" c'est à dire avec aucune optimisation.

J'ai testé sur le compilateur g77 (utilisé avec Force2.0) sur le mode par défaut et en utilisant -O3.

Ma question est : Un code correctement écrit peut-il donner des résultats différents selon le niveau d'optimisation choisi à la compilation ?

Citation:

---

Envoyé par gregory2526

Un code correctement écrit peut-il donner des résultats différents selon le niveau d'optimisation choisi à la compilation ?

---

Théoriquement, la réponse est non.

La norme Fortran est très explicite sur ce que peut faire et ne pas faire un compilateur. Par exemple, si A = (f(x) == k) .and. (g(x) == y), le code optimisé n'a pas le droit "d'arrêter" après le premier terme si c'est faux. Aussi, le compilateur n'a pas le droit de réorganiser une expression d'une façon qui puisse changer le résultat (incluant les erreurs d'arrondi/troncation).

Tu ne dis pas dans quelle mesure il y a différence.

Parmi les pistes possibles que je vois, il y a les erreurs de programmation subtiles genre :

call Routine(4)
subroutine Routine(k)
...
k = ...

Dans un tel exemple, il est possible qu'en mode développement, le 4 soit réinitialisé à chaque appel alors qu'en mode release, il ne soit initialisé qu'une fois.

Ou encore :

z = f(x) + y

où f(x) modifie y via un common.

L'autre possibilité c'est qu'une fois optimisé, le code maintienne des résultats intermédiaires dans les registres. Sur un processeur x86, les registres ont 80 bits alors que les doubles ont 64 bits et les reals simples ont 32 bits. L'expression a / b + c / d pourrait donc donner des résultats différents selon que les résultats intermédiaires sont ramenés à la précision de a, b, c, et d ou maintenu à la précision des registres. Je crois que le compilateur n'a pas le droit de maintenir la précision des registres, mais je ne suis plus certain. Je crois avoir lu quelque chose sur le sujet dans Usenet. Si tu baragouine en anglais, fais une recherche du côté de http://groups.google.com/groups?oi=d...p.lang.fortran

Merci, je vais chercher dans le lien que tu m'a donné.

En tout cas, ça ne fait que confirmer ce que je pensais déjà sur le code sur lequel je travaille. :cry:
Il est vieux, et très mal programmé (le nombre de bugs que j'y ai trouvé est impressionnant). Mais bref...

C'est un code qui résoud une équation de diffusion. J'ai des écarts de qq % en relatif, dans les résultats entre la version optimisée et la non optimisée, lorsque la quantité est faible. Ce n'est donc pas très important. Mais ce n'ai pas satisfaisant, et qui sait quelle erreur on peut faire sur un modèle complexe (au niveau geométrie par exemple).

Merci encore.

Salut.

Sylvain Bergeron a raison: le problème ne réside pas dans le Fortran, mais dans une particularité des processeur Intel (80 et 64 bits). Tu ne rencontrerais pas ce problème sur une machine appliquant strictement la norme ANSI. Je me suis amusé une fois à écrire un programme qui, au départ, se plantait misérablement (racine d'un nombre négatif), mais qui marchait impeccablement si on ajoutait un "write" quelque-part ou si on appliquait l'option "debug". C'est un peu le problème que tu as rencontré. Malheureusement, je n'ai pas conservé ce programme quand j'ai changé de machine.

Jean-Marc Blanc

En fait il fonctionne bien (ou pas bien) dans l'un ou l'autre cas. Je n'ai pas d'erreur qui ne se produise que dans un certain degré d'optimisation, et pas a un autre. C'est simplement le résultats des calculs qui est légèrement différent. Je n'ai testé l'effet de l'optimisation que dans un cas simple.


Donc finalement, je ne peux pas faire grand chose...
je serai toujours dépendant de la machine.
:cry:
De toute façon, je n'ai plus trop de temps pour me plonger dans ce problème avant la fin de mon stage...

Si tu utilises Visual Studio, surtout la version 6, (au CEMEF? ;) ) vérifie si tu utilises par défaut la librairie IMSL, contenant les BLAS, LAPACK optimisés pour ton processeur.

Si c'est le cas ( et en général dans le cadre d'utilisation de libraries optimisées constructeur genre MKL ou optimisée "manuelle" comme ATLAS), et ce n'est pas étonnant vu le type d'optimisation engagée dans ces cas (utilisation mémoire, cache niveau 1 et 2 etc etc)...

Fortran90, je ne suis plus au cemef pour mon stage. Je n'utilise donc plus Visual Fortran.

J'utilise G95, aved Force2.O sous windows et les conpilateurs gnu lorsque je travaille sous linux (chez moi ou sur le serveur de calcul). Et le problème se produit quel que soit le compilateur.

De plus je n'utilise pas de librairie, les méthode numériques utilisées étant déjà implémentées dans le programme (quoique je me demande si l'utilisation de ces librairies ne rendraient pas la résolution plus rapide).

PS: CEMEF également ?

tu utilise quelle version de G95? est-ce la version 64bits?

Parce que moi j'ai des soucis entre la version 32 et 64bits... j'ai un double boot sur mon ordi (windaube et ubuntu) et donc bin sous windaube comme il ne gère absolument pas le 64bit, j'utilise g95 32bits version cygwin mais sous la buntu j'utilise le g95 64bits (bon en plus je parallèlise vu que sous liux c'est possible) et je dois avoué que l'on constate quand même une différence (de vitesse, ça on s'en douterai) mais aussi de précision du calcul.
Parfois sur certain calcul on peut presque parler de résultats différents....

j'utilise la version 32 bits (je n'ai pas de machine 64), sous windows. J'avoue ne pas connaitre la version (celle fournie avec Force2.0)

Je peut aussi dire que j'ai des résultats différents (rarement tout de même), lorsque le calcul diverge sous linux, et converge sous win, avec le même compilo (même version ??). Mais ça ne concerne pas l'optimisation.

En tout cas, en ce qui concerne 32 et 64b, je pense que c'est tout a fait normal de trouver quelque chose de différent. Mais je me pose un question... Un real*4, par exemple, aurat-il la même precision si c'est un 32 ou 64 ?

pour la version, je l'a donne dès mon retour au boulot demain matin.

bon il me semble qu'avec Force 2.0 c'est G77 qui est fourni et non G95 de plus tu programme en 77 ou en 90/95/2003? car force2.0 est gentil mais comme il ne gère pas les formats récents il craint vraiment (mes élèves utilisait ça! après changement, ils ont fait des progrès monstre en programmation....)

cela dit quelle sont exactement les options de compilations que tu lance? as-tu accès à la ligne de commande qui lance le compilateur, l'éditeur de liens?

(par exemple sous G95 l'option "-Ox" où x=1..5 est la commande de l'optimisation (nieau de 1 à 5) mais cela gère surtout la taille de l'executable et ne change pa le résultat y a l'option "-fshort-circuit" qui permet d'arreter l'évaluation d'une condition si la première est déjà non vérifiée. "fintrinsic-extensions" "-ftr15581"

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51

#======================================================================== # Makefile for Fox1D (c) Damien Lachouette # current version: 0.1.1 - 12/08/2007 # # ------------------------------- # # It is a simple computation code witch applied in internal erosion # It describe the erosion of a pipe in a One-dinesional way # Use of finites diferences, newton-raphson and runge_kutta methods # # ------------------------------- # # History: # 12/08/2007 ---> version 0.1.1 # - New errors management # 09/08/2007 ---> version 0.1.0 # - New strain rate computation # 07/08/2007 ---> version 0.0.2 # - translation in unicode UTF-8 of the source code # 16/05/2007 ---> version 0.0.1 # - Module-based programation of Renard95 #========================================================================   FC=i686-pc-cygwin-g95 FL=i686-pc-cygwin-g95 Cflag=-info -L./ -I./ -fshort-circuit -fzero -O5 -fno-underscoring -Wunused-types -fintrinsic-extensions -ftr15581 Lflag=-info -Wall -Wextra -L./ -I./ -fbound-check -O5 COMPILED=Fox1D.o MainSection.o renard.o addon.o   Fox1D.exe: $(COMPILED) $(FL) -o Fox1D.exe $(COMPILED) $(Lflag)   Fox1D.o: Fox1D.f95 MainSection.o $(FC) -c Fox1d.f95 $(Cflag)   MainSection.o: MainSection.f95 renard.o $(FC) -c MainSection.f95 $(Cflag)   renard.o: renard.f95 variables.FI addon.o $(FC) -c renard.f95 $(Cflag)   addon.o: addon.f95 $(FC) -c addon.f95 $(Cflag)   clean: rm *.o *.mod *~   mrproper: clean rm Renard.exe   all: Fox1D.exe

---

voici le makefile de mon code en version optimisé au max... (sauf si g oublié un truc)

Toutes mes excuses :oops:
il s'agit bien de g77 (et je bosse sur un vieux code en g77).

Si j'avait eu le choix, je n'aurais pas programmé sous windows. En tout cas Force2.0 m'a été imposé. J'ai quand même reussi à les convaincre d'acheter visual Fortran (au moins pour la facilité de debuggage, et parceque je trouve qu'il y a quelques outils qui facilitent la programmation.

Chez moi, je bosses sous linux, avec g95 et je programme en 90.

Effectivement, j'ai accès aux options de compilation (pas en ligne de commande mais c'est tout comme), et j'utilise les options -g -O3. ça me permet d'avoir, lorsque le programme plante, la subroutine dans laquelle il s'est arreté directement dans la fenetre dos, et le -O3 accélère un peu le calcul.

Par contre, il y a pas mal d'option d'optimisation que je ne connait pas. Il faudra que je regarde ça sérieusement.

tu peux aussi chercher du coté du profiling (par contre sous windows je sais pas du tout comment faire) mais y peut-être une option du genre dans force 2.0

en faisant le profile du code en version optimisé et non optimisé tu dois pouvoir trouver quelles sont les différences et donc pourquoi y a des soucis de calcul..... (cela dit, si ton code est un peu long, ce sera un travail de super fourmi)

cela dit NORMALEMENT (mais on peut difficilement parler de normalité sous windows) si l'optimisation chage le résultat c'est une erreur de programmation (et vraisemblablement le code optimisé est plus proche du vrai car il "corige" certaines erreur de programmation) essaye de reunir dans les deux cas les même condition de windows (même services activer même programme tournant etc....)

je n'avais pas pensé au profiling pour comparer mes versions avec et sans optimisation.
Je ne sais pas non plus comment faire sous windows (je n'ai pas vu cet outil dans force 2.0, et je n'arrive pas à le faire fonctionner pour mon programme avec Visual Fortran).
Je n'ai pas vraiment de possibilité au niveau de windows, car il faudrai que j'ai des droits que je n'ai pas au niveau du système. Je ne peux que supposer que les différents services restent constants au cours du temps sur ma machine.

Je suppose aussi qu'il doit y avoir des problèmes au niveau de la programmation (même si ça ne résoudrait pas la totalité de ce problème, je pense). Cela dit, je me vois mal me prendre la tête avec 9000 lignes de vieux fortran, d'autant plus que j'ai bientôt terminé mon stage.

En fait, cette discussion me permet surtout de m'améliorer sur le sujet, et de savoir comment réagir si cela se produit dans une autre situation, dans le futur. Mais je vais qd même regarder dans le détail les options de compilation que tu utilise.

Les options de compilation et d'édition de lien sont donné dans le guide d'utilisation de g95, rien de plus, c'est assez important de lire ce genre de doc (quelque soit le language, quelque soit le compilo) quand elle est disponible parce que certains problèmes que tu peux rencontrer face à des code un peu mal programmer sont résolus par le compilo...

de plus moi j'aime bcp les option "-Wall" et "-Wextra" ,comprendre "Warning all" et "Warning extra" car si le compilo ne renvoie pas d'erreur, c'est que tu as bien programmé (ou presque) après il ne reste presque que les problèmes d'algorithmique l'option "-nounderscoring" permet de ne pas rajouter d'under score dans les nom de fonctions genre MAIN_(...) ce qui permet de mieux callé du C dans du Fortran et inversement et de rendre le code plus compatible avec d'autre compilo....

de la même manière, pour toi cela semble compliqué mais c'est bien aussi d'essayer plusieurs compilateurs sur son code avec les otpimisations en plus car ils ne fonctionnent pas pareil et chacun a ses particularité... un code qui se compile nikel avec plusieur compilo est bien plus sûr ...

je suis d'accord avec toi sur l'utilisation de plusieurs compilateurs.

Et c'est vrai que j'aurais du m'intéresser un peu plus aux options de compilation.
Les -Wall, je l'ai utilisé (ce qui m'a permis de supprimer plusieurs pages de warnings...)

De toute façon, il faudra bien que je m'y plonge un jour. Mais le peu de fois ou j'ai regardé, il y a certaines options que je ne comprenait pas. En fait je n'ai jamais eu de réelle formations au niveau de la compilation. C'était simplement de la programmation, souvent avec des IDE ou il suffit de cliquer sur un bouton pour compiler. Tout est complètement transparent... Ce n'est pas évident par la suite de comprendre le fonctionnement réel d'un compilateur...

par exemple, l'option -nounderscoring, je l'avait vu rapidement dans la liste des options, mais je ne voyais pas l'interêt. Maintenant, je comprends... merci.

il faudra que je cherche un cours simple pour connaitre un peu la signification de différents terme de compilations qui ne sont pas clair pour moi...