Kernel optimization with BOLT (binary optimization and layout tool)
133 points
6 days ago
| 6 comments
| lwn.net
| HN
stephc_int13
3 hours ago
[-]
Instruction Cache and TLB trashing is an often overlooked consequence of code bloat and sometimes of overly aggressive micro-benchmark driven optimization.

Reorganizing the binary is an interesting approach to minimize the cost, but I think that any performance oriented developer should keep in mind that most projects are rarely dependent on a single hot loop but on many systems working together and competing for space in the cache(s).

I generally use -Os instead of -O2 and -O3 in my projects, while trying to reduce code bloat to a minimum for that reason.

reply
JoelJacobson
9 hours ago
[-]
Here is another interesting BOLT article, this one on PostgreSQL optimization:

https://vondra.me/posts/playing-with-bolt-and-postgres/

"results are unexpectedly good, in some cases up to 40%"

reply
pfdietz
8 hours ago
[-]
That's amazing.
reply
BSDobelix
12 hours ago
[-]
One can try it out with CachyOS/Arch:

https://cachyos.org/blog/2411-kernel-autofdo/

reply
ndesaulniers
4 hours ago
[-]
Note: that's autoFDO+propeller. This article is about BOLT.
reply
knowitnone
8 hours ago
[-]
wanted to see what CachyOS is about. https://www.phoronix.com/review/cachyos-linux-perf/5 it came second place to ClearLinux which is not bad.
reply
OnlyMortal
7 hours ago
[-]
Back in the day on the Mac, the order of source files in your project would determine locality in the binary.

If memory serves, this was with MPW C or maybe CodeWarrior.

You could see the jump (jmp) instructions use short jumps rather than long ones.

reply
rurban
6 hours ago
[-]
This is still relevant. I had big success in writing an order optimizer for perl5
reply
fsflyer
5 hours ago
[-]
The Metrowerks profiler and linker worked together to optimize locality in the binary, the focus was on PowerPC code. The linker could generate the static call tree, but the profiler could generate a dynamic call tree of what was actually called. Separating out the cold portions of the call tree into portions of the executable that didn't get paged in was the goal.

I worked on the Profiler and I seem to remember that Microsoft was one of the developers that put a bunch of effort into using this to optimize the Office suite on Mac. I remember the release of Word that used it was snappier.

reply
Iwan-Zotow
30 minutes ago
[-]
same in MS DOS

you have far and near pointers modifiers

reply
kardos
10 hours ago
[-]
Does it work with Intel fortran-compiled code?
reply
kijiki
6 hours ago
[-]
As long as you relink with relocations preserved in the final ELF binary, it should.
reply
kardos
1 hour ago
[-]
Thank you!
reply
vsskanth
8 hours ago
[-]
Anyone know of a windows equivalent to BOLT ?
reply
neerajsi
53 minutes ago
[-]
Microsoft had internal tooling very similar to bolt almost 20 years ago. Most of those opts were moved to the compiler in ltcg mode with pgo.
reply
Cieric
4 hours ago
[-]
Some google searching brought up this. https://learn.microsoft.com/en-us/cpp/build/profile-guided-o... I'm only reading over it now, but I'm going to test it out a bit when I can.
reply
dwattttt
2 hours ago
[-]
PGO describes the using extra data to guide optimisations, but it doesn't define what those optimisations are.

Reading the link, there's several that sound like they match what BOLT is applying (Basic Block Optimization, Function Layout, Conditional Branch Optimization, and Dead Code Separation).

reply