3 ms·
If the debug code with no optimisations is the one trusted most, that's what ships. If the optimiser drops off some code as it thinks it has no effect, I'd gue
by jbms 4y ago
If the debug code with no optimisations is the one trusted most, that's what ships.
If the optimiser drops off some code as it thinks it has no effect, I'd guess that's possible to spot, and you'd want to know to either fix the code or remove dead code. I've not personally had to inspect compiler output but I do spend a surprising amount of time in linker map files understanding what's going on.
- wizofaus 4y agoOptimising compilers do a lot more than drop code with no effect (and TBH most decent linter tools will pick that up for you anyway), I've seen them generate machine code that bore virtually no relationship to the C source, with loop unrolling, function call inlining, operation interleaving etc. etc. https://cacm.acm.org/magazines/2020/2/242347-optimizations-in-c-compilers/fulltext https://cacm.acm.org/magazines/2020/2/242347-optimizations-i... has some interesting examples.
- flyingfences 4y agoYup, and that's exactly why we turn the optimizations off and keep them off, even for the shipped release.
- wizofaus 4y agoMakes sense if safety is a priority over performance and/or concerns over reverse engineering.
- jstimpfle 4y agoFor the mostly high-level C code that I write, I find that compiler optimisations give typically give speed-ups in the 1.5x - 3x range. A lot of code is bound by external bottlenecks that would completely mask such a speedup anyway. For really performance-oriented code you probably want to drop to SIMD first, and play with compiler optimisations second.