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

[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.

[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.

[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?

[sb56637]

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

[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..

[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.

[Templar82]

Slow btrfs file system, slow kde plus balloo full disk indexing in the background, CPU governor set to powersave mode, CPU mitigations set to super paranoid level. And I might have missed a few. Not going to be able to tell a thing about LTO with opensuse defaults in place.

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

[microcode]

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.

[nuetzel]

Ah, that's why I got a massive 2,200+ packages update today. Only freed up 110MB or so of disk space though; that's like 50kB/package on average. Still, removing DE AD C0 DE is always a plus.

Here it was ~5385 last night...

[Linuxhippy]

Wow this is really great news - finally a mainstream distribution is used the advanced optimizations modern compilers can offer these days.

This has been really long overdue, most major distributions still compiler everyting with "-O2" - leaving all those inter-file-optimizations unused.
I really hope RedHat and others will follow soon...