On Mon, Apr 24, 2006 at 03:10:04PM -0500, Randy McMurchy wrote:
Yes, many are grossly wrong.
Yes, and something that will be greatly helped along by jhalfs, but
going back in memory to previous SBU threads, I believe it was decided
that SMP machines would be quite skewed. Hyprethreading acts
El Lunes, 1 de Mayo de 2006 22:53, Archaic escribió:
Yes, and something that will be greatly helped along by jhalfs, but
going back in memory to previous SBU threads, I believe it was decided
that SMP machines would be quite skewed. Hyprethreading acts like SMP
(to what extent I'm not sure)
Dan Nicholson wrote these words on 04/24/06 15:30 CST:
On 4/24/06, Randy McMurchy [EMAIL PROTECTED] wrote:
And on my doggy 500mhz P3, just recently built (20060322):
[EMAIL PROTECTED]: ~/build/Logs/LFS_Tools/gcc-4.0.3-Pass1 cat sbu.time
9.38 SBU
Are you building on my box? :-) I got 9.2
On 4/25/06, Randy McMurchy [EMAIL PROTECTED] wrote:
Dan Nicholson wrote these words on 04/24/06 15:30 CST:
On 4/24/06, Randy McMurchy [EMAIL PROTECTED] wrote:
And on my doggy 500mhz P3, just recently built (20060322):
[EMAIL PROTECTED]: ~/build/Logs/LFS_Tools/gcc-4.0.3-Pass1 cat sbu.time
Dan Nicholson wrote these words on 04/25/06 10:15 CST:
Maybe, but it depends on lots of other things, too. What services are
you running, what optimization settings, etc.
Are you sure about that?
I display bogomips and it never changes, regardless what services I
may be running. I don't know
On 4/25/06, Randy McMurchy [EMAIL PROTECTED] wrote:
Dan Nicholson wrote these words on 04/25/06 10:15 CST:
Maybe, but it depends on lots of other things, too. What services are
you running, what optimization settings, etc.
Are you sure about that?
I display bogomips and it never
El Martes, 25 de Abril de 2006 01:49, Bryan Kadzban escribió:
So you're right: not drastic, and not many packages. I don't know how
widespread the differences here are; I'd chalk most of it up to just not
having updated the SBU numbers since 6.1.1.
I'm now making a script that will do report
El Martes, 25 de Abril de 2006 19:01, M.Canales.es escribió:
I'm now making a script that will do report with the SBUs and disk space
calculations from jhalfs build logs.
When ready, anyone using jhalfs to build the book could to submit us that
report and we could to use it to update the
Hi
I made some changes to jhalfs to do more accurate disk usage and build time
measurements. Due that into the editor's guide there is no mention (yet)
about how to do that measurements, I implemented the next approach:
Disk usage is made in to steeps, a first du -skx $LFS before to unpack
On 4/24/06, M.Canales.es [EMAIL PROTECTED] wrote:
That should to work. But comparing the values obtained from my last jhalfs
build with the current ones in the book, the differences are abismal in some
cases. For example, for GCC-pass1 in the book we have:
Approximate build time: 4.4 SBU
M.Canales.es wrote these words on 04/24/06 14:40 CST:
Disk usage is made in to steeps, a first du -skx $LFS before to unpack the
package, and a second du -skx $LFS before to delete the sources and build
dirs (excluding in both cases the jhalfs dir to not measure build log files).
Sounds
El Lunes, 24 de Abril de 2006 22:03, Dan Nicholson escribió:
Approximate build time: 8 SBU
I get 9.2 SBU for gcc-pass1. I didn't measure disk usage with those.
Well, my time values can be smallest than yours due that I'm using an
HiperThreading enabled Intel CPU.
What I can't undestart
Dan Nicholson wrote these words on 04/24/06 15:03 CST:
On 4/24/06, M.Canales.es [EMAIL PROTECTED] wrote:
Approximate build time: 8 SBU
I get 9.2 SBU for gcc-pass1. I didn't measure disk usage with those.
And I'm smack dab in the middle between y'all.
[EMAIL PROTECTED]:
On 4/24/06, M.Canales.es [EMAIL PROTECTED] wrote:
El Lunes, 24 de Abril de 2006 22:03, Dan Nicholson escribió:
Approximate build time: 8 SBU
I get 9.2 SBU for gcc-pass1. I didn't measure disk usage with those.
Well, my time values can be smallest than yours due that I'm using an
Randy McMurchy wrote these words on 04/24/06 15:17 CST:
And I'm smack dab in the middle between y'all.
[EMAIL PROTECTED]: ~/build/Logs/LFS_Tools/gcc-4.0.2-Pass1 cat sbu.time
8.64 SBU
[EMAIL PROTECTED]: ~/build/Logs/LFS_Tools/gcc-4.0.2-Pass1 cat elapsed.time
real24m40.135s
user
Joshua Murphy wrote these words on 04/24/06 15:24 CST:
theoretically, be
within 3-4 of each other (between systems) at the worst.
In my opinion, it is much closer than that. Consistently. I'm at
less than 1 SBU difference between an Athlon 2400+ with 768mb RAM
and a 500mhz P3 with only 256mb.
El Lunes, 24 de Abril de 2006 22:10, Randy McMurchy escribió:
unpack additional packages (like libidn, bash-doc or vim-languages)
To me, this skews things badly. We've never ever counted unpacking
source tarballs before.
[EMAIL PROTECTED]:~/sources$ time { tar -xjf
El Lunes, 24 de Abril de 2006 22:25, Randy McMurchy escribió:
[EMAIL PROTECTED]: ~/build/Logs/LFS_Tools/gcc-4.0.2-Pass1 cat sbu.time
8.64 SBU
And on my doggy 500mhz P3, just recently built (20060322):
[EMAIL PROTECTED]: ~/build/Logs/LFS_Tools/gcc-4.0.3-Pass1 cat sbu.time
9.38 SBU
M.Canales.es wrote these words on 04/24/06 15:32 CST:
Not so badly. From your other post I think that the hardware used to do the
builds has a bigger impact in the final values than the unpack of that small
packages ;-)
Good point. But I tend to think BLFS.
Now do the same thing for the
M.Canales.es wrote:
What I can't undestart is that the book SBU values are smallest that
mine :-?
Have the SBU numbers been updated at all since 6.1 or 6.1.1? If not,
those book versions still use gcc 3.4. If gcc 4's bootstrap takes a lot
longer than gcc 3.4's did, then that could explain the
On 4/24/06, Bryan Kadzban [EMAIL PROTECTED] wrote:
Have the SBU numbers been updated at all since 6.1 or 6.1.1? If not,
those book versions still use gcc 3.4. If gcc 4's bootstrap takes a lot
longer than gcc 3.4's did, then that could explain the higher SBUs when
building gcc 4.
gcc-4
Dan Nicholson wrote:
The situation you describe doesn't seem like it would have that
drastic of an effect on more than a couple packages.
IIRC, it really only had an effect on the large packages (gcc, glibc,
etc.). And (again IIRC) it wasn't drastic; it was on the order of an
SBU or so.
So
22 matches
Mail list logo
