Was Collecting SBUs now, Fast compile engines

Ian Molton spyro at armlinux.org
Fri Jun 7 14:49:07 PDT 2002

On Fri, 07 Jun 2002 23:35:12 +0200
Björn Lindberg <d95-bli.no at spam.nada.kth.se> wrote:

> > thing is, the data has to get INTO those caches, so unless you have
> > compiled the software already, all that data is sitting on the
> > harddisc, not in memory.
> Of course, but assuming enough RAM it only has to be read /once/ while
> it will be processed probably several times.

yes, but the point is that what KIND of RAM you have is irrelevant and
makes little impact on performance. Even 70ns FPM DRAM SIMMS are at
LEAST an order of magnitude faster than the BEST harddiscs.

Consider you have a system and you:

1/2 the CPU speed - BIG effect on compiling
run the HDD at PIO4 instead of UDMA100 - BIG effect on compiling
use PC133 instead of DDR - tiny effect on compiling.

of course, having ENOUGH RAM and having FAST RAM are different matters.

> > so, in order of importance:
> > 
> > 1) CPU caching
> > 2) L2/3 cache (if any)
> > 3) OS RAM cache (note: NOT RAM bandwidth - even the DRAM in my 15 yo
> > acorn would do here)
> > 4) HDD performance, ***especially*** seek time, far more than
> > throughput.
> > 5) memory bandwidth
> You forgot 0) CPU speed, which is the most important factor, IMO. Of
> course, we could argue about the significance of CPU speed versus CPU
> cache speed/size, but it is not very fruitful, since faster (more
> modern) processors generally come with faster/larger caches.

I didnty forget, its just impossible to measure with any degree of
sanity, even in the same family of CPUs, let alone across (say) ARM, PPC
and X86.

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

More information about the lfs-chat mailing list