Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
LTO: We are almost there
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5, 6  Next  
Reply to topic    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message
CaptainBlood
l33t
l33t


Joined: 24 Jan 2010
Posts: 821

PostPosted: Tue Jan 03, 2017 2:59 pm    Post subject: Re: LTO: We are almost there Reply with quote

costel78 wrote:
Libreoffice is ready to be compiled with lto, it is not enabled in ebuild. All is needed is to append --enable-lto to configure:
Code:
--- libreoffice-5.2.2.2.ebuild   2016-10-09 21:00:04.140865463 +0300
+++ libreoffice-5.2.2.2-r1.ebuild   2016-10-09 20:59:21.324450098 +0300
@@ -78,7 +78,7 @@
 LO_EXTS="nlpsolver scripting-beanshell scripting-javascript wiki-publisher"
 
 IUSE="bluetooth +branding coinmp collada +cups dbus debug eds firebird gltf gnome googledrive
-gstreamer +gtk gtk3 jemalloc kde libressl mysql odk pdfimport postgres quickstarter telepathy test vlc
+gstreamer +gtk gtk3 jemalloc kde libressl +lto mysql odk pdfimport postgres quickstarter telepathy test vlc
 $(printf 'libreoffice_extensions_%s ' ${LO_EXTS})"
 
 LICENSE="|| ( LGPL-3 MPL-1.1 )"
@@ -404,6 +404,7 @@
    #   not linked or anything else, worthless to depend on
    econf \
       --docdir="${EPREFIX}/usr/share/doc/${PF}/" \
+      $(use_enable lto) \
       --with-system-dicts \
       --with-system-headers \
       --with-system-jars \

is what I tried for 5.2.3.3-r1 which triggered a request for doxygen :oops:
The ebuild patch iŝ so straight forward I don't know what to do...
Code:
diff libreoffice-5.2.3.3-r1.ebuild libreoffice-5.2.3.3-r2.ebuild
81c81
< gstreamer +gtk gtk3 jemalloc kde libressl mysql odk pdfimport postgres quickstarter telepathy test vlc
---
> gstreamer +gtk gtk3 jemalloc kde libressl +lto mysql odk pdfimport postgres quickstarter telepathy test vlc
427a428
>       $(use_enable lto) \
Any idea?

Thanks 4 ur attention, interest & support.
Back to top
View user's profile Send private message
Child_of_Sun_24
Guru
Guru


Joined: 28 Jul 2004
Posts: 410

PostPosted: Tue Jan 03, 2017 3:59 pm    Post subject: Re: LTO: We are almost there Reply with quote

CaptainBlood wrote:
costel78 wrote:
Libreoffice is ready to be compiled with lto, it is not enabled in ebuild. All is needed is to append --enable-lto to configure:
Code:
--- libreoffice-5.2.2.2.ebuild   2016-10-09 21:00:04.140865463 +0300
+++ libreoffice-5.2.2.2-r1.ebuild   2016-10-09 20:59:21.324450098 +0300
@@ -78,7 +78,7 @@
 LO_EXTS="nlpsolver scripting-beanshell scripting-javascript wiki-publisher"
 
 IUSE="bluetooth +branding coinmp collada +cups dbus debug eds firebird gltf gnome googledrive
-gstreamer +gtk gtk3 jemalloc kde libressl mysql odk pdfimport postgres quickstarter telepathy test vlc
+gstreamer +gtk gtk3 jemalloc kde libressl +lto mysql odk pdfimport postgres quickstarter telepathy test vlc
 $(printf 'libreoffice_extensions_%s ' ${LO_EXTS})"
 
 LICENSE="|| ( LGPL-3 MPL-1.1 )"
@@ -404,6 +404,7 @@
    #   not linked or anything else, worthless to depend on
    econf \
       --docdir="${EPREFIX}/usr/share/doc/${PF}/" \
+      $(use_enable lto) \
       --with-system-dicts \
       --with-system-headers \
       --with-system-jars \

is what I tried for 5.2.3.3-r1 which triggered a request for doxygen :oops:
The ebuild patch iŝ so straight forward I don't know what to do...
Code:
diff libreoffice-5.2.3.3-r1.ebuild libreoffice-5.2.3.3-r2.ebuild
81c81
< gstreamer +gtk gtk3 jemalloc kde libressl mysql odk pdfimport postgres quickstarter telepathy test vlc
---
> gstreamer +gtk gtk3 jemalloc kde libressl +lto mysql odk pdfimport postgres quickstarter telepathy test vlc
427a428
>       $(use_enable lto) \
Any idea?

