Announcement

Collapse
No announcement yet.

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

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

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

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

    The past few months openSUSE developers have been working on enabling LTO by default for its packages while now finally with the newest release of the rolling-release openSUSE Tumbleweed this goal has been accomplished...

    http://www.phoronix.com/scan.php?pag...Tumbleweed-LTO

  • microcode
    replied
    Originally posted by starshipeleven View Post
    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.

    Leave a comment:


  • Awesomeness
    replied
    Originally posted by Zan Lynx View Post
    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.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by microcode View Post
    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?

    Leave a comment:


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

    Leave a comment:


  • carewolf
    replied
    Originally posted by Zan Lynx View Post

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

    Leave a comment:


  • hubicka
    replied
    Originally posted by Templar82 View Post
    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.

    Leave a comment:


  • Templar82
    replied
    Originally posted by andyprough View Post
    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.

    Leave a comment:


  • microcode
    replied
    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.

    Leave a comment:


  • nuetzel
    replied
    Originally posted by bug77 View Post
    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...

    Leave a comment:

Working...
X