[blfs-dev] SBUs - was Re: #3982: Firefox-23.0.1/Xulrunner-23.0.1

Fernando de Oliveira famobr at yahoo.com.br
Thu Aug 22 05:45:03 PDT 2013

Em 21-08-2013 19:48, Ken Moffat escreveu:
> On Sun, Aug 18, 2013 at 01:49:17PM -0300, Fernando de Oliveira wrote:
>> All 5 VMs finished. They run with 4 CPU's, are i686. Two, as I said
>> before, 1GB RAM, running in other host, 3 have 1.5GB, running on this
>> host that have many other things, including FF and TB, running as well.
>> In the other host, times were
>> SBU_TIME: 36.00411522
>> SBU_TIME: 35.76518218
>> In this host,
>> SBU_TIME: 49.10614525
>> SBU_TIME: 52.37500000
>> SBU_TIME: 59.61038961
>> Perhaps, again, the fact that I have an AMD_64 running on a i686 host
>> running inside a 32bit vmplayer explains why this machine always gave me
>> trouble. It was built to replace this host. Would copy and change
>> whatever needed, for physical, instead of virtual hardware, as done
>> before, is more practical than what I did with LFS7.2, built directly on
>> a physical machine. But as I have written before, discovered that, for
>> many reasons, still need 32bit. Then, waited for LFS7.4, to build a new
>> complete one, 32bit. I only need 64bit for creating OJDK binary for the
>> book. Hope to start building tomorrow.
>  A couple of comments on SBUs - not sure if they relate to what you
> wrote there, but I'd like to record what I do for package edits.

More or less. For the book, I run with j1. Above they ran with j4. But I
was amazed that the faster builds are in a much slower host. I think the
issue is that I am using a larger but slower HD, here. Some time ago,
speed of VM's here were almost double of the ones running in the older
host. I will have to revert that, some day (fast and slow HDs are still
in this host, just move the systems from one to the other.

>  This is prompted by my LFS-7.4 build on i686.  The host was LFS-7.2
> and a single-threaded initial SBU was 78.392 seconds (whoot! fast!).
> But one of the first things I do on a new system is remove /tools,
> recreate an empty /tools, and run the SBU commands as root.  Usually
> a gcc version increase means things run slower, and in this case
> I've gone from 4.7.1 to 4.8.1.  My SBU on this machine is now
> 150.849 seconds.

I will write down things that I think. I may be wrong, so, please tell
me, if I am.

SBU is good, necessary. SBU can never be trusted completely. Can never
be accurate. This host has SBU=133s (about measurement method, see
below), but 7.4-rc1, in a VM, in this same host, reported SBU=120s,
yesterday, so one must be wrong, or, inaccurate.

I have a script to generate the SBUs. However, each time it is executed
in the same machine, the value is different, most of times by small
amounts, but eventually, by large amounts (cannot remember if it could
be double the value or such). Perhaps the machines have their own
"temper" :-), they sometimes get slowing down, tired, have to leave X,
clean swap, restart video card module, restart VM services,logout, get
back... But, SBU is necessary, is a very good invention, cannot see how
it could be done differently, and gives an order of magnitude for the build.

About the method, I do aa thing similar to you, but run the script as
normal user and install using DESTDIR. I believe this should not differ
much from executing as root,  in an empty tools, but if it is really
very different, please, tell me.

About the SBUs for mozilla's. I recall one day, VM with, perhaps, 512MB
of RAM, it was taking much much longer than previous versions. So
started watching libxul linking (did not understand it was linking, at
that time). It was taking what I recall much more than double the time
as previous ones (probably wrong memory is). Said in earlier post it had
1GB, but seems I started using them with 512MB. Point is, any changes,
SBU different.

>  When I'm putting a new version into BLFS I always try to measure it
> on the current release. So my recent changes were measured on 7.3,
> and whatever I do now will be measured on 7.4.

I always do that, but thanks to remind me. Always, before, or asap,
after, committing, try to build in the other machines. These will have j
with the number of CPUs, intead, just to be sure it builds and works,
not for SBU for the book.

I very much appreciate your help, elsewhere, and also here, thanks.


More information about the blfs-dev mailing list