-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 16.05.2014 12:05, jbc.engelen@...2592... wrote:
---- "Jon A. Cruz" wrote:
On Thu, May 15, 2014, at 03:53 PM, Krzysztof Kosiński wrote:
2014-05-15 23:56 GMT+02:00 Johan Engelen <jbc.engelen@...2592...>:
Hi all, Why do we build with -O2 instead of O3?
Because -O3 compilation takes a lot more time and memory than -O2, yet the improvement is minor in most cases.
It may make sense for compiling releases, but for regular development -O2 is enough. So unless you can show that under some specific circumstances Inkscape performs much better with -O3, I think the default should stay at -O2.
Krzysztof summarized it pretty well here, however I did want to highlight the need for actual performance numbers. [...]
For my dev builds I have to use -O0 (to turn off optimizations) otherwise stepping through debuggers can be quite misleading. Stack traces from crashes can also be affected.
The -O2 level is pretty common to target, however some products actually choose to ship with -O0 instead. Some very high load/performance server systems I'd worked on were like that. In general one can often architect code nicely enough to not require compiler optimizations and can benefit from clear debugging data when the rare crash or forced dump occurs.
One other factor is in code clarity. Sometimes it is easy to get better performance not bumping up the optimization level, but instead by "de-optimizing" the source. That is, if one removes a coder's attempts at micro-optimizations it often leads to code that looks slower but, since it is clearer, will actually be much faster as a good compiler can do more with it.
But remember, the main take-away is that we need to get performance data from live end-to-end full test scenarios. And keep in mind that studies have shown developer intuition on performance to be wrong 80%+ of the time.
Please don't change the topic. The question is about a compiler flag, that may give better code for free, not about coding for performance.
I raise the question because perhaps the person who set O2 knew of any bugs caused by O3. I don't see any other reason for not using it. Sure, it won't improve performance (we all know why Inkscape is slow), but it won't make it slower either. Compile speed is not very much affected, and if one wants to use a debugger (I hardly ever do), one should change the flags anyway. Changing from O2 to O3 only for release to me seem like asking for trouble.
Off-topic: For debug-builds you can use -Og (in recent GCC versions), which will enable optimizations that don't interfere with the debugging. Independently, compiling with -fno-omit-frame-pointer (regardless of -O level) improves stacktracing ability, particularly on Windows, where MS stack tracing code may not work at all without frame pointer.
On-topic: It's simple. If -O3 doesn't introduce any bugs (which can be verified by extensive testing, i guess) AND gives measurable performance bump - - do use it. Otherwise (if it breaks things or if it reduces performance (which is known to happen)) - don't.
Now, i haven't debugged much software with -O3, so i can't say whether doing default dev builds with -O3 is a wise choice. Debugging -O2 kind of works most of the time, once you learn its quirks, and you can always rebuild the offending module with -Og or -O0 (and maybe -g3 to boot!) if needed.
- -- O< ascii ribbon - stop html email! - www.asciiribbon.org