Are you using the lto-overlay yet?
It gives you most oft the benefits of Clear Linux at the cost of longer compile times, right in your favorite distribution. It enables LTO and other costly optimizations by default, with some blacklists for packages that fail to build when it's enabled.
I've been using it for months, no problems. Don't you like being autistically on the edge of what is possible?
Other urls found in this thread:
github.com
github.com
gitgud.io
wiki.gentoo.org
twitter.com
When's he gonna add PGO?
PGO can be enabed on a per-package basis. For exampe, you can enable PGO on gcc, firefox, etc using the "pgo" USE-flag.
This is not enabled by default however, because it makes compiling even slower. I don't care, though, because my OS can multi-task.
If i remember right then pgo for firefox was masked for years. Did they finally fix it?
Not gonna lie, LTO for more performance critical packages would make me use gentoo again. I'm not exactly satisfied with solus/clear linux package management.
Does it work with mesa/radv/x11/glibc? I assume they are the most noticeable ones.
Where is a list of confirmed packages? The repo does not list anything.
You can do PGO with (more or less) every program but you'd need to write a script to
>instruct the compiler to build the program to generate profile data
>run automated tests representative of actual real world use
>compile the program again using the profile data
As said this increases compile time. It also breaks reproducible builds.
>If i remember right then pgo for firefox was masked for years. Did they finally fix it?
Firefox for Windows, Mac, Linux (again PGO breaks reproducibility so binary distros might not use PGO but the Linux binary distributed by Mozilla does) and Android is built with PGO+LTO.
>Not gonna lie, LTO for more performance critical packages would make me use gentoo again
It's only a few percent extra so don't expect too much.
>Where is a list of confirmed packages? The repo does not list anything.
That would be all packages except the ones for which LTO is disabled.
github.com
Can confirm that LTO works with mesa/glibc/xorg, etc. PGO also works nicely on gcc and firefox at least.
I didn't do any benchmarks, but it should be competitive with Clear Linux since the optimizations are more or less the same. I'm doing it more for fun, so I'm happy anyway.
>Firefox
So it's not in use.mask anymore?
>It's only a few percent extra so don't expect too much.
That's the difference between something usable and not usable on a poc laptop.
>github.com
>no webkit/engine based packages
>no qemu/vbox
>no wine
>no pulseaudio
>no mesa
>no gcc with pgo
>no java
>no ffmpeg
>no php
>no spidermonkey
>no mariadb
Kinda disappointed to be honest. They are the most resource intensive things around and could really benefit from speed improvements.
I guess they are also not build with lto on clear linux so no patch thieving possible.
Did you unmask mesa? clear linux does not build with lto, i wonder why.
see: github.com
Oh man, i can't wait for zen2. Gonna try all this out then.
>So it's not in use.mask anymore?
No, or at least lto-overlay overrides it.
>lots of packages
Some like ffmpeg seem to work with lto, depending on the CFLAGS. I don't use it much, so I didn't test it.
>gcc
Works with lto and pgo, just compiled gcc 8.3 yesterday.
>Did you unmask mesa? clear linux does not build with lto, i wonder why.
Yes, it works fine on my Intel box anyway.
lto-overlay also enables other optimizations, so even without LTO it might be a bit faster than without.
>No, or at least lto-overlay overrides it.
Nice
>Works with lto and pgo, just compiled gcc 8.3 yesterday.
>Yes, it works fine on my Intel box anyway.
I guess things will gradually unmask themselves over the next months. I hope i don't have to maintain too much shit in my unmask files then. eix-test-obsolete is hopefully still around.
>lto-overlay also enables other optimizations, so even without LTO it might be a bit faster than without.
No doubt about that. I just recently jumped on the solus bandwagon and was surprised that gnome based desktops could actually be decently fast and not hinder gaming on my craptop. It was the complete opposite on arch and i still have nightmares from three years ago using gnome with gentoo on my, now defunct, main rig. Dropped frames left and right.
Thanks for bringing that overlay to my attention, pal.
All these optimizations make me want to switch over from Arch to Gentoo
If you wanna switch then compile your gentoo system in qemu+kvm+real disc and just ram that live usb in afterwards and do the boot configuration again in the real system. You can take all the time you want and don't have to half ass shit just to get the system running.
I'm doing all my gentoo installs that way and it really helps not living under pressure.
You can also use virtual discs instead but you will have to mount the images and copy shit over manually in a live env.
Why do that when you can just untar stage3 into some partition and chroot into that?
Placebo tier unless you run it on a distributed system.
Overly complicated. Just run Ubuntu or other live distro off a thumb drive and install while browsing internet
That's why you don't use silly hobbyist overlays. Instead have a local env set up for clang and lld to use thinlto and enabled that on select few packages where you would actually notice the better performance. ffmpeg (and libs it uses) is one of the better examples versus the vanilla gentoo setup of O2/march=native/gcc-8 on my system benchmarks are showing improvements x265 16.8fps->26.5, vpx 2.02fps->2.31fps, ffmpeg h264 decode 1307.3fps->1310.0. All of qt including qtwebengine is buildable with lto as well but you need to rewrite the qt5-build eclass so it actually passes the correct settings, the in tree qtwebengine.ebuild by default if passed lto only builds the outer layer with it but the performance critical chromium inside is left just plain O2 (gentoo qt maintainers have had their thumbs up their arses for a while on this and don't seem to care enough to fix things).
Mesa is not something I have tried yet but it could be that some parts of it work with LTO (like that Intel you have working) and other don't. Cloveros gives us another datapoint and it looks they don't have it enabled either gitgud.io
Because that's not a gentoo install at all. You still have to configure profiles/make.conf/use flags/inits and compile all packages you might want. That can easily take hours/days depending on the system. If you want to profit from OP overlay then you have to do an emerge -e anyway.
Why not do that time consuming boring shit in a vm with the ability to just put it to sleep if something else needs to be done?
It's just plain easier and live systems often don't have the programs you want. Of course if the pc doesn't have anything on it then that is the only way. Also, live systems seem to have lost the ability to install packages. ubuntu 19.04, for example, was plain broken in that regard.
using a vm as a no effort install has zero downtime with no downsides. It's plainly superior to chrooting with a live cd.
So uh, you mean this?
>wiki.gentoo.org
I have personally never used anything else other than default gcc. That's one more thing on the agenda when zen2 comes out.
The qt situation is unfortunate, I noticed that qt+plasma is better supported on gentoo than gtk+gnome so i guessed that they would have their shit together but it seems I am wrong.
Luckily i have some experience writing eclasses so I can hopefully fix that locally. Do you have a bug report handy?
>Because that's not a gentoo install at all.
That's exactly how gentoo installation goes
A gentoo installation is following the handbook. I don't remember that "extract dat stage3 tarball" was the only point on it.
Arrange a partition, extract stage3 tar, chroot and do stuff until you are ready to boot. No need for VM.
Just start qemu and install, no need for downtime.
Don't even install Gentoo. Zero time wasted.
That sounds interesting, but a bit more involved. But comparing it to O2 is a bit unfair as this enables Graphite and other loop optimizations as well. Also, this overlay does everything automatically. And yeah, as I said, I only tried mesa with my Intel setup, on an AMD card it might blow up.
WTF? But why the VM? I could understand if you're running Windows or whatever, but if you're already using Linux a VM is totally unnecessary. If you're on Arch, Debian, whatever, you don't need a VM at all. Technically you don't even need to chroot, just edit the files from your main system and set up the bootloader.
Again: WTF. You can install it however you want if you know what you're doing. It's doubly literally just unpacking the stage3, editing fstab etc. and installing a bootloader. Done.
I hope you're trolling.
>I hope you're trolling.
Why? If you only have one system then the ability to just cleanly pause the vm in the middle of compiling is invaluable.
But you don't need a VM to do that. Just press Ctrl-z. Or Ctrl-c and kill that fucker.
Sure, suspending the VM is nice, because it saves the RAM to disk, but compiling is also going to be slower than chroot.
>Just press Ctrl-z. Or Ctrl-c and kill that fucker.
It's more comfortable and qemu isn't rocket science.
>but compiling is also going to be slower than chroot
Nah, kvm is magic.
Yes, that article explains the concepts.
>Do you have a bug report handy?
There are multiple open bug reports on it not respecting the build settings that all stem from the same issue. The hack I'm using, I'll just post the diff
@@ -499,6 +505,25 @@
# bug 633838
unset QMAKESPEC XQMAKESPEC QMAKEPATH QMAKEFEATURES
+ #gentoo platform file
+ mkdir ${S}/mkspecs/gentoo || die
+ if tc-is-gcc; then cp ${S}/mkspecs/linux-g++/*.h ${S}/mkspecs/gentoo/ ; fi || die
+ if tc-is-clang; then cp ${S}/mkspecs/linux-clang/*.h ${S}/mkspecs/gentoo/ ; fi || die
+ cat
cont. Normally it would pick one of the included mkspecks and if that matches close enough to what we are doing things will work out fine. When playing outside the box generating our own mkspecs was however needed. Few caveats: I've only tested this on clean (see bug 678332) qt5 building all packages with the same settings, this only covered the main issues I had, and as is this code wouldn't work on freebsd/gentoo or crosscompiling (?) or things alike
>But comparing it to O2 is a bit unfair
True if you are interested in which of the toolchains produces fastest binaries, but this was just a simple before/after test I did for myself to see if it was worth the extra compile time. The more sane resource usage of thinlto is what I think makes this approach far more viable
>this enables Graphite
on llvm this class of optimizations are under the polly framework and it looked too WIP last time I checked them out.
>And yeah, as I said, I only tried mesa with my Intel setup, on an AMD card it might blow up.
Tested this with just radeonsi set and it blew up during linking of shared-glapi.