[lfs-dev] Two changes to consider for 8.0
dj at linuxfromscratch.org
Sat Dec 31 02:55:47 PST 2016
On 12/30/2016 09:01 PM, Bruce Dubbs wrote:
> I don't have a problem with adding gold as you propose, but I do wonder
> what the benefits are for using it. As best I can tell, it would only
> be useful in speeding up the link phase for some large projects. Is
> that right?
> If so, what are some performance improvements we can expect to see?
Correct. Ken, might be able to provide some insight as to differences.
As I go through this build, I plan to do some 1:1 comparisons for larger
packages to see how much of difference to expect. Off the cuff, I see
Firefox, Chromium, Webkit, and KF5 as targets for potential "wow"
numbers. The results, however, are not relevant to the question of
whether to include it IMO.
This one comes down to which is more costly, an extra build of bison in
chapter 5 and additional time and build size -- which are not
insignificant numbers -- or adding binutils to BLFS to complete the
binutils installation if gold is desired. I'm also kind of waiting for
2.28 so we can avoid covering the broken tests and likely reduce some of
that time. It needs to be tested in real use with BLFS to make sure
nothing breaks in the default configuration, so I'm getting the ball
rolling again now while I'm doing a complete rebuild anyway, and we are
not yet preparing for release.
> As far as ISL goes, what apps would use it? Is the performance
> improvement significant? I suppose there is a reason gcc doesn't
> build/install it by default.
The reason is that it is an external dependency, same as MPC, MPFR, and
GMP (and the rest of the toolchain + GDB for that matter) which are also
supported by the top-level autotools. It was excluded originally because
it was an experimental feature and getting cloog, ppl, and cloog-ppl to
play nicely in chroot required a bit of hacking, but that was several
years ago, gcc-4.8 IIRC. The feature is now mature requiring only one
additional library. I honestly don't know about the performance
improvements. I haven't found any packages that will use the five
additional optimizations by default, but I haven't really looked all
that hard either, and again, I don't consider the results relevant to
the discussion of including it in the book.
The other options for addressing the additional dependency are to
install the library before GCC, or just address this in BLFS, but I
don't know of any other consumers (besides polly - same optimizations
for clang). In my mind, this directly affects the C and C++ drivers, so
it should go into LFS if possible. We already have GMP in LFS (the other
Graphite dep), but GCC uses a specific version of libisl and that needs
to be accounted for, hence the suggestion to use the inline build
(taking a cue from Arch) rather than it being its own package.
More information about the lfs-dev