Thanks 4 ur attention, interest & support.


If the Patch only add the --enable-lto option you could set it via the EXTRA_ECONF in /etc/portage/env and then enable the use of the configuration in /etc/portage/package.env

For example:
/etc/portage/env/libreoffice.conf:
EXTRA_ECONF="--enable-lto"

/etc/portage/package.env/libreoffice:
app-office/libreoffice libreoffice.conf

Should work with all Versions that support --enable-lto. And you don't need to apply a Patch every time when there is a new version.
Back to top
View user's profile Send private message
saboya
Guru
Guru


Joined: 28 Nov 2006
Posts: 333
Location: Brazil

PostPosted: Tue Jan 03, 2017 6:07 pm    Post subject: Reply with quote

costel78 wrote:
What about system stability ? Impressions, other than long time involved to fix/circumvent all lto errors ?

Everything seems fine. Can't say I noticed any improvements, but it seems as stable as ever.

FYI, bumped into 2 more regressions:

1 - 4.9 kernel does not build with gold anymore - https://bugs.gentoo.org/show_bug.cgi?id=602532

Had to backport a fix to binutils to make it compile again.

2 - Samba does not build with gold - https://bugs.gentoo.org/show_bug.cgi?id=600788

This one really got me. When it first failed I thought it was because of lto, so I put no-lto in package.env and tried again. Then I found out it was because of gold, and simply added linker-bfd. It failed even earlier (in configure) with this:
Code:
Checking for custom code                                                          : Could not find the python development headers


Then I removed no-lto (leaving only linker-bfd) and it worked. Don't know what's going on here.
Back to top
View user's profile Send private message
costel78
Guru
Guru


Joined: 20 Apr 2007
Posts: 305

PostPosted: Tue Jan 03, 2017 7:16 pm    Post subject: Reply with quote

@mv Until gcc-config will behave proper I put in my /etc/portage/bashrc a BIG warning everytime sys-devel/gcc is emergeged, uninstalled or so. Also
Code:
find / -not -path "/mnt/*" -not -path "/sys/*" -not -path "/proc/*" -not -path "/dev/*" -not -path "/run/*" -type l ! -exec test -r {} \; -delete -print
is run on my update script and result is mail to me.
Quite rudimentary, but...

@CaptainBlood Maybe enable-lto got misplaced in 5.2.3.3-r1. I am on 5.2.4.2 and doxygen is not installed in my system. Child_of_Sun_24 suggestion is exactly what I've done to get rid of libreoffice ebuild need in local overlay. It is frustratting to remember in the middle of the long emerge "Oh! I forgot about lto..."

Code:
Filename: /etc/portage/env/app-office/libreoffice with the following content:
EXTRA_ECONF="--enable-lto"


@saboya
I am not using gold. I tried it multiple times and found to be unreliable for system-wide. Put it in the "box" with icc, llvm. Maybe in the future things will go better.

As altblitz mentioned two pages ago, chromium is compiling with lto using --param lto-partitions=1, but with the cost of compile time increase:
Code:
genlop -t chromium
 * www-client/chromium

     Mon Dec 26 21:28:48 2016 >>> www-client/chromium-56.0.2924.21
       merge time: 1 hour, 13 minutes and 39 seconds.

     Wed Dec 28 13:43:34 2016 >>> www-client/chromium-56.0.2924.21
       merge time: 1 hour, 18 minutes and 35 seconds.

     Thu Dec 29 23:50:30 2016 >>> www-client/chromium-57.0.2950.4
       merge time: 1 hour, 49 minutes and 49 seconds.

_________________
Sorry for my English. I'm still learning this language.
Back to top
View user's profile Send private message
NTU
Tux's lil' helper
Tux's lil' helper


Joined: 17 Jul 2015
Posts: 126

PostPosted: Wed Jan 04, 2017 5:03 pm    Post subject: Reply with quote

System wide instability with Gold? I've been using it for a year or so now with no issues except compiling problems. You're getting runtime problems with Gold? What kinds???

As for LTO kernel development, I'm in the middle of moving right now, there's a lot of kernel development I've been meaning to catch up on, backporting all the latest and greatest security features of 4.8 and 4.9 - vmapped stacks, hardened usercopy, etc etc. also splitting up the Grsecurity patch into separate files for easier maintainability and dissecting the enormous patch blob, might even try and join the KSPP team, kernel self protection project (if they aren't too crazy)

