> Make it work, then make it right, then make it fast.
Applies to core language choice, I used to hear a lot about rewriting interpreted langs to something faster... but the reality is that a team that's just spent 1 year making an app in python aren't going to pivot to writing Java, Go, or Rust one day. The new team isn't going to be building something new and exciting, they are going to be on a tight timeline to deliver a port of something which already exists.
I have found that his advice on using profilers was very important. I thought I knew where it would be slow, but the profiler usually stuck its tongue out at me and laughed.
When I ran a C++ shop, optimization was a black art. Things like keeping code and pipelines in low-level caches could have 100X impact on performance, so we would do things like optimize to avoid breaking cache. This often resulted in things like copying and pasting lines of code to run sequentially, instead of in a loop, or as a subroutine/method.
It's difficult. There's usually some "low-hanging fruit" that will give awesome speedups, then, it gets difficult.
This is why it is frequently helpful to look at the code generated by the C++ compiler. It gives you insight into the kinds of optimizations the compiler can see and which ones it can't, so you can focus on the ones it struggles with. This knowledge becomes out-of-date on the scale of years, so I periodically re-check what I think I know about what the compiler can optimize.
For some things, like vectorization, the compiler's optimizer almost never produces a good result for non-trivial code and you'll have to do it yourself.
[1]: https://stackoverflow.com/questions/375913/how-can-i-profile...
The story I heard, is that the author threw it together to reinforce his side of an argument about code efficiency.
I wonder how Matt Godbolt feels about being used or about being called "it".
Joking of course - it was an odd choice to use $surname.org for one specific tool he built.
Compilers can and do allow themselves license to ignore ABI in some cases; for c and c++, this includes link-time-optimised programs and -fwhole-program &c, as well as straight-up localised transformations on localised data structures (for whatever value of 'local' you prefer). Many other programming languages, in particular including JIT-compiled ones, also do not specify any ABI at all.
Modern C++ in particular encourages the extensive use of expressive compile-time metaprogramming to automate optimization that the compiler cannot. In theory, the heavily optimized data structure and algorithm code that is often generated in C++ could be manually written in C or similar. However, in practice, few software engineers have the patience or time to systematically apply those optimizations manually to everything in their code base. I know for a fact that I didn't when I was writing C.
That modern C++ tends to produce the most highly optimized code is more a matter of economy than theoretical capability.
In Rust you can annotate a function with `#[inline(always)]` which makes is not a suggestion; it'll always inline it AFAIK (unless it calls itself recursively where, by definition, inlining is not possible).
Clang also has a flatten attribute which can be interesting: it does the conjugate of marking functions inline: the function to which it is applied to will have all its own content inlined, e.g. [[clang::flatten]] void f() { a(); b(); }
will inline a and b
Having recently worked on a large C/C++ code base which had a heavy focus on performance observation, I found myself wondering if tricks like dynamic Code Generation to avoid method overhead and unnecessary branch checks actually had a significant benefit on performance relative to the developer economy impact.
We tended to use clang/llvm.
I know that we often had to actively work against the native optimizations.
We had a team from Intel, that used to run these awesome tools on our code, and helped us to see a lot of these weird dichotomies.
Anyone who had the "pleasure" of using Amazon's internal tools can talk about how "Make it work ASAP" attitude has worked out for their internal tooling :) LPT anyone?
It works if you have lots of things communicating over APIs.
You don't actually have to make it fast, but you have to be designing w/ an eye towards eventual speed. Otherwise you end up w/ a mess that can be made faster, but never fast.
At least that's been my experience.