Release Code Optimization Problems..
-
Hello, SCENARIO:
- I have some "C" code that runs heavy math, that takes time to get the results.
- Compiling under a Debug configuration, all goes as required.. but the run sessing is to slow (few hours to get the results.)
- Compiling under a Release configuration, fails to get the required results.
(Release configuration with its default Speed code optimization (/O2 flag)) - When I turn off speed optimizations under Release configurations, the results are O.K, but again, it runs slower than expected.
QUESTIONS
- How can I detect what does causes this differences on the code?
- How can I debug this code and catch the affecting lines?
I guess that this has to do in the way this "C" code is written, that optimizing it for speed causes the differences. All this code runs under the same thread, and uses data that is static. Any hint?:sigh::confused: Thanks in Advance.
-- **Ricky Marek** (_AKA: rbid_)-- "Things are only impossible until they are not" --- Jean-Luc Picard My articles -
Hello, SCENARIO:
- I have some "C" code that runs heavy math, that takes time to get the results.
- Compiling under a Debug configuration, all goes as required.. but the run sessing is to slow (few hours to get the results.)
- Compiling under a Release configuration, fails to get the required results.
(Release configuration with its default Speed code optimization (/O2 flag)) - When I turn off speed optimizations under Release configurations, the results are O.K, but again, it runs slower than expected.
QUESTIONS
- How can I detect what does causes this differences on the code?
- How can I debug this code and catch the affecting lines?
I guess that this has to do in the way this "C" code is written, that optimizing it for speed causes the differences. All this code runs under the same thread, and uses data that is static. Any hint?:sigh::confused: Thanks in Advance.
-- **Ricky Marek** (_AKA: rbid_)-- "Things are only impossible until they are not" --- Jean-Luc Picard My articlesrbid wrote:
All this code runs under the same thread
Create the seperate synchronised threads for the large calculations and which is not much dependent on each other Knock out 't' from can't, You can if you think you can :cool:
-
rbid wrote:
All this code runs under the same thread
Create the seperate synchronised threads for the large calculations and which is not much dependent on each other Knock out 't' from can't, You can if you think you can :cool:
A_Laxman wrote:
rbid wrote: All this code runs under the same thread Create the seperate synchronised threads for the large calculations and which is not much dependent on each other
This is exactly how it is implemented. The code that has the problem runs on a separate synchronized thread. Even if I encapsulate the code on a single "console application", the problem persists. Thanks for your thoughts, this place is a great place for getting good ideas and solutions.
-- **Ricky Marek** (_AKA: rbid_)-- "Things are only impossible until they are not" --- Jean-Luc Picard My articles -
Hello, SCENARIO:
- I have some "C" code that runs heavy math, that takes time to get the results.
- Compiling under a Debug configuration, all goes as required.. but the run sessing is to slow (few hours to get the results.)
- Compiling under a Release configuration, fails to get the required results.
(Release configuration with its default Speed code optimization (/O2 flag)) - When I turn off speed optimizations under Release configurations, the results are O.K, but again, it runs slower than expected.
QUESTIONS
- How can I detect what does causes this differences on the code?
- How can I debug this code and catch the affecting lines?
I guess that this has to do in the way this "C" code is written, that optimizing it for speed causes the differences. All this code runs under the same thread, and uses data that is static. Any hint?:sigh::confused: Thanks in Advance.
-- **Ricky Marek** (_AKA: rbid_)-- "Things are only impossible until they are not" --- Jean-Luc Picard My articlesIf a code runs in debug mode and not in release mode then most probably there is a bug in the code, which is exposed in release mode due to optimizations. If you are using VS 2005 (this might work with VS 2003 also but I am not sure since I never used it) then its simple, just put break point in the code and let then program run under debugger. When program crashes visual studio will give you an option of breaking into the code. This way you will know where exactly is the problem. If you are using some older versions then try debugging the usual way. Look carefully at pointers, if you are using them. Try putting testing fprintf's/ or AfxMessageBox's (if you are using MFC) in release mode at various places and see how far code is able to execute. Another way might be to take crash address and find which souce line it corresponds to using a map file[^]. When using a map file you might get crash at a line which is not in your code or at a place where you are sure there's nothing wrong. In that case you will have to figure out which functions are calling the function which crashed. Hope this helps. -Saurabh
-
Hello, SCENARIO:
- I have some "C" code that runs heavy math, that takes time to get the results.
- Compiling under a Debug configuration, all goes as required.. but the run sessing is to slow (few hours to get the results.)
- Compiling under a Release configuration, fails to get the required results.
(Release configuration with its default Speed code optimization (/O2 flag)) - When I turn off speed optimizations under Release configurations, the results are O.K, but again, it runs slower than expected.
QUESTIONS
- How can I detect what does causes this differences on the code?
- How can I debug this code and catch the affecting lines?
I guess that this has to do in the way this "C" code is written, that optimizing it for speed causes the differences. All this code runs under the same thread, and uses data that is static. Any hint?:sigh::confused: Thanks in Advance.
-- **Ricky Marek** (_AKA: rbid_)-- "Things are only impossible until they are not" --- Jean-Luc Picard My articlesI hate those problems. There's almost nothing you can do to determine the problem. The only way I've been able to sort it out reliably is to narrow down to a particular section of code by comparing the results with what is expected every few lines, and flag an error (a message box or debug trace) when they don't match. When you can find out which section of code causes the problem, check it extremely carefully to catch things that might be dependent on the compiler moving statements around, and possibly rewrite the code. Even if it's slightly less efficient, the extra speed you get with optimisation will probably make it worthwhile. Good luck :rose:
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
-
If a code runs in debug mode and not in release mode then most probably there is a bug in the code, which is exposed in release mode due to optimizations. If you are using VS 2005 (this might work with VS 2003 also but I am not sure since I never used it) then its simple, just put break point in the code and let then program run under debugger. When program crashes visual studio will give you an option of breaking into the code. This way you will know where exactly is the problem. If you are using some older versions then try debugging the usual way. Look carefully at pointers, if you are using them. Try putting testing fprintf's/ or AfxMessageBox's (if you are using MFC) in release mode at various places and see how far code is able to execute. Another way might be to take crash address and find which souce line it corresponds to using a map file[^]. When using a map file you might get crash at a line which is not in your code or at a place where you are sure there's nothing wrong. In that case you will have to figure out which functions are calling the function which crashed. Hope this helps. -Saurabh
Saurabh.Garg wrote:
ForumVisual C++ / MFC Subject:Re: Release Code Optimization Problems.. Sender:Saurabh.Garg Date:4:32 20 May '06 If a code runs in debug mode and not in release mode then most probably there is a bug in the code, which is exposed in release mode due to optimizations. If you are using VS 2005 (this might work with VS 2003 also but I am not sure since I never used it) then its simple, just put break point in the code and let then program run under debugger. When program crashes visual studio will give you an option of breaking into the code. This way you will know where exactly is the problem. Hope this helps. -Saurabh
You are right, but the code does not crash, just gives a different result that is not acceptable. Puting a breakpoint or dumping via TRACE or printf is like searching for needle in a montain of hay (or how you say it).. I'm running VS 2003. A great article about Surviving the Release version[^] can be found in this site as well.. I'm also thinking about what is mentioned [here](http://www.codeproject.com/debug/survivereleasever.asp#Compiler Bugs (again))[[^](http://www.codeproject.com/debug/survivereleasever.asp#Compiler Bugs (again) "New Window")]. Have a nice day.
-- **Ricky Marek** (_AKA: rbid_)-- "Things are only impossible until they are not" --- Jean-Luc Picard My articles -
I hate those problems. There's almost nothing you can do to determine the problem. The only way I've been able to sort it out reliably is to narrow down to a particular section of code by comparing the results with what is expected every few lines, and flag an error (a message box or debug trace) when they don't match. When you can find out which section of code causes the problem, check it extremely carefully to catch things that might be dependent on the compiler moving statements around, and possibly rewrite the code. Even if it's slightly less efficient, the extra speed you get with optimisation will probably make it worthwhile. Good luck :rose:
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
Ryan Binns wrote:
ForumVisual C++ / MFC Subject:Re: Release Code Optimization Problems.. Sender:Ryan Binns Date:7:53 20 May '06 I hate those problems. There's almost nothing you can do to determine the problem. The only way I've been able to sort it out reliably is to narrow down to a particular section of code by comparing the results with what is expected every few lines, and flag an error (a message box or debug trace) when they don't match. When you can find out which section of code causes the problem, check it extremely carefully to catch things that might be dependent on the compiler moving statements around, and possibly rewrite the code. Even if it's slightly less efficient, the extra speed you get with optimisation will probably make it worthwhile.
Yes, you have interpreted my question correctly. I guess that I will continue to dumping (via TRACE) debug information to catch the problem, it is like looking for a needle in a montain of hay. and even worse, the problem is detected only after running for almost 1hour. (That is the reason why speed optimizations are required) Thanks for your help.
-- **Ricky Marek** (_AKA: rbid_)-- "Things are only impossible until they are not" --- Jean-Luc Picard My articles -
Hello, SCENARIO:
- I have some "C" code that runs heavy math, that takes time to get the results.
- Compiling under a Debug configuration, all goes as required.. but the run sessing is to slow (few hours to get the results.)
- Compiling under a Release configuration, fails to get the required results.
(Release configuration with its default Speed code optimization (/O2 flag)) - When I turn off speed optimizations under Release configurations, the results are O.K, but again, it runs slower than expected.
QUESTIONS
- How can I detect what does causes this differences on the code?
- How can I debug this code and catch the affecting lines?
I guess that this has to do in the way this "C" code is written, that optimizing it for speed causes the differences. All this code runs under the same thread, and uses data that is static. Any hint?:sigh::confused: Thanks in Advance.
-- **Ricky Marek** (_AKA: rbid_)-- "Things are only impossible until they are not" --- Jean-Luc Picard My articlesSounds a lot like scientific programming. I do not know your code, but this sort of problem often arises from: 1.)Array overrun (Solution: interface array access through an intermediary function that executes a bunch of assert(); to verify that access is always within bounds. The asserts all dissappear in the release mode so that they do not slow production down at all.) 2.)Optimizer bug. (Here the machine-code generated by the compiler is just flat wrong. Every mature scientific programmer must be prepared to deal with this horrible sort of problem. I have NEVER (since 1965) dealt with a compiler that I did not find bugs in its code generation. Here, my best approach is to start backward from the crash line. Either some datum going into the crash is wrong or the line is encoded wrong.) Item 1.) is about 100 times more common than item 2.) but they lead to comparable amount of grief in toto. Gematria
-
Sounds a lot like scientific programming. I do not know your code, but this sort of problem often arises from: 1.)Array overrun (Solution: interface array access through an intermediary function that executes a bunch of assert(); to verify that access is always within bounds. The asserts all dissappear in the release mode so that they do not slow production down at all.) 2.)Optimizer bug. (Here the machine-code generated by the compiler is just flat wrong. Every mature scientific programmer must be prepared to deal with this horrible sort of problem. I have NEVER (since 1965) dealt with a compiler that I did not find bugs in its code generation. Here, my best approach is to start backward from the crash line. Either some datum going into the crash is wrong or the line is encoded wrong.) Item 1.) is about 100 times more common than item 2.) but they lead to comparable amount of grief in toto. Gematria
Ray Hagstrom wrote:
ForumVisual C++ / MFC Subject:Re: Release Code Optimization Problems.. Sender:Ray Hagstrom Date:14:46 20 May '06 Sounds a lot like scientific programming.
I'm doing some system verification code, the system guys use Matlab for generating their models, and I run some "C" code to verify their models.
Ray Hagstrom wrote:
1.)Array overrun (Solution: interface array access through an intermediary function that executes a bunch of assert(); to verify that access is always within bounds. The asserts all dissappear in the release mode so that they do not slow production down at all.)
Yes, But this could also happen in the Debug or Release without speed optimization, and it does not happen, the problem arises only when I compile the code with speed optimization (/O2 flag) (PC-Lint[^] did not find any access out of bounds in the code)
Ray Hagstrom wrote:
2.)Optimizer bug. (Here the machine-code generated by the compiler is just flat wrong. Every mature scientific programmer must be prepared to deal with this horrible sort of problem. I have NEVER (since 1965) dealt with a compiler that I did not find bugs in its code generation. Here, my best approach is to start backward from the crash line. Either some datum going into the crash is wrong or the line is encoded wrong.)
The program does not crash, but produces wrong results when compiled with the optimize for speed flag. I'm currently adding some TRACE lines to print out the computed results and then compare them with the Debug (or Release without code optimization).. but that is like looking for a needle in a montain of hay :(( Any additional hint? Thanks to all in advance. :rose:
-- **Ricky Marek** (_AKA: rbid_)-- "Things are only impossible until they are not" --- Jean-Luc Picard My articles -
Ryan Binns wrote:
ForumVisual C++ / MFC Subject:Re: Release Code Optimization Problems.. Sender:Ryan Binns Date:7:53 20 May '06 I hate those problems. There's almost nothing you can do to determine the problem. The only way I've been able to sort it out reliably is to narrow down to a particular section of code by comparing the results with what is expected every few lines, and flag an error (a message box or debug trace) when they don't match. When you can find out which section of code causes the problem, check it extremely carefully to catch things that might be dependent on the compiler moving statements around, and possibly rewrite the code. Even if it's slightly less efficient, the extra speed you get with optimisation will probably make it worthwhile.
Yes, you have interpreted my question correctly. I guess that I will continue to dumping (via TRACE) debug information to catch the problem, it is like looking for a needle in a montain of hay. and even worse, the problem is detected only after running for almost 1hour. (That is the reason why speed optimizations are required) Thanks for your help.
-- **Ricky Marek** (_AKA: rbid_)-- "Things are only impossible until they are not" --- Jean-Luc Picard My articlesOne other thing you could try is to enable optimisation for your debug build and see if it has the same problem. If it does, you can step through it with the debugger. You won't be able to go one line at a time, but you should be able to narrow it down enough to find the problem area.
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
-
Saurabh.Garg wrote:
ForumVisual C++ / MFC Subject:Re: Release Code Optimization Problems.. Sender:Saurabh.Garg Date:4:32 20 May '06 If a code runs in debug mode and not in release mode then most probably there is a bug in the code, which is exposed in release mode due to optimizations. If you are using VS 2005 (this might work with VS 2003 also but I am not sure since I never used it) then its simple, just put break point in the code and let then program run under debugger. When program crashes visual studio will give you an option of breaking into the code. This way you will know where exactly is the problem. Hope this helps. -Saurabh
You are right, but the code does not crash, just gives a different result that is not acceptable. Puting a breakpoint or dumping via TRACE or printf is like searching for needle in a montain of hay (or how you say it).. I'm running VS 2003. A great article about Surviving the Release version[^] can be found in this site as well.. I'm also thinking about what is mentioned [here](http://www.codeproject.com/debug/survivereleasever.asp#Compiler Bugs (again))[[^](http://www.codeproject.com/debug/survivereleasever.asp#Compiler Bugs (again) "New Window")]. Have a nice day.
-- **Ricky Marek** (_AKA: rbid_)-- "Things are only impossible until they are not" --- Jean-Luc Picard My articlesOh I interpreted your question incorrectly. In this case you can selectly turn off optimizations using #pragma optimize( "", off ) . . . #pragma optimize( "", on ) any functions with these two statements won't be optimized. Try disbaling optimization for most critical functions and see if results are as expected. Keep trying until you get correct result. If your code is huge then it might be a tedious process but its better then checking intermediate results as computing them by hand might be difficult. -Saurabh
-
Oh I interpreted your question incorrectly. In this case you can selectly turn off optimizations using #pragma optimize( "", off ) . . . #pragma optimize( "", on ) any functions with these two statements won't be optimized. Try disbaling optimization for most critical functions and see if results are as expected. Keep trying until you get correct result. If your code is huge then it might be a tedious process but its better then checking intermediate results as computing them by hand might be difficult. -Saurabh
Saurabh.Garg wrote:
ForumVisual C++ / MFC Subject:Re: Release Code Optimization Problems.. Sender:Saurabh.Garg Date:22:21 20 May '06 Oh I interpreted your question incorrectly. In this case you can selectly turn off optimizations using #pragma optimize( "", off ) . . . #pragma optimize( "", on )
Eureka:-D, thanks for the idea. (It is so simple when you know it :) ). Thanks.
-- **Ricky Marek** (_AKA: rbid_)-- "Things are only impossible until they are not" --- Jean-Luc Picard My articles -
Saurabh.Garg wrote:
ForumVisual C++ / MFC Subject:Re: Release Code Optimization Problems.. Sender:Saurabh.Garg Date:22:21 20 May '06 Oh I interpreted your question incorrectly. In this case you can selectly turn off optimizations using #pragma optimize( "", off ) . . . #pragma optimize( "", on )
Eureka:-D, thanks for the idea. (It is so simple when you know it :) ). Thanks.
-- **Ricky Marek** (_AKA: rbid_)-- "Things are only impossible until they are not" --- Jean-Luc Picard My articlesSo were you able to solve the problem. It would be nice if you can share what type of code can cause optimization problems. -Saurabh
-
So were you able to solve the problem. It would be nice if you can share what type of code can cause optimization problems. -Saurabh
Saurabh.Garg wrote:
ForumVisual C++ / MFC Subject:Re: Release Code Optimization Problems.. Sender:Saurabh.Garg Date:22:36 21 May '06 So were you able to solve the problem. It would be nice if you can share what type of code can cause optimization problems. -Saurabh
I'm still fighting with it. But at least, I know which files are the cause. It seems that the developer was not aware that optimizations could cause some aliasing..about aliasing. (Using pointers to variables that the compiler may supress during optimization) Look in:
- Writing Efficient C and C Code Optimization[^]
- Look forAssume No Aliasing, Assume Aliasing Across Function Calls in the MSDN documentation (I could not find the internet link)
I will sumarize when I finish my investigation.
-- **Ricky Marek** (_AKA: rbid_)-- "Things are only impossible until they are not" --- Jean-Luc Picard My articles -
One other thing you could try is to enable optimisation for your debug build and see if it has the same problem. If it does, you can step through it with the debugger. You won't be able to go one line at a time, but you should be able to narrow it down enough to find the problem area.
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
Ryan Binns wrote:
ForumVisual C++ / MFC Subject:Re: Release Code Optimization Problems.. Sender:Ryan Binns Date:20:38 20 May '06 One other thing you could try is to enable optimisation for your debug build and see if it has the same problem. If it does, you can step through it with the debugger. You won't be able to go one line at a time, but you should be able to narrow it down enough to find the problem area. Ryan
I'm using your sugestion together with the sugestion in: http://www.codeproject.com/script/comments/forums.asp?forumid=1647&select=1497199&fr=364&df=100#xx1497199xx[^] So far, I managed to isolate a bunch of files that cause the problem, it seems that the developer that wrote that code was not aware about aliased code. (I asked him to take a look and maybe re-design some code that causes the problem.) I will sumarize the results. Thanks.
-- **Ricky Marek** (_AKA: rbid_)-- "Things are only impossible until they are not" --- Jean-Luc Picard My articles -
Hello, SCENARIO:
- I have some "C" code that runs heavy math, that takes time to get the results.
- Compiling under a Debug configuration, all goes as required.. but the run sessing is to slow (few hours to get the results.)
- Compiling under a Release configuration, fails to get the required results.
(Release configuration with its default Speed code optimization (/O2 flag)) - When I turn off speed optimizations under Release configurations, the results are O.K, but again, it runs slower than expected.
QUESTIONS
- How can I detect what does causes this differences on the code?
- How can I debug this code and catch the affecting lines?
I guess that this has to do in the way this "C" code is written, that optimizing it for speed causes the differences. All this code runs under the same thread, and uses data that is static. Any hint?:sigh::confused: Thanks in Advance.
-- **Ricky Marek** (_AKA: rbid_)-- "Things are only impossible until they are not" --- Jean-Luc Picard My articlesHello to all, First of all, thanks for your help in trying to solve this problem. The problem is solved, and was caused by variable aliasing that confused the compiler optimizations. The code that caused the problem has been re-designed and fixed. (I found also other spaguetti programming problems there). How was this problem isolated
-
First I added to the beginning and end of all source files (not header files) the following line:
// Add at the beggining of the file:
#pragma optimize( "", off )
...
// Add at the end of the file:
#pragma optimize ("", on ) -
Then file by file, once a time I removed the pragma to see if the problem appears, if yes, mark the file as problematic and continue to the next file.(restoring the #pragma to the beggining of it)
-
Once I finished with all files, and ending with a pair of problematic files, I started to do the same for isolating the "functions" that caused the problem.
// Add before the function body:
#pragma optimize( "", off )
...
// Add after the function closinc brace:
#pragma optimize ("", on )- At the end, I found that only a small number of functions were the ones that caused the problem, and the reason was variable aliasing.
The code was belonging to a novice developer, that with my help he has re-designed his code and now we all are happy :) Note: Variable aliasing is described in the VC documentation, look under Compiler Optimizations, specially for the flags /Ow or /Oa. Thanks to all who helped me to identify the problem.
-- **Ricky Marek** (_AKA: rbid_)-- "Things are only impossible until they are not" --- Jean-Luc Picard My articles