bde at zeta.org.au
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 zeta.org.au> 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