Re: Performance

Hi James,

James Northrup wrote:
>
> My benchmark in both occasions was tarring+gzipping and building
> various gnu utils packages as the libc would permit.
>
> Subjectively, the vsta+vstafs vs the linux 1.2 was astonishing on
> the side of vsta. I had guessed a margin of around 33% faster
> either by the vsta simplified include paths and/or the shared page
> behavior that was not quite dialed into Linux at the time.

If memory serves I think there are 3 points here (and please excuse me
if any of this is now incorrect as I don't have any recent sources handy
and it's a while since I spent a lot of time in the kernel):

1) VSTa is still running with an old version of gcc - Linux has been
continuing apace with the latest and greatest optimizing versions and
that will certainly have made a big impact. I spent a lot of time
looking at what code generation worked best for different 386, 486
(single, double and triple clocked) and Pentium systems about 5 years
ago and there were huge gains (in some code sequences a factor of 2) if
the code sequencing was correct for the specific CPU being used.

2) Wherever there is significant messaging traffic there's quite a hit.
I suspect there's a factor of 2 still waiting to be extracted from the
message passing code given some judicious use of assembly code. With
Linux someone will tend to optimize these sorts of things quite quickly.

3) VSTa's page mapping is both a blessing and a curse - when doing
things like the pipe server where there are 4k pages being moved about
it is without doubt the fastest way to go. If messages get smaller
(e.g. less than 500 bytes say) then the cost of the page mapping will
often be greater than the cost of simply copying the data (TLB misses,
TLB thrashing, etc). Block oriented operations will do very well with
page mapping whilst ops that don't work this way will be slower.

                        Regards,
                        Dave
Received on Wed Dec 27 02:27:25 2000