7 ms·
> execute instructions faster (via -O3) One problem with -O3 is that it disregards any effects of the cache (and yes, ESP32s have a bit of cache memory). I rec
by gsliepen 2mo ago
> execute instructions faster (via -O3)
One problem with -O3 is that it disregards any effects of the cache (and yes, ESP32s have a bit of cache memory). I recommend using -Os as the default optimization level, as it often has the same or almost the same performance benefits as -O3. Less cache pressure is beneficial, especially for bigger applications, and the smaller code size is of course nice on embedded systems that have limited amounts of flash storage. If you know some specific functions or source files are performance sensitive, you can use pragmas to change optimization for those:
#pragma GCC optimize("O3")
See https://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html https://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-.... Clang has a similar pragma, see https://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-selectively-disabling-optimization https://clang.llvm.org/docs/LanguageExtensions.html#extensio....
- secondcoming 2mo agoThis is how all the now defunct Symbian code was compiled.
- deleted 2mo ago[deleted]
- jcalvinowens 2mo agoRemember that -Os is much much more aggressive in GCC than it is in LLVM, with LLVM you need to use -Oz to get the same result. GCC has historically been a bit of a pig about -Os, my favorite example is on x86 where it will emit a runtime divide for a division by a compile time constant power of two because it saves a byte of text! int fn(int n) { return n / 8; } ..becomes: 0000000000000000 <fn>: 0: 89 f8 mov %edi,%eax 2: b9 08 00 00 00 mov $0x8,%ecx 7: 99 cltd 8: f7 f9 idiv %ecx a: c3 ret ..versus: 0000000000000000 <fn>: 0: 8d 47 07 lea 0x7(%rdi),%eax 3: 85 ff test %edi,%edi 5: 0f 49 c7 cmovns %edi,%eax 8: c1 f8 03 sar $0x3,%eax b: c3 ret