The SPUs seem to become VERY irrealistic

Florian Hess (FLoH) hipabos at web.de
Fri Oct 18 17:38:54 PDT 2002


Matthias Benkmann schrieb:
> On Fri, 18 Oct 2002 23:25:10 +0200 "Florian Hess (FLoH)" <hipabos at web.de>
> wrote:

> Yes. There's more to computer speed than just MHz. Processor cache size
> for instance plays a role. And these factors are all non-linear. A
> processor with twice the amount of cache is not twice as fast. For a
> program that is very localized, the cache may not have an effect, but some
> other program might get a large speed boost.
> In other words: Your old Pentium 150MHz won't just take 10 times the time
> of an Athlon 1.5GHz for the same task. On some tasks it may take 20 times
> or more time because of architectural differences.
> 
That was clear to me all the time. But I thought the SBU value were 
relatively reliable since it abstractifies from tact rate etc. It 
seems I was wrong. The gcc's complexity is also totally different to 
that of the bash. The SPU would be realistic perhaps if you had to 
compile differently big bashs.

> 
>>My system is: P150, 16mb + 300mb Swap space, 
>>Debian Potato, CD1 (all development tasks installed).
> 
> 
> That system is very old. I don't think many systems of this type went into
> the SBU average.

All modern intel&Co. processors are based on the i386 architecture. So 
the SBU relation must be valid for all these processors. Gerard's 
exception refers even only to SMP.

I think 6h is still a reasonable time for gcc on such a
> system. I wouldn't worry if I were you. Programs hanging in endless loop
> are very rare. Usually they'll crap out with a segfault or something
> similar.
> 

I failed to order an extra amount of patience before I was born ;-). 
So I'll try it with a full Debian Woody distribution.


FLoH.

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



More information about the lfs-support mailing list