GCC 10's LTO Will Make Use Of Available CPU Cores By Default

[phoronix]

Phoronix: GCC 10's LTO Will Make Use Of Available CPU Cores By Default

Currently when passing "-flto" for enabling Link-Time Optimizations with the GCC compiler, it defaults to using a single core/thread for carrying out the optimizations and code generation. There has been support for specifying a number of threads to use for carrying out this link-time work in parallel while finally in GCC 10 that is being enabled by default...

http://www.phoronix.com/scan.php?page=news_item&px=GCC-10-LTO-flto-Available-Cores

[skeevy420]

I always thought that was an odd default. Glad to see the change.

[bug77]

I always thought that was an odd default. Glad to see the change.

And it is. The only case I'd think to use that is when I'm not sure the multithreaded version works correctly.

[c117152]

I always thought that was an odd default. Glad to see the change.

The linux scheduler tends to let big compile jobs choke everything UI related including local or even remote terminals and tweaking the scheduler kernel flags or prioritizing the ssh server's process sometimes has worse results than just leaving out a thread.

[birdie]

GCC should just respect the (make) -j value however I'm not sure if it's doable - you have to traverse a list of running processes and find your root process along with its arguments.

[tchiwam]

Would be fun to test -j N and force LTO on 1 processor then on N processors.

[jf33]

Is this change about conservative LTO or thin LTO?

[smitty3268]

GCC should just respect the (make) -j value however I'm not sure if it's doable - you have to traverse a list of running processes and find your root process along with its arguments.

make should just define the option for GCC if that's the behavior you want.

[Zan Lynx]

The linux scheduler tends to let big compile jobs choke everything UI related including local or even remote terminals and tweaking the scheduler kernel flags or prioritizing the ssh server's process sometimes has worse results than just leaving out a thread.

Have you been running a systemd based distro like Fedora? The cgroups that systemd does automatically seem to make this not a problem.

I've run a 4 core Dell laptop on Fedora 30 with a KVM-based virtual Windows machine with 8 cores assigned with Visual Studio compiling 16 jobs, and at the same time run Android Studio compiling 8 clang jobs.

Wayland gnome-shell remained responsive. Not perfect by any means, but usable.

[mmstick]

The linux scheduler tends to let big compile jobs choke everything UI related including local or even remote terminals and tweaking the scheduler kernel flags or prioritizing the ssh server's process sometimes has worse results than just leaving out a thread.

The trick is to ensure that your compositor has a realtime priority, and that compile jobs are given a batch job priority. The Linux scheduler is doing its job correctly, your desktop processes just aren't providing the hints it needs to be effective.