|
[Sponsors] |
Results from debug and nondebug code are different |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
July 15, 2004, 11:20 |
Results from debug and nondebug code are different
|
#1 |
Guest
Posts: n/a
|
Hi, Who had the same problem? What is the main reason? Thanks for your help.
|
|
July 15, 2004, 11:50 |
Re: Results from debug and nondebug code are diffe
|
#2 |
Guest
Posts: n/a
|
Does one of those run with some optimization flag? Optimized and non-optimized will give you different results often if your code is not "perfect". This might be something similar. Just a guess...
-- Jarmo |
|
July 15, 2004, 12:37 |
Re: Results from debug and nondebug code are diffe
|
#3 |
Guest
Posts: n/a
|
Please specify: what language and compilator are you using for code development.
Consider that using debug flag you turn off all the protections in your code. I suggest first to be sure that your code does not give you ANY warning during the compilation from a scratch. Best, Maciej Matyka btw. Dream Equation - a demoscene production with CFD |
|
July 15, 2004, 13:17 |
Re: Results from debug and nondebug code are diffe
|
#4 |
Guest
Posts: n/a
|
Thanks for your answer. Good guess. I am trying different optimization flags. You are right my code is not perfect. As you know, it is hard to clean it.
|
|
July 15, 2004, 13:19 |
Re: Results from debug and nondebug code are diffe
|
#5 |
Guest
Posts: n/a
|
Thanks for your answer. I am gcc to compile my C++ code. There are no any warnings. With double, there is no problem at all for two versions.
|
|
July 15, 2004, 17:29 |
Re: Results from debug and nondebug code are diffe
|
#6 |
Guest
Posts: n/a
|
So, use the double
Maciej Matyka <A HREF="http://panoramix.ift.uni.wroc.pl/~maq/eng/">http://panoramix.ift.uni.wroc.pl/~maq/eng/</a> |
|
July 15, 2004, 19:47 |
Re: Results from debug and nondebug code are diffe
|
#7 |
Guest
Posts: n/a
|
You have one of two possible problems: 1)The compiler is just not optimizing your code correctly. 2)You have a memory problem. You are going outside some array bound and actually corrupting an instruction. When you turn off optimization, the instructions are different and your "corruption" may wander somewhere else and either disappear or cause some other part of your code to behave strangely.
I've seen both. |
|
July 16, 2004, 08:38 |
Re: Results from debug and nondebug code are diffe
|
#8 |
Guest
Posts: n/a
|
1. You might want to check and make sure you do not have any variables which are not initialized properly!
I would suggest using print statements in the debug and non debug code. It should be a rather straight forward matter to isolate the section of code which generates the difference. Then it may become obvious what the problem is. |
|
July 18, 2004, 02:52 |
Re: Results from debug and nondebug code are diffe
|
#9 |
Guest
Posts: n/a
|
Another wild guess: If you have floating-point arithmetics, and somewhere in your code you have branching according to comparison of float-type variable(s) with inappropriate tolerance, you may branch to different code segments with- and without- debug due to the different order of operations at various compilation/linking options.
|
|
July 18, 2004, 15:47 |
Re: Results from debug and nondebug code are diffe
|
#10 |
Guest
Posts: n/a
|
Good guess too. I played with that already. It seems not.
|
|
July 18, 2004, 15:47 |
Re: Results from debug and nondebug code are diffe
|
#11 |
Guest
Posts: n/a
|
|
|
July 18, 2004, 15:48 |
Re: Results from debug and nondebug code are diffe
|
#12 |
Guest
Posts: n/a
|
I am writing a commercial code, not for a paper. So, I can not do that.
|
|
July 18, 2004, 15:49 |
Re: Results from debug and nondebug code are diffe
|
#13 |
Guest
Posts: n/a
|
|
|
July 18, 2004, 15:53 |
Re: Results from debug and nondebug code are diffe
|
#14 |
Guest
Posts: n/a
|
I am checking it now using print. Unfortunately, this problem does not appear in all problems. The problem I am testing has over one million cells.
|
|
July 19, 2004, 08:22 |
Re: Results from debug and nondebug code are diffe
|
#15 |
Guest
Posts: n/a
|
Is it a gradual progression or an immediate difference?
If it is gradual then you could be in the business of compounded rounding within your algorithm. Which means you will have to evaluate the IMPLEMENTATION of your algorithm and remove excessive rounding. If it is an immediate difference then print statements should still do the trick. Since it is a large problem I would suggest using your friends -> awk, grep, and diff to post process the data from your print statements. |
|
|
|