Je code en C++ sur VS 6.0
 
J'ai remarqué que j'avais des erreurs d'arrondi legerement différentes (de l'ordre de 10^-15 sur des double) selon si je compile en release ou en debug ? En l'occurence, il semble que c'est le mode debug qui est le plus exact.
 
C'est pas vraiment critique mais j'aimerais bien savoir d'où vient ce binz ? Ca serait pas un truc du genre le FPU est emulé en mode debug ?
 
Merci par avance.

 
étrange en effet ...
 
mode "BOOLAY" ON
Ca doit être à cause des asserts ...
mode "BOOLAY" OFF
 

 
Non, fait un listing asm tu verras que la fpu est bien utilisée
par contre, dans VC7 y'a un truc a propos de la FPU dans les reglages du projet, regarde voir si t'as ca dans ton vc6
 
 

 
Je vais vérifier. Au fait, je précise que j'ai bien tracé chaque nombre pour voir d'où venait le stress. Je vais essayer de faire un petit prog pour mettre en valeur ce problème.

essaye en virant la global optimisation pour voir, parait que ca peut generer des soucis (de mémoire & pas vérifié)

à priori je dirais qu'en debug, le fpu est configuré pour une précision interne 80 bits, alors qu'en release le fpu est ptet uniquement en 64 bits (ou 56 je sais pu   )

en fait deux choses peuvent influencer la consistance des calculs:
 
1) le mode interne: 80/64/32....
 
2) le flux de code: forcément plus le code passe par des registres, si le fpu est mode 80 bits par exemple, plus la précision sera grande car on passera moins par des float/double de ton code en C/C++.
 
à priori je dirais qu'en DEBUG, la précision interne est la plus grande, alors qu'en RELEASE la précision est plus basse, mais le flux utilise "mieux" les registres...  
 
donc désolé d'avoir complexisifé la chose

J'ai du mal à voir quel intérêt ca aurait de changer la précision en mode debug ... (attention, je ne dis pas que ce n'est pas ca ... Je dis juste que ce serait vraiment surprenant ...)
 
Ce que propose chrisbk me parait plus plausible ... Une option de compilation qui engendrerait une perte de précision me semble être une cause plus appropriée aux conséquences observées ...

ok ... Je retire ce que je viens d'écrire ...

bah je dit ça, mais quand tu est mode "standard" de compilation ça reste du fpu87 en mode par défaut donc problablement 64 ou 80 bits.
en mode release, quand tu fous toutes les optimisations à donf, le compilo va générer du code fpu ciblé pour le ppro, avec un mode de précision "balancé", une utilisation max des registres, et des réciproques là ou c'est rentable ( "fmul 1/valeur" où "1/valeur" est précalculé, au lieu de "fdiv valeur" par exemple)....

 
tu crois qu'il se permet ce genre de chose ? Si oui doit avoir moyen de changer ca (sous VC7 c'est "improve floating point consistency", ca vient de me revenir)
 
 

en fait le fpu est utilisé comme les pipelines à pixels des cartes graphiques ou ta texture est en S3TC en 4bits/pixel, puis étendue dans le pipeline en 32/64/96/128bpp (entier ou flottant), puis ramené une fois dans le framebuffer en 16/32/64/96/128, puis attaqué par le ramdac en 16 ou 32 8:8:8:8 ou 2:10:10:10
 
tout ça de manière "transparente" au programmeur/utilisateur...

 
bin ché pas c'est un exemple, mais je sais que j'ai déja vu passer des options comme ça...
 
ce genre de subtilité c'est le watcom qui me les a jetées au visage

Sous VC++ 6.0, tu as l'option "Improve Float Consistency" dans les optimisations. Je n'y connais rien, mais vous pouvez aller voir ce lien.

peut-etre qu'il reordonne simplement les instructions
en release pour etre plus efficace d'ou les differences constatees.
 
LeGreg