Just remarks

Craig Hurley sobit at reddnet.net
Mon May 27 11:03:45 PDT 2002


I kind of like the a class, b class... idea.  
If you use the 500MHz, 2.2GHz and such for the averages, why not
add a table to "Conventions use in the book" called "general compile
times"

  Classes      |   Cel500  |   Athlon1.53  |  P4-2.2
------------------------------------------------------
    A          |   <time>   |   <time>      | <time>
    B          |   <time>   |   <time>      | <time>


This could give a quick general referance to those that read the
beginning chapters.  Maybe even make the Class listing on the page a
link to the table?


-----Original Message-----
From:	jsmaby at virgo.umeche.maine.edu
Sent:	Mon 5/27/2002 1:40 PM
To:	lfs-dev at linuxfromscratch.org
Cc:	
Subject:	Re: Just remarks
> Think about it - if gerhard used his 2.2GHz P4 to do the timings, and
> you had (say) a 733MHz celeron... would you be able to predict the
build
> time based on his figure?

Yes, after compiling one medium-sized package (static bash would do
nicely),
and doing a little arithmatic.

> Now, an average figure - does that make it /any/ easier to guess how
> long your build will take?

To an extent, yes.  The speed depends on lots of things, like memory
bandwith, amount of memory (less than 32mb _really_ hurts), hard drive
speed, etc.  By averaging over many configurations, one creates a
mythical
machine that has all those properties averaged, and a given machine will
be more likely to match (using the speed ratio calculated from the first
package's build time).  Things do start to go non-linear in 486's, and
they would likely mess up the average (or rather, systems with < 32mb
ram).

A while back, the idea of changing the build time units to ed's (the
time
it takes ed to compile) was discused (although I think static bashes
would
make more sence).  I think Gerard's answer at the time was that it had
to wait until after 3.0.  I guess it's after 3.0 now, so perhaps it
should be implemented.

-James
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message




-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list