Déterminisme et virgule flottante

[Tramb]

Salut les hardeurs,

est-ce que quelqu'un sait des choses sur le déterminisme bit-à-bit de la FPU, du SSE ss, et du SSE2 sd?

J'ai l'impression que les normes sont en précision relative garantie et que rien ne garantit de ne pas avoir des différences pour un même code sur deux architectures.

[Neo_13]

ieee754 est là pour ça

si le cpu respecte l'ieee754, le résultat doit etre prévisible. par contre la FPU x87 fait 80bits, là où le SSE fait 64 bits

par contre les GPU (GPGPU notamment) eux, ne sont pas ieee754 compliant.

[Tramb]

ieee754 est là pour ça

si le cpu respecte l'ieee754, le résultat doit etre prévisible. par contre la FPU x87 fait 80bits, là où le SSE fait 64 bits

par contre les GPU (GPGPU notamment) eux, ne sont pas ieee754 compliant.

Justement IEEE754 ne garantit que la précision minimale, pas le déterminisme, non?
En gros si je fais des tonnes de calculs qui restent en registre, au moment où le CPU commite le résultat en mémoire, le résultat dépend de la précision interne.
Exemple : tu prends le plus petit double représentable, tu le divises par deux, il n'est pas mis à 0 si la précision est à 80 bits, et il est mis à 0 si la précision est à 64 bits.
Tu peux le sommer suffisament longtemps, ça donnera quelque chose dans un cas, et 0 dans un autre. Donc la FPU x87 n'est pas déterministe d'une inner precision à une autre.
Sauf *peut-être* (je n'en suis même pas sûr) à repasser par la RAM après chaque opération.

J'aimerais du coup avoir des infos du genre sur les SSE1&2

[fefe]

Je vais essayer de repondre:
Les 3 sont deterministes, sauf les quelques instructions d'approximations en SSE (inverse approximee inverse racine carree approximee). J'entends par deterministe que, quel que soit le processeur qui execute l'instruction (si bien entendu les modes d'arrondis etc sont gardes constants et l'etat initial est le meme), le resultat est garanti d'etre le meme. Les inverses approximes sont garantis deterministes jusqu'au 11 eme bit, apres cela a peu de chances de varier entre produits d'un meme constructeur, mais historiquement il y a eu des variations Intel/AMD.

Ensuite il y a la question de savoir si ils sont equivalents, en gros peut on employer du SSE ss et avoir le meme resultat qu'en x87 en mode single. La c'est beaucoup plus complique, mais la reponse courte est non ce n'est pas equivalent, mais dans la plupart des cas c'est suffisant.

Je vais essayer de te retrouver les papiers sur la definition de la norme, mais effectivement la norme en elle meme n'est pas completement deterministe, en revanche les implementations que sont SSE ou x87 sont deterministes individuellement.

[Tramb]

Je vais essayer de repondre:
Les 3 sont deterministes, sauf les quelques instructions d'approximations en SSE (inverse approximee inverse racine carree approximee). J'entends par deterministe que, quel que soit le processeur qui execute l'instruction (si bien entendu les modes d'arrondis etc sont gardes constants et l'etat initial est le meme), le resultat est garanti d'etre le meme. Les inverses approximes sont garantis deterministes jusqu'au 11 eme bit, apres cela a peu de chances de varier entre produits d'un meme constructeur, mais historiquement il y a eu des variations Intel/AMD.

Ensuite il y a la question de savoir si ils sont equivalents, en gros peut on employer du SSE ss et avoir le meme resultat qu'en x87 en mode single. La c'est beaucoup plus complique, mais la reponse courte est non ce n'est pas equivalent, mais dans la plupart des cas c'est suffisant.

Je vais essayer de te retrouver les papiers sur la definition de la norme, mais effectivement la norme en elle meme n'est pas completement deterministe, en revanche les implementations que sont SSE ou x87 sont deterministes individuellement.

Merci bien pour tes précisions, as-tu une référence comme quoi les SSE ss et sd sont déterministe? Sont-ils des normes de fait ou des vraies normes? J'arrive pas à trouver de doc là dessus et même Intel et AMD n'ont pas l'air de trop s'intéresser à la question...

[Neo_13]

Merci bien pour tes précisions, as-tu une référence comme quoi les SSE ss et sd sont déterministe? Sont-ils des normes de fait ou des vraies normes? J'arrive pas à trouver de doc là dessus et même Intel et AMD n'ont pas l'air de trop s'intéresser à la question...

ne pas confondre "ne pas s'y intéresser" et "ne pas en parler"

[Tramb]

ne pas confondre "ne pas s'y intéresser" et "ne pas en parler"

Ok
Disons qu'ils ne s'engagent pas trop dessus donc ils ne doivent pas être bien sûrs eux même.

[fefe]

Un exemple court:
si en SSE single tu fais
S = 1+1/2+1/3+1/4+...1/n

et tu compares avec la meme chose en x87
le resultat va etre different alors que si tu compares individuellement le resultat de chaque operation intermediaire les resultats seront egaux bits a bits.

La raison ici est que en x87 la conversion en 32 bits n'intervient pas apres chaque operation qui est faite en 80 bits en interne, mais juste au moment du store du resultat.

A supposer qu'un store soit fait apres chaque operation (force par une affectation en C) le x87 donnerait le meme resultat que le SSE. MAis vu que les compilos preferent ne pas forcer les store apres chaque operation pour des raisons evidentes de performance (et cela ne fait qu'augmenter la precision) on aboutit a des differences, bien que les 2 respectent la norme.

