[RFC] Port of NetBSD's optimized amd64 string code
delphij at frontfree.net
Tue Aug 2 17:36:07 GMT 2005
On Tue, Aug 02, 2005 at 10:20:42AM -0700, David O'Brien wrote:
> On Tue, Aug 02, 2005 at 12:02:46PM +0800, Xin LI wrote:
> > On Mon, Aug 01, 2005 at 06:39:16PM -0700, David O'Brien wrote:
> > > On Tue, Aug 02, 2005 at 02:25:18AM +0800, Xin LI wrote:
> > > > Here is a patchset that I have produced to make our libc aware of the
> > > > NetBSD assembly implementation of the string related operations.
> > >
> > > What performance benchmarks have these been thru?
> > BTW. Would you please give me some hints on the benchmarking? I am
> > not sure whether just looping the test cases on some determine dataset
> > would be enough?
> Try some real world tests such as 'make buildworld'. Looking in
> src/usr.bin the following utils make good use of these libc functions and
> would be good real world tests: uuencode catman compress last makewhatis
> * uuencode a large kernel
> * run /etc/periodic/weekly/320.whatis
> * compress a large kernel
> * last delphij on a large /var/log/wtmp
> * cp /usr/src/share/man/man[1-9] to a ram disk and then run catman over it
Thanks, I will try these tomorrow.
> Just a few suggestions. It is easy to "optimize" for the simple input case
> and miss the larger case. I've also seen people "optimize" for all cases
> but then wind up with so much overhead that small inputs are slower.
> I have some very fancy routines from AMD that take into account cache
> size, alignment, and uses the prefetch instructions. The problem is they
> are a huge win for large input sizes, but I'm concerned about their
> performance on small input sizes.
> If these NetBSD routines perform better in the tests I listed above, we
> should commit them. We can continue to refine these libc routines over
Agreed. I will do more careful benchmarks that can reflect more real world
better, to figure out whether these "optimizations" are really necessary for
Xin LI <delphij frontfree net> http://www.delphij.net/
See complete headers for GPG key and other information.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20050803/ae260bdf/attachment.bin
More information about the freebsd-amd64