On Tue, Nov 28, 2017 at 06:47:03PM -0800, Nathan Hartman wrote:
> >
> > Over the last 24 hours I've been updating qtwebengine and I see
> > similar variation in the number of SBUs. I wonder if it is worth
> > noting that the timings, particularly for large slow C++ programs,
> > can vary a lot between different machines ?
>
> Here's an idea: A script, introduced early in the book, could record build
> times in a file using a format easily parsed. Upon completion of a BLFS
> system, the reader could send this file to the BLFS project along with dmesg
> output. Collect as many of these as you wish, run them through a program that
> parses and calculates the mean and standard deviation of the build times, and
> you'll have a very good way to estimate best/worst/average case build times.
For times (in the sense of hours, minutes, seconds), I think there
is no interest. What we have is multiples of SBUs - but for these
big packages we prefer to measure with -j4 [ for users of ninja and
rust, see the notes in the editor's guide re the ways of working
around some of the problems ] and to have an SBU built with -j1 on
the completed LFS system (because starting the build on a host with
an old toolchain will usually give a quicker build for pass 1
binutils than using the latest versions of the toolchain -
compilation speed is not an important target for toolchain
developers).
Also, a system might be being used whilse the build is happening -
for a modern 4-core machine, running xorg and a few terms shouldn't
impact the load, but even having a lot of browser tabs open can slow
things down.
It is also, of course, possible to build packages with different
configuration options - and some of those might alter the time.
For qtwebengine, of course, the shipped ninja (on a system without a
patched system ninja) is part of the problem - on my i3 the loadavg
is well over 6 with just the build in one tty and top in another.
And for the book, we put a guidance time in - all I'm suggesting is
that we ought to note that for big packages this might be overly
optimistic, I don't think recording standard deviations, or indeed
worst times, would be worth the effort.
Actually, for a worst time build on the oldest machine available,
with slow memory and a slow disk for when it starts to swap.
For most (not-too-big) packages, the benefit of an SBU has been that
anybody's build SBU should be close to what is in the book. So when
the book has a time in the single digits of SBUs I expect my own
times to be close to what is in the book.
Second issue: what is this phrase "Upon completion of a BLFS system"
- I'm seeing the divergence in timings because I'm applying security
updates, in that sense the system is not complete, and never will be
until I eventually retire it.
But thanks anyway, and if anybody feels inclined to pick up that
suggestion, don't let me stop you.
ĸen
--
Truth, in front of her huge walk-in wardrobe, selected black leather
boots with stiletto heels for such a barefaced truth.
- Unseen Academicals
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