Ok
Disons qu'ils ne s'engagent pas trop dessus donc ils ne doivent pas être bien sûrs eux même.

Merci de la blague ca m'a fait rire .

SSE est IEEE754 compliant (et garanti pour), mais par defaut utilise un mode ou les denormaux sont evalues comme zero (DAZ, definit par la norme) qui est different du mode par defaut employe dans x87.

2 lectures pas inutiles:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
http://www.cs.berkeley.edu/~wkahan/i...us/IEEE754.PDF

[Tramb]

SSE est IEEE754 compliant (et garanti pour), mais par defaut utilise un mode ou les denormaux sont evalues comme zero (DAZ, definit par la norme) qui est different du mode par defaut employe dans x87.

2 lectures pas inutiles:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
http://www.cs.berkeley.edu/~wkahan/i...us/IEEE754.PDF

En fait ma problématique c'est pas du tout la similarité entre SSE et x87. C'était plus un exemple qui me fait me poser la question sur les différentes implémentations du SSE[12].
J'aimerais juste trouver trouver des preuves que si j'exécute le même code sur un Intel, un AMD ou un CPU du futur, personne ne rajoute de l'inner precision dans son implémentation SSE et ne nique le déterminisme qui permet quand même de bien compresser des séquences de jeu avec le couple (inputs, code de simu).


(Par contre le SSE n'est pas par défaut ni en DAZ ni en FTZ si je ne m'abuse, c'est juste ICC par exemple qui se permet d'initialiser les programmes comme ça, sous MSVC tu es obligé de le setter à la paluche).

Je me plonge dans les docs, merci chef!

Edit: Je me sens un peu insulté quand même que tu m'ai posté le grand classique "What Every Computer Scientist Should Know About Floating-Point Arithmetic" ;-)

[Gabriel]

Si ta question est de savoir si les calculs sont déterministes sur une implémentation donnée, la réponse est bien sur oui. Sinon, ce serait un cauchemard pour tester les programmes, et pour tester les processeurs.

Si ta question est de savoir si les specs te garantissent un comportement identique entre processeurs de constructeurs différents, la réponse est en général oui, mais il y a quelques exceptions. Il y a effectivement certaines instructions SSEx qui sont spécifiées comme garantissant un résultat exact à N bits. Dans ce cas, le résultat sera reproductible sur un même processeur, mais rien ne garanti un résultat identique entre processeurs différents. Mais dans ce cas, c'est explicitement mentionné dans la doc.

edit: ceci dit, il serait interessant de faire la comparaison en pratique, avec les quelques instructions fournissant des réciproques, sur du K8/K10/Netburst/Core/Core2.

[fefe]

Edit: Je me sens un peu insulté quand même que tu m'ai posté le grand classique "What Every Computer Scientist Should Know About Floating-Point Arithmetic" ;-)

Etant donne que ce n'est pas une discussion privee je me suis permis de le linker pour ceux qui ne connaitraient pas, et je suis certain que c'est la majorite des visiteurs du forum.

(Par contre le SSE n'est pas par défaut ni en DAZ ni en FTZ si je ne m'abuse, c'est juste ICC par exemple qui se permet d'initialiser les programmes comme ça, sous MSVC tu es obligé de le setter à la paluche).

Je ne me souviens plus si c'est par defaut ou recommande pour l'utilisation par defaut (pas seulement ICC, gcc et compagnie aussi). Il faut juste que je retrouve la page du blue book en question. (section 5-1 du optimization reference manual dans le blue book).

Sinon pour les questions de precisions, SSE est specifie comme un jeu d'instruction 2,1 avec operandes sur registres de longueur fixe et garantie (et de la meme taille que la norme le specifie).

Chaque operation passe par une phase de rounding conforme a la norme et ecrit sur un bus de resultat (qui amene aux registres ou est bypasse vers l'input d'une operation dependante) qui fait exactement la meme largeur que le registre. De ce fait il est donc impossible d'avoir le meme effet qu'avec x87 de precision "cachee", vu que ce que tu vois est ce que tu as. SSE est IEEE-754 strict alors que x-87 ne l'est pas, x87 seulement les instructions prises separement (et avec un store) le sont.


(je vais editer je cherche qq infos)

[Tramb]

Etant donne que ce n'est pas une discussion privee je me suis permis de le linker pour ceux qui ne connaitraient pas, et je suis certain que c'est la majorite des visiteurs du forum.

Je plaisante c'est effectivement d'utilité publique quand on voit le nombre de mes collègues qui ignorent comment ça marche... et de gens qui s'extasient sur "la rsqrt magique de Carmack"

Sinon pour les questions de precisions, SSE est specifie comme un jeu d'instruction 2,1 avec operandes sur registres de longueur fixe et garantie (et de la meme taille que la norme le specifie).

Chaque operation passe par une phase de rounding conforme a la norme et ecrit sur un bus de resultat (qui amene aux registres ou est bypasse vers l'input d'une operation dependante) qui fait exactement la meme largeur que le registre. De ce fait il est donc impossible d'avoir le meme effet qu'avec x87 de precision "cachee", vu que ce que tu vois est ce que tu as.


(je vais editer je cherche qq infos)

Ca c'est *exactement* l'info qu'il me fallait!


(Sinon ça me paraitrait un peu cavalier de mettre le DAZ/FTZ de base pour tous les gens qui recompilent juste leur code numérique avec un nouveau compilo qui gère le SSE2, ca pourrait quand même faire des disparités importantes avec le x87, mais bon osef)

Si ta question est de savoir si les specs te garantissent un comportement identique entre processeurs de constructeurs différents, la réponse est en général oui, mais il y a quelques exceptions. Il y a effectivement certaines instructions SSEx qui sont spécifiées comme garantissant un résultat exact à N bits. Dans ce cas, le résultat sera reproductible sur un même processeur, mais rien ne garanti un résultat identique entre processeurs différents. Mais dans ce cas, c'est explicitement mentionné dans la doc.

L'important pour moi étant de pouvoir forcer le compilateur à n'en sortir aucun derrière mon dos, bien que je doute qu'il se permette de foutre des rcpss sans intrinsics.

[fefe]

Une des raisons pour lesquelles Intel recommande le DAZ sur SSE est que a l'origine SSE etait la pour faire de la 3D simple precision, donc un domaine ou DAZ est le defaut. Par consequent aucune attention n'a ete portee au support des denormaux qui sont particulierement lents sur Intel (mais pas chez AMD).

SSE2 est arrive par dessus ca, avec l'espoir de remplacer le x87 (le programming model est tellement plus simple et pratique, meme quand on est en scalar) en supplement. Les denormaux sont restes pourris et la recommandation d'utiliser DAZ avec. Quand tu te retrouves en denormal c'est du microcode qui prend la main et c'est tout de suite beaucoup plus long (cf un lien qu il faut que je trouve pour les latences des operateurs en denormal). Chez AMD une partie importante des conditions de denormaux sont traitees en hard d'ou en general un speedup impressionant par rapport a Intel (d'ou l'interet pour Intel de garder DAZ comme recommandation par defaut).

Sinon pour le passage de x87 a SSE2 il y a des warnings partout disnat qu'il n y a pas de garantie de toute facons que les resultats soient les memes (du a la non compatibilite stricte de x87 avec IEEE 754).

Quelqu'un qui recompile du code numerique en SSE2 sans reflechir un minimum merite d'avoir ses denormaux a zero, au moins ca lui evitera d'avoir des problemes de precisions durs a trouver caches un peu partout ca se verra directement.

La serie des 1/n croissant est un des exemples classiques de pourquoi coder en floating point sans comprendre ce qu'on fait ne peut amener qu'a des catastrophes et si qq uns ont le temps et ne savent pas a quoi s'attendre je recommande de le coder.

L'important pour moi étant de pouvoir forcer le compilateur à n'en sortir aucun derrière mon dos, bien que je doute qu'il se permette de foutre des rcpss sans intrinsics.

De toutes facons a partir de Penryn, meme pour des questions de perf les reciproques approximees ne seront plus interressantes, donc il vaut mieux oublier qu'elles n'aient jamais existees.

[Tramb]

Quelqu'un qui recompile du code numerique en SSE2 sans reflechir un minimum merite d'avoir ses denormaux a zero, au moins ca lui evitera d'avoir des problemes de precisions durs a trouver caches un peu partout ca se verra directement.

La serie des 1/n croissant est un des exemples classiques de pourquoi coder en floating point sans comprendre ce qu'on fait ne peut amener qu'a des catastrophes et si qq uns ont le temps et ne savent pas a quoi s'attendre je recommande de le coder.

On est bien d'accord mais le calcul numérique pour beaucoup de gens c'est:
"ah j'ai pas assez de précision en float je passe double"
"ah j'ai pas assez de précision en double je passe en inner 80bits"

De toutes facons a partir de Penryn, meme pour des questions de perf les reciproques approximees ne seront plus interressantes, donc il vaut mieux oublier qu'elles n'aient jamais existees.

Intéressant.

[Alice]

Je plaisante c'est effectivement d'utilité publique quand on voit le nombre de mes collègues qui ignorent comment ça marche... et de gens qui s'extasient sur "la rsqrt magique de Carmack"

C'est mal de s'extasié sur le Rsqrt dans QuakeIII ? (qui n'est d'ailleur pas de Camarck)

[Tramb]

C'est mal de s'extasié sur le Rsqrt dans QuakeIII ? (qui n'est d'ailleur pas de Camarck)

Non c'est justement de s'extasier sur "le rsqrt de Carmack" qui est mal.
Note les guillemets et l'association des termes

[Alice]

C'est subtil !

[fefe]

Ce qui est mal avec le rsqrt c'est que l'implementation d'AMD donnait des resultats differents de celle d'Intel, et dans certains jeux (dans mes souvenirs c'etait dans le moteur d'unreal qq chose) ils utilisaient des comparaisons sur l'ensemble des bits pour determiner par exemple des collisions. Le probleme est que vu qu'il n y avait que les 11 premiers bits d'egaux, dans une demo particuliere une rocket touchait sa cible sur un CPU et ne la touchait pas sur l'autre, favorisant immensement un constructeur par rapport a l'autre lors de comparaisons de perf utilisant cette demo.

Je ne me souviens plus si ils ont change la demo ou patche le code pour utiliser un divss mais c'etait marrant.

[Gabriel]

Quelqu'un qui recompile du code numerique en SSE2 sans reflechir un minimum merite d'avoir ses denormaux a zero, au moins ca lui evitera d'avoir des problemes de precisions durs a trouver caches un peu partout ca se verra directement.

Faut être un peu indulgent aussi: le programmeur lambda qui utilise un compilo Microsoft pour cibler de l'AMD64 se retrouve sans rien demander avec son code converti en SSE2, vu que de base MSVC ne génère plus de x87 dans cette conf.

(ceci dit, c'est vrai que pour quelqu'un qui ne se pose pas la question, il est possible que cela ne change pas grand chose pour lui d'avoir les dénormaux à 0)

[fefe]

Disons que pour un programmeur lambda, a priori il s'attend a avoir des flottants qu'il peut comparer a 0 plutot qu'a epsilon, donc DAZ est beaucoup moins sujet a erreur pour un programmeur qui ne sait pas ce qu'il fait.

Quand on est pas en DAZ arriver a avoir un nombre que l on peut comparer =0 est rare. Conclusion, ton programmeur lambda est en fait bien content d'avoir eu DAZ mis on dans son dos (et Microsoft ne fait pas que des choses horribles dans le dos des utilisateurs, l'essentiel est pas con en general, on remarque juste les cas ou ca l'etait).

[Gabriel]

et Microsoft ne fait pas que des choses horribles dans le dos des utilisateurs

Loin de moi cette idée

[Paul Verveine]

est-ce que quelqu'un peut traduire cette discussion ?

[Alexko]

Un exemple court:
si en SSE single tu fais
S = 1+1/2+1/3+1/4+...1/n

et tu compares avec la meme chose en x87
le resultat va etre different alors que si tu compares individuellement le resultat de chaque operation intermediaire les resultats seront egaux bits a bits.

La raison ici est que en x87 la conversion en 32 bits n'intervient pas apres chaque operation qui est faite en 80 bits en interne, mais juste au moment du store du resultat.

Tu veux dire que même en 32 bits, en x87 les calculs sont faits sur 80 bits en interne ? Ça n'implique pas un coût conséquent en performances ?

[Tramb]

est-ce que quelqu'un peut traduire cette discussion ?

En fait, si on fait les mêmes calculs sur plein de CPUs avec les même entrées, obtient-on toujours le même résultat.
Cette question se ramène à "Qui a tué Kennedy?" ou "Pourquoi les choux de Bruxelles?" mais grâce à pas mal de calculs.

(En fait c'est plutôt "Puis-je définir complètement une partie du jeu XXX juste avec le code de XXX et en rejouant les entrées au clavier/souris et en faisant tourner l'IA?" Moins intéressant que la raison d'être des choux de bxl)

[fefe]

Tu veux dire que même en 32 bits, en x87 les calculs sont faits sur 80 bits en interne ? Ça n'implique pas un coût conséquent en performances ?

La difference de perf entre single et double precision est minime a partir du moment ou tu as deja le hard pour faire du double.

[Paul Verveine]

merci tramb

[Alexko]

La difference de perf entre single et double precision est minime a partir du moment ou tu as deja le hard pour faire du double.

OK, dans ce cas je comprends mieux !

[Møgluglu]

Quelques petites rectifications...
Il y a en fait 2 problèmes distincts avec le x87 : la précision et la détection des overflows/underflows.

Pour la précision, le registre de contrôle x87 contient un flag permettant de sélectionner si l'arrondi de la mantisse aprés chaque opération doit se faire vers la simple, la double ou la double étendue.
La plupart des systèmes mettent ce flag par défaut en double pour des raisons de portabilité (et les compilos C associés mappent long double sur double). L'exception est GNU/Linux, qui tourne en double-étendue par défaut.

Le truc, c'est que ce contrôle de précision n'agit que sur la mantisse. L'exposant, lui, reste celui du format double-étendu 80 bits. Donc les seuls overflows/underflows qui sont détectés sont ceux de la double-étendue, pas ceux de la simple ni de la double. C'est seulement au moment de l'écriture en mémoire que ceux-ci sont détectés.

Simplement forcer l'écriture mémoire après chaque opération n'est pas suffisant si on ne règle pas aussi le registre de contrôle, à cause du problème du double arrondi.
En effet, si le résultat exact de l'opération est très proche du milieu de deux doubles consécutifs (représentable exactement en double-étendue) et se retrouve arrondi une première fois vers celui-ci, le second arrondi (lors de l'écriture en mémoire) va utiliser la règle de l'arrondi pair IEEE, et donc avoir une chance sur deux d'arrondir du mauvais côté.

SSE et SSE2 ont l'immense avantage de résoudre proprement tout ces problèmes et d'être IEEE-compliant par défaut (à part min et max qui ne suivront pas la prochaine norme, mais c'est pas la faute d'Intel).

C'est pour ça que je ne suis pas du tout d'accord avec fefe sur la question des DAZ/FTZ. Il serait à mon avis criminel de les activer par défaut.
De deux choses l'une:
- soit le calcul ne cause pas d'underflows, et ça ne coûte rien de respecter la norme,
- soit il en cause, et on a le choix entre calculer rapidement un résultat certainement faux ou calculer lentement un résultat éventuellement juste.
Le choix est vite fait en ce qui me concerne

En l'absence de dénormaux, quasiment toutes les règles de l'arithmétique flottante s'effondrent, et loin de simplifier la programmation cela la rend extrêmement complexe. Les dénormaux c'est un garde-fou pour les codes numériques un peu limite et pour simplifier les preuves.
Par exemple un débutant écrira:

if(a != b) {
  // je peux faire la division
  return c / (a - b);
}

et il aura raison, ça marche très bien avec une arithmétique IEEE-754. Mais pas sans dénormaux.

(oui, c'était juste le coup de gueule de celui qui doit faire de l'arithmétique sur GPU)

[Møgluglu]

Sur la question du déterminisme :

La norme IEEE 754 actuelle spécifie :
- 2 formats d'échange au bit près : simple et double précision.
- le comportement exact des additions, soustractions, multiplications, divisions, racines carrées, conversions dans avec 4 modes d'arrondi et les comparaisons.
- plein d'autres trucs que personne n'utilise comme les exceptions ou les flags...

Les implémentations sont libres d'utiliser les représentations internes qu'elles veulent et les algos qu'elles veulent tant que le comportement est celui voulu par la norme.

IEEE 754 ayant en partie été écrite pour normaliser a posteriori le comportement du X87, celui-ci est par définition IEEE-compliant.

La prochaine révision de la norme rajoute les formats half, quad et des équivalents décimaux, les opérations FMA, min et max.
Le comportement des autres opérations, et en particulier les fonctions élémentaires (exp, log, fonctions trigo...) n'est pas spécifié et ne le sera pas sinon sous forme facultative.

Ça c'est la belle théorie.
En pratique, le maillon faible est le compilateur. Les concepteurs de compilos ignorent superbement toutes les problématiques du calcul flottant, et te laissent en général le choix entre voir ton code entièrement réécrit en un calcul totalement différent ou (s'il sont gentils) désactiver toutes les optimisations.
Les langages eux-même (genre le C...) sont mal définis sur les précisions intermédiaires, les ordres d'évaluation, les formats...

[fefe]

Ton exemple c/(a-b) peut aussi etre source de problemes meme si tu supportes les denormaux, a moins que ton hypothese de depart est que ni a,b,c ne soient denormaux. Je suis d'accord avec toi que ca arrivera moins souvent mais ca ne fait que repousser le probleme. Les 2 camps sont activements defendus, celui des denormaux par les "numericiens" (Kahan et x87) celui du DAZ par ceux qui font du hardware et doivent gerer toutes sortes d'utilisateurs (SSE). Bien sur ce n'est pas si manicheen, mais l'image est la.

Et meme si la norme est le resultat du travail de Kahan avec Intel pour x87, en general la compliance de x87 est definie comme non stricte, essentiellement pour les problemes que tu as mieux expliques que moi.

Pour les latences en simple precision, la taille reduite de ta mantisse (quand les flags dont parle Mogluglu sont actives) te permet d'arreter des operations comme la multiplication ~ 1 cycle avant.

Meme si la plupart des processeurs ont toujours eu la possibilite de supporter la norme, il y en a plus d'un qui ne la supportait pas dans son mode d'operation par defaut, le plus connu etant l'alpha qui ne respectait pas la norme pour les overflow/NaN en hard jusqu'a EV6 (une option de compilation permettait de l'activer et le soft gerait ces cas la).

Je ne sais pas vraiment ce que font les GPUs mais je suppose que tu n'as pas l'option de trap et de gerer l'exception a la main en soft, d'ou pas mal de problemes.

PS: j'ai vu plus de problemes lies a la presence de denormaux que de problemes de DAZ/FTZ parmi les utilisateurs qui utilisaient le flottant sans comprendre. Certes le resultat avec les denormaux a des chances d'etre plus proche du resultat vise (mais c'est un peu comme utiliser double a la place de float en esperant avoir un meilleur resultat), mais ce n'est pas systematique, et on y arrive beaucoup plus lentement.

Ça c'est la belle théorie.
En pratique, le maillon faible est le compilateur. Les concepteurs de compilos ignorent superbement toutes les problématiques du calcul flottant, et te laissent en général le choix entre voir ton code entièrement réécrit en un calcul totalement différent ou (s'il sont gentils) désactiver toutes les optimisations.
Les langages eux-même (genre le C...) sont mal définis sur les précisions intermédiaires, les ordres d'évaluation, les formats...

Oui,
l'exemple classique est S=A*B+C*D+E*F+G*H

Pour etre compatible avec IEEE il faut considerer que l'addition n'est pas associative et donc executer:

A*B,C*D,E*F,G*H
   +
       +
           +

Alors que si le compilateur considere l'addition comme associative (ce qui est le cas pour l'addition entiere) il peut faire:

A*B,C*D,E*F,G*H
    +      +
       +

La tentation est souvent forte de reordonnancer les instructions pour optimiser le code... mais le resultat n'est pas le meme