Page MenuHomeSolus
Create Task
Maniphest T8183

Proposal to enable LTO by default for all builds
Closed, WontfixPublic
Actions

Description

I propose that we build all packages with LTO by default which will provide better performance and reduced package size at the cost of slightly longer package build times. The size decrease is not massive, but it will surely make a difference.

Not all packages will build with LTO (for example libwebkit-gtk and for some languages) but it should be a good candidate as a default option. I suggest adding a bool in package.yml for turning off the LTO.

OpenSUSE have recently switched over to building all packages using LTO in Tumbleweed, see here for more info.

Event Timeline

Jacalz renamed this task from Enable LTO by default for all builds to Proposal to enable LTO by default for all builds.Jul 25 2019, 5:54 PM
Jacalz created this task.
Jacalz updated the task description. (Show Details)
DataDrake closed this task as Wontfix.Jul 25 2019, 6:08 PM
DataDrake added subscribers: • sunnyflunk, DataDrake.

No. I will consider adding it as an optimization option in ypkg like we do with PGO, but we will NOT be enabling it by default. LTO has the potential for benefit, but also has been known to degrade performance for certain libraries and applications. Sometimes by orders of magnitude:

https://www.phoronix.com/scan.php?page=article&item=amd-epyc-gcc9&num=1

If we were 100% convinced it was good in most cases @sunnyflunk and I would have enabled it by default ages ago.

Jacalz added a comment.Jul 25 2019, 7:03 PM

Thanks for the inputs. I have had great success in my own LTO compilations form a performance standpoint, but I did not know that it wasn’t that good over all. I really thought that it was a great default option, but I will see about using it and other optimizations more, when necessary instead, when I update packages...

• sunnyflunk added a comment.Jul 26 2019, 1:24 AM

For an LTO build to be better, I would suggest the following criteria:

  1. Doesn't introduce any bugs (quite a few packages have issues with reverse dependencies)
  2. Is not critical to the system without a significant improvement (in filesize or performance) and testing
  3. a) Produces smaller files (more than a fraction) or b) If larger file size, has a metric to prove it improves performance

Increasing file size is always worse if it doesn't lead to improved performance from the files. Improved performance is usually assumed without evidence. If you can explain why it improves performance then make a task/patch with said explanation of the improved metric.

The reality is, most of Linux is built around splitting up files/packages into smaller pieces, which hurts LTO badly.

Copyright © 2015-2021 Solus Project. The Solus logo is Copyright © 2016-2021 Solus Project. All Rights Reserved.