Erreur d'arrondi différentes en mode Debug ou Release

Erreur d'arrondi différentes en mode Debug ou Release - C++ - Programmation

Marsh Posté le 17-04-2003 à 17:03:22    

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.


Message édité par Tetragrammaton IHVH le 17-04-2003 à 17:09:08

---------------
"Dieu a exploité tous nos complexes d'infériorité, en commençant par notre incapacité de croire à notre propre divinité." - Emil Michel Cioran
Reply

Marsh Posté le 17-04-2003 à 17:03:22   

Reply

Marsh Posté le 17-04-2003 à 17:14:52    

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


---------------
last.fm
Reply

Marsh Posté le 17-04-2003 à 17:18:26    

Tetragrammaton IHVH a écrit :

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.


 
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
 
 

Reply

Marsh Posté le 17-04-2003 à 17:22:02    

chrisbk a écrit :


 
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.


---------------
"Dieu a exploité tous nos complexes d'infériorité, en commençant par notre incapacité de croire à notre propre divinité." - Emil Michel Cioran
Reply

Marsh Posté le 17-04-2003 à 17:23:32    

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

Reply

Marsh Posté le 17-04-2003 à 17:34:49    

à 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  :cry: )

Reply

Marsh Posté le 17-04-2003 à 17:37:38    

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 :/

Reply

Marsh Posté le 17-04-2003 à 17:39:00    

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 ...


---------------
last.fm
Reply

Marsh Posté le 17-04-2003 à 17:40:39    

BJOne a écrit :

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 :/


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


---------------
last.fm
Reply

Marsh Posté le 17-04-2003 à 17:41:48    

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)....

Reply

Marsh Posté le 17-04-2003 à 17:41:48   

Reply

Marsh Posté le 17-04-2003 à 17:44:16    

BJOne a écrit :

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)
 
 

Reply

Marsh Posté le 17-04-2003 à 17:44:23    

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 :D
 
tout ça de manière "transparente" au programmeur/utilisateur...

Reply

Marsh Posté le 17-04-2003 à 17:45:40    

chrisbk a écrit :


 
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)
 


 
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 :D

Reply

Marsh Posté le 17-04-2003 à 17:49:50    

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.


---------------
each day I don't die is cheating
Reply

Marsh Posté le 17-04-2003 à 21:03:17    

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


---------------
voxel terrain render engine | animation mentor
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed