OpenSUSE Enables LTO By Default For Tumbleweed - Smaller & Faster Binaries

[hubicka]

A before and after test should show what difference LTO makes regardless of which desktop in installed.

We plan to get into some benchmarking next week (this needs to build the distro twice once with LTO and once without so other changes are not affecting the results).

Before and after tumbleweed update I did very quick testing on my notebook.
/usr/bin shrank from 1335840 to 1239812 (7.7%) which is in match of our expectations. Note that some binaries was LTO optimized before as well.
I did not measure noticeable difference in boot time. However gcc configure script seems to run reproducibly 13-18% faster which suggests that overall system performance is improved.

Memory use after boot into plasma desktop seems also slightly better. Used memory changed 1189460->1159204. I was bit worried about this since code layout with LTO needs work.

Note that enabling LTO is one step. Things will need to be re-optimized for such intrusive change and also GCC -O2 has room for improvements especially with -flto. This is what I work on for GCC 10.

[carewolf]

Or maybe someone could fix the package.

LTO on GCC and CLang is good enough these days that when I look into LTO build failures, it's almost always a dodgy piece of code doing some trick it shouldn't be doing.

Well, there are things that LTO breaks, and the breakage can be at runtime and not at build time It needs disabling here and there. But yes, most places are coding mistakes, but I can't blame distros for not wanting to clean up all OSS source code everywhere..

[sb56637]

Thanks Michael, really looking forward the comparison tests with this.

[starshipeleven]

I'd like to see a build infrastructure that automatically detects whether or not it makes sense or not to statically link a given library into a given object, and which updates the dependent package with the dependency in a mostly-automatic fashion.

I'm curious, when would "make sense" to statically link a lib in an object?

[Awesomeness]

Or maybe someone could fix the package.

You would have to talk to the upstreams about that. Not every packager is capable of programming and distributions should keep downstream patches to the minimum anyway.

[microcode]

I'm curious, when would "make sense" to statically link a lib in an object?

When the likely I$ impact on a running system is lower, or some serious cross-object inlining benefits the performance in some measurable way.

For example, you use a single function from some library, and maybe the compiler specializes or autovectorizes it in context.

Not sure how much tooling would be required to make these distinctions, but it's a thought.