Bruce Evans bde at
Sat Mar 29 08:04:32 PST 2003

On Sat, 29 Mar 2003, Dag-Erling [iso-8859-1] Sm=F8rgrav wrote:

> Bruce Evans <bde at> writes:
> > > On a different note, support.s is a bloody mess.  Once the dust has
> > > settled, I'd like to go through it and reorder its contents a little.
> > There is very little wrong with its order.
> I placed generic_page*() next to i686_pagezero(), which is right below
> the various bzero() implementations.  That's fine in the sense that it
> is logically related to bzero(), but it's certainly not alphabetical.


> There's a comment right before generic_bzero() that says "bcopy
> family", but bcopy() is miles away from that comment

Oops.  bzero() is in the bcopy() family, but I don't know how it got to
be sorted before bcopy().

> > The microoptimization of making bzero a function pointer wasn't such a
> > good idea.  The main problem with undoing it is that this breaks binary
> > compatibility.
> It looked completely bogus to me.  I realize it breaks binary

It was more useful on original i386's.  It saves a whole branch instruction=

> IMHO, if specialized pagezero() and pagecopy() functions result in
> measurably improved performance, they're worth the added complexity,
> even if we're just talking about a few percent.

I would buy a few percent of real time, but I think we're talking about
a few percent of the copy/zero time, which is a few percent of the
system time, which is a few percent of the real time.  I tried
makeworld with i686_pagezero() on an Athlon (!SMP).  It's a pessimization
on Athlon's and I got a measureable pessimization of 0.3% (6 seconds out
of 1949).  I don't consider this to be significant.

Remaining tyle points taken to private mail.


More information about the cvs-src mailing list