People have been asking about a secure kernel that you don't need to constantly update or switch releases, so with a barrage of backport patches, people can have all the same security features of 4.9 to older kernels, they'll be hosted here (empty tree right now, haven't worked on it yet)

https://github.com/NTULINUX/kernel-patches/tree/master/backports

There's a lot to do, I've just been busy so I haven't had the time. LTO (fun project) and security patches (real project) are both a priority for me right now, might be a few more weeks until I get around to it. Don't worry!

Cheers guys, and thanks for testing out that script. Please star the project if you can, it will feature a chroot/linux filesystem builder as well, also written entirely in bash, practically LFS in a script, and btw, all the LFS docs in regards to building a toolchain couldn't be further from the truth.

1.) GCC does not support newlib, I was wondering why it wasn't building, GCC bug report I filed confirmed this.

2.) GMP, MPC, and MPFR are not extracted in the GCC builds in the LFS docs, so you get decimal float errors (IIRC)

3.) LFS does not install GLIBC headers before GCC, so GCC does not build

4.) Configure lines are all goofy

5.) Unncessesary modifications to source trees

Tons and tons of issues I can't even remember them all with LFS, but it's a complete mess so I'm basically re-doing LFS entirely and converting it all in a script because those guys can't build a Linux system to save their life, the order is all goofed up on the build process and countless steps are missing. The crosstool-ng tree is in much better shape.

Cheers mates!
Back to top
View user's profile Send private message
Jaglover
Watchman
Watchman


Joined: 29 May 2005
Posts: 5958
Location: Saint Amant, Acadiana

PostPosted: Wed Jan 04, 2017 5:11 pm    Post subject: Reply with quote

FWIW I just noticed gcc-6.3.0 with gold linker produces an error in kernel compiling. Just happened to look at the screen when I saw it, compiling didn't stop. Not good.
_________________
Please learn how to denote units correctly!

Political Correctness is all about replacing imaginary injustice with real injustice.
Back to top
View user's profile Send private message
saboya
Guru
Guru


Joined: 28 Nov 2006
Posts: 333
Location: Brazil

PostPosted: Wed Jan 04, 2017 6:15 pm    Post subject: Reply with quote

Jaglover wrote:
FWIW I just noticed gcc-6.3.0 with gold linker produces an error in kernel compiling. Just happened to look at the screen when I saw it, compiling didn't stop. Not good.

It's a binutils issue. I mentioned it in my last post. It's already fixed upstream, I backported the patch and it compiles fine. More info: https://bugs.gentoo.org/show_bug.cgi?id=602532
Back to top
View user's profile Send private message
NTU
Tux's lil' helper
Tux's lil' helper


Joined: 17 Jul 2015
Posts: 126

PostPosted: Wed Jan 04, 2017 6:44 pm    Post subject: Reply with quote

Jaglover, if you compile with multiple jobs, the compilation won't stop as soon as there's an error until the other jobs are complete. OT: XJ220 FTW!
Back to top
View user's profile Send private message
Child_of_Sun_24
Guru
Guru


Joined: 28 Jul 2004
Posts: 410

PostPosted: Wed Jan 04, 2017 6:59 pm    Post subject: Reply with quote

[quote="saboya"]
costel78 wrote:

1 - 4.9 kernel does not build with gold anymore - https://bugs.gentoo.org/show_bug.cgi?id=602532

Had to backport a fix to binutils to make it compile again.


The Problem is known in the Kernel Bug Tracker, since 4.9-rc1.

Here is the Thread:
https://bugzilla.kernel.org/show_bug.cgi?id=177741

And this is the Fix (Kernel Patch):
https://bugzilla.kernel.org/attachment.cgi?id=246881

Worked fine for me.
Back to top
View user's profile Send private message
saboya
Guru
Guru


Joined: 28 Nov 2006
Posts: 333
Location: Brazil

PostPosted: Wed Jan 04, 2017 10:59 pm    Post subject: Reply with quote

Child_of_Sun_24 wrote:
The Problem is known in the Kernel Bug Tracker, since 4.9-rc1.

Here is the Thread:
https://bugzilla.kernel.org/show_bug.cgi?id=177741

And this is the Fix (Kernel Patch):
https://bugzilla.kernel.org/attachment.cgi?id=246881

Worked fine for me.

I'm not a linker specialist, much less kernel specialist, so I couldn't argue with you if this is a binutils or kernel bug. But justbecause it can be worked around in either means the problem is in the other end.

Since the patch I mentioned already made it into upstream, I would guess they realize it's incorrect nad have to fix it anyway.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 5750

PostPosted: Thu Jan 05, 2017 4:33 pm    Post subject: Reply with quote

After the hint of costel78, I made the symlink and re-emerged world on amd64 and x86

There is a corresponding new version of the flto failure list

Result:

Several packages succeeded which failed previously, most remarkably most qt packages (though not all).

On the other hand, the link caused additional failures: Packages failing with
Quote:
libtool: eval: line ...: syntax error near unexpected token `|'

(those marked in the list with "|") could previously usually be fixed with -ffat-lto-objects; now they always require to switch off -flto completely. Some other packages even exhibit this or other errors now even though they work without the symlink.

Some runtime errors have vanished due to the symlink. For instance, qpdfview now runs fine instead of complaining about nonreadable plugins.

On the other hand, serious runtime errors and stability issues remain or are new:

app-arch/bzip2 fails completely at runtime.
app-shells/zsh has unreproducible problems (it can compile broken .zwc files or fail to parse the command line). This did not occur without the symlink.
media-libs/mesa seems to cause firefox crashes, though this is not very reproducible and might be a strange accident.
Certainly there are more issues which I just have not found yet.

Statistics:

Not counting the packages which break only with -fwhole-program (which unsurprisingly is overly aggressive) and those which have not been emerged recently (marked in the list with "PO"), there are about

130 packages failing on x86
95 packages failing on amd64

out of a total of ~1400. If one takes into account only packages which actually compile code (excluding e.g. virtuals/* and packages which install only script, text, or data files), I would guess that about 20% of these packages fail.

The main causes for build failures are:

20%: The "|" message of libtool mentioned above
15%: Reallocations in readonly sections (usually only on amd64, though sometimes also on x86)
35%: /usr/include/bits/stdio2.h:97:10: internal compiler error - this happens only on x86
Remainder: Symbols not found, strange errors (other internal compiler errors or reallocation problems), build system issues (e.g. configure failing to determine the endianness with -flto), runtime errors.
Back to top
View user's profile Send private message
Child_of_Sun_24
Guru
Guru


Joined: 28 Jul 2004
Posts: 410

PostPosted: Thu Jan 05, 2017 5:09 pm    Post subject: Reply with quote

saboya wrote:
Child_of_Sun_24 wrote:
The Problem is known in the Kernel Bug Tracker, since 4.9-rc1.

Here is the Thread:
https://bugzilla.kernel.org/show_bug.cgi?id=177741

And this is the Fix (Kernel Patch):
https://bugzilla.kernel.org/attachment.cgi?id=246881

Worked fine for me.

I'm not a linker specialist, much less kernel specialist, so I couldn't argue with you if this is a binutils or kernel bug. But justbecause it can be worked around in either means the problem is in the other end.

Since the patch I mentioned already made it into upstream, I would guess they realize it's incorrect nad have to fix it anyway.


When i read the Bugtracker Thread it looks like that it is a binutils problem, i am not an expert, too (Posted it only because not everyone is able to backport a fix for binutils) :-)
Back to top
View user's profile Send private message
costel78
Guru
Guru


Joined: 20 Apr 2007
Posts: 305

PostPosted: Thu Jan 05, 2017 7:29 pm    Post subject: Reply with quote

@NTU I will give another chance to Google Linker. I enable it on chromium compilation (via -fuse-ld=gold) but I haven't seen any improvements. Of course it could be due to lto-partition=1. When I'll have time will try with libreoffice. If it link/compile faster I'll try a world recompile with gold.
Of course, any work on kernel security or lto if always appreciated.
One more question: what exactly happened between gcc 5 and 6 regarding Gentoo old hardened patches ? Were they accepted upstream ? Where did they disappear ?

@mv First, great statistic (and effort).
Are you using a hardened profile ? That's the only profile where I got numerous runtime errors with lto. I should specify earlier that I am using default/linux/amd64/13.0/no-multilib profile. gnome-shell is the only package that exhibit runtime errors.
I was looking at yours flto failure list. As far as I understand both -flto and -fwhole-program don't work very well together and that combination is discouraged.

The reason I asked then and now about impressions and stability is no matter what benefits any compilation compilation flag may bring, stability is sacred, so please notify us there of such cases.
_________________
Sorry for my English. I'm still learning this language.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 5750

PostPosted: Thu Jan 05, 2017 8:14 pm    Post subject: Reply with quote

costel78 wrote:
Are you using a hardened profile? That's the only profile where I got numerous runtime errors with lto.

I am using the hardened kernel (and some hardening *FLAGS), but not by profile. However, most runtime errors I experienced were not triggered by a kernel exception (which would happen if it is a problem of reallocating in a readonly section), so I doubt that this is special to hardened.
However, as far as I can judge the list includes all packages which exhibit runtime problems; so far, my system appears to be stable with that list.
Quote:
As far as I understand both -flto and -fwhole-program don't work very well together and that combination is discouraged.

No, quite the opposite: Originally - when flto was first introduced - the intention was to use -flto and -fwhole-program together for the final linking. However, one had to be careful to specify -fwhole-program only for the linking phase but not for the compiling phase. Since this turned out difficult in practice, it was decided to ignore -fwhole-program for the compiling phase. So it is now safe to use it in both phases and indeed recommended for -flto unless memory or compile time restrictions speak against it.
The only thing one has to take care of is that it should of course only be used for linking the program but not for linking a library (because it might optimize needed symbols away). Therefore, I globally disable it for all packages matching *-lib/* and similar wiildcards where it will certainly be wrong to use it: It is wrong for every package which installs *.so* files.
Back to top
View user's profile Send private message
NTU
Tux's lil' helper
Tux's lil' helper


Joined: 17 Jul 2015
Posts: 126

PostPosted: Fri Jan 06, 2017 2:24 am    Post subject: Reply with quote

Yeah I'd definitely give it another go, Gold is stable as all hell for me, my only issues with compiler flags has been forcing fPIE in CFLAGS and CXXFLAGS and -pie in LDFLAGS, I went through all the packages though and only about 20 or 30 of them didn't build with fPIE+pie out of about 1100 installed. Setting fstack-protector-all had no issues what so ever. I have noticed though that the certain packages that didnt build with fPIE and -pie explicility specified in make.conf actually were position independent executables in Debian, I have to figure out how they did that and were able to build with pie when I couldn't.

Like double cherry -fPIE yeah there she was. (lul)

Sent from my Droid 4 XT894. iPhones suck.
Back to top
View user's profile Send private message
costel78
Guru
Guru


Joined: 20 Apr 2007
Posts: 305

PostPosted: Sun Jan 08, 2017 4:54 pm    Post subject: Reply with quote

I did a full recompile of my system with gold. No stability problems, so far.
Aside fpc and lazarus which does not accept gold, only gettext and kernel failed with gold.
There were a few others problems related to the new gperf-3.1, well systemd error scare me a bit until the real cause was elucidated.

What I observed doing comparatives genlop -t, or better said, what I did not observed, is the speed gain of ld.gold. Did bfd catch up in the mean time ?
_________________
Sorry for my English. I'm still learning this language.
Back to top
View user's profile Send private message
saboya
Guru
Guru


Joined: 28 Nov 2006
Posts: 333
Location: Brazil

PostPosted: Sun Jan 08, 2017 4:57 pm    Post subject: Reply with quote

costel78 wrote:
I did a full recompile of my system with gold. No stability problems, so far.
Aside fpc and lazarus which does not accept gold, only gettext and kernel failed with gold.
There were a few others problems related to the new gperf-3.1, well systemd error scare me a bit until the real cause was elucidated.

What I observed doing comparatives genlop -t, or better said, what I did not observed, is the speed gain of ld.gold. Did bfd catch up in the mean time ?

LTO might play a factor in evening things out.
Back to top
View user's profile Send private message
costel78
Guru
Guru


Joined: 20 Apr 2007
Posts: 305

PostPosted: Sun Jan 08, 2017 5:32 pm    Post subject: Reply with quote

If that's the case it mean there are no real advantages using ld.gold with lto.
_________________
Sorry for my English. I'm still learning this language.
Back to top
View user's profile Send private message
NTU
Tux's lil' helper
Tux's lil' helper


Joined: 17 Jul 2015
Posts: 126

PostPosted: Tue Jan 10, 2017 3:50 am    Post subject: Reply with quote

costel78 wrote:
If that's the case it mean there are no real advantages using ld.gold with lto.


Hey don't talk bad about gold like that :P

Nah, Gold actually helps out LTO a bit, mainly with -fuse-linker-plugin and other friends enabled, they go hand in hand my friend. No gold, no LTO, that's how I roill, but I dropped bfd regardless if I'm using LTO or not. Gold all the way, EEEEEYAOOOO! Finally finished moving by the way, I should be returning to kernel hacking shortly.

Also, if you're running into issues compiling the kernel with the default linker set to Gold, you need to update your kernel.

Best regards!

NTU (aka NUT, lul)
Back to top
View user's profile Send private message
trubicoid
n00b
n00b


Joined: 04 Aug 2009
Posts: 44

PostPosted: Thu Jan 19, 2017 1:13 pm    Post subject: Reply with quote

costel78 wrote:
If that's the case it mean there are no real advantages using ld.gold with lto.


there is an advantage of ld.gold over ld.bfd, the binaries are smaller, with or without lto:

Code:
ls -l /bin/gzip
ld.bfd  without -flto 98064
ld.bfd     with -flto 89776
ld.gold without -flto 96000
ld.gold    with -flto 87768
Back to top
View user's profile Send private message
CaptainBlood
l33t
l33t


Joined: 24 Jan 2010
Posts: 821

PostPosted: Fri Jan 20, 2017 8:40 am    Post subject: Reply with quote

ls -la /bin/gzip
-rwxr-xr-x 1 root root 85752 10 janv. 18:56 /bin/gzip

gcc-5.4 + ld.gold / fat-lto, openmp & graphite!!!

for
Code:
app-arch/gzip-1.8:
 U I
 - - pic
 - - static
Back to top
View user's profile Send private message
trubicoid
n00b
n00b


Joined: 04 Aug 2009
Posts: 44

PostPosted: Fri Jan 20, 2017 10:23 pm    Post subject: Reply with quote

to see the difference, you need to try linkers and lto by yourself

I have gcc 4.9.4 and -march=native, which makes the reproduction of exactly the same numbers difficult
Back to top
View user's profile Send private message
CaptainBlood
l33t
l33t


Joined: 24 Jan 2010
Posts: 821

PostPosted: Sat Jan 21, 2017 2:31 pm    Post subject: Reply with quote

CaptainBlood wrote:
ls -la /bin/gzip
-rwxr-xr-x 1 root root 85752 10 janv. 18:56 /bin/gzip

gcc-5.4 + ld.gold / fat-lto, openmp & graphite!!!

for
Code:
app-arch/gzip-1.8:
 U I
 - - pic
 - - static

My bad!!! forgot to mention :/usr/x86_64-pc-linux-gnu/binutils-bin/2.27/
stack protection set to off.

whereas equivalent bfd leads to:
Code:
ls -la /bin/gzip
-rwxr-xr-x 1 root root 85624 21 janv. 16:56 /bin/gzip


so bfd is slightly smaller than gold, in this case.

Thks 4 ur attention, interest & support.
Back to top
View user's profile Send private message
IvanMajhen
Guru
Guru


Joined: 10 Jun 2006
Posts: 392
Location: Croatia

PostPosted: Wed Jan 25, 2017 11:04 pm    Post subject: Re: LTO: We are almost there Reply with quote

altblitz wrote:
Blitz did it. Yet again.
Firefox 50.1 with -O3 LTO PGO march=native
and Chromium LTO PGO.

From the benchmarks, Firefox is only ~20% lower than Chromium.

All in all - Blitz have the most speedy browser on the Earth now.
Privacy and security patches applied.


How did you configured PGO for chromium?
Back to top
View user's profile Send private message
costel78
Guru
Guru


Joined: 20 Apr 2007
Posts: 305

PostPosted: Fri Jan 27, 2017 8:45 pm    Post subject: Reply with quote

Ok, ok, I surrender. There is, at least, the benefit of size when using gold, with or without lto. Nice catch.
Regarding binaries sizes I was impressed by musl. Too bad it does not support all usual desktop packages and it is a bit slow than glibc.
I do not know... first was icc, and, in time gcc surpass it (except when using their math libs), then llvm which now is on pair with gcc and slower during compile time (sic). Maybe is time to not believe in every wheel reinvent.

For compile chromium, or anything else, with pgo there is one method: https://forums.gentoo.org/viewtopic-t-938468.html.
_________________
Sorry for my English. I'm still learning this language.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Unsupported Software All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6  Next
Page 4 of 6

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum