Adrian Cochrane
Recently much of the performance benefits of modern CPUs have instead come from "optimizing compilers" (like GCC, LLVM [in turn rustc, Julia, etc], Glasgow Haskell Compiler, JavascriptCore, Spidermonkey, V8, JVMs, etc) emitting code better suited for them. Addressed by numerous optimization passes.
At which point compilers have an interesting tradeoff: Do we make our own software faster or the software we're compiling? JITs have this worse!
So what sort of code does modern hardware like?
1/6?
Adrian Cochrane
CPUs like straightline code without branches! They make prefetching the next batch of instructions. They dislike conditional branches which they have to predict! They really dislike dynamic branches (function pointers, methods; caveats), but that needs a JIT.
In some cases this goes hand-in-hand with concision (e.g. collapsing chained GOTOs arising from lowering controlflow), other times not so much. So there's an analysis pass deciding where to optimize for concision vs minimal controlflow.
3/
Adrian Cochrane
Modern CPUs love small software! It fits better in its instruction caches! Perhaps an optimizing compilers main job is to rewrite your code to be more concise without unused code, duplicate code, computations which could be performed at compiletime, etc.
Vector instructions can help with this!
Sure you could argue that this is poor code quality the compiler is cleaning up, but thanks to lowering (split into several passes) & other optimizations it sneaks into even the cleanest of code.
2/6?
MarkusL
@alcinnz Another way to look at that is that compilers should minimise the abstraction penalty. If you write beautiful clean code with everything broken down into small functions and classes, the compiler's job is to ensure that you don't pay for your clean code in poor performance.
Adrian Cochrane
Then there's CPU registers! Even if stackmachines look more elegant to me...
RAM is relatively-extremely slow so optimizing compilers try to keep all the data they can in CPU registers. At which point a late lowering pass needs to decide which CPU registers those corresponds to.
Which is roughly equivalent to The Map Colouring Problem, meaning there's no good way to compute it. We have to rely on hueristics & fallbacks to stack.
As always lowering yields messiness to cleanup.
6/6 Fin!
Adrian Cochrane
Branch density is especially within loops, then again (especially if the optimizing if the optimizing compiler has anything to say about) loops make branch prediction easier! They can even make dynamic branches easier to predict!
So GCC at least has a whole suite of optimization passes dedicated to shrinking loopbody sizes & minimizing loop iterations (again vector instructions are very handy here), especially for inner loops.
Replacing finite loops with duplicate straightline code helps.
4/6
Adrian Cochrane
What else?
Inlining functions is a tricky balance to get right. Can reveal more optimizations & can save minuscule branching cost if its not overwhelmed by the harm it does to concision.
Some instructions (e.g. multiplication, divide) take longer to evaluate than others (e.g. add, subtract, shift), so there's "peephole" optimizers handling that.
Ordering code so related branches (with preference given to probable paths) are near each other helps the instruction cache.
5/6
Chirp! is a social network. It runs on GNU social, version 2.0.1-beta0, available under the GNU Affero General Public License.
All Chirp! content and data are available under the Creative Commons Attribution 3.0 license.