Re: [blfs-dev] SBUs - was Re: #3982: Firefox-23.0.1/Xulrunner-23.0.1
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.3750 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. -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] SBUs - was Re: #3982: Firefox-23.0.1/Xulrunner-23.0.1
On Thu, Aug 22, 2013 at 09:45:03AM -0300, Fernando de Oliveira wrote: Em 21-08-2013 19:48, Ken Moffat escreveu: 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. Or something else was using the processor when you first measured, or conceivably something in the kernel or VM improved. Perhaps you gave it more memory. 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. It will always differ, but hopefully not by more than a few seconds. OTOH if you only had one CPU then any other tasks running will make a noticeable difference. 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. Sorry - yes, I do this too when measuring for the book. By that time I've already installed the package and (hopefully) noticed if it works ok If you ever look at the wiki you might come across a few packages where I've noted variations of DESTDIR (typically INSTALLROOT). 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. Yes, agreed. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] SBUs - was Re: #3982: Firefox-23.0.1/Xulrunner-23.0.1
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.3750 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. 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. 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. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] SBUs - was Re: #3982: Firefox-23.0.1/Xulrunner-23.0.1
Ken Moffat wrote: 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. bunutils has definitely been getting slower. At one time mine was about 93 seconds. The latest is 129 seconds. My #1 suspect is gcc, but binutils is probably not blameless either. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
