If you're working on close to hardware things, make sure you run static analysis, and manually inspect the output of your compiler if you feel something's off - it may be doing something totally different from what you expect, because of optimization and what not. Also, optimizations don't always trigger as expected. Also, sometimes abstractions can cost a fair amount too (C++ std::string c/dtor, for example, dtors in general), more than you'd expect, and in those cases you might want to re-examine your need for them.

Having said all that, also know how to get the compiler to work for you, hand-optimization at the assembly level isn't usually ideal. I've often been surprised by just how well compilers figure out ways to speed up / compactify code, especially when given hints, and it's way better than having a blob of assembly that's totally unmaintainable.

Learnt this from programming MCUs and stuff for hobby/college team/venture, and from messing around with the Haskell compiler and LLVM optimization passes.

  • 0
    Teach me your ways, master.
  • 6
    @ewpratten lol, you probably know more than I do with all your FRC stuff.

    I can recommend spending a lot of time with Compiler Explorer though - it lets you write stuff in many languages and quickly see the disassembled output of the compiler.
  • 1
    @RememberMe that looks cool! Thanks
  • 0
    Compiler Explorer just keeps getting better and better.
Add Comment