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>
> 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
I failed to order an extra amount of patience before I was born ;-).
So I'll try it with a full Debian Woody distribution.
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