From owner-freebsd-current  Fri Apr  5 03:01:59 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id DAA11377
          for current-outgoing; Fri, 5 Apr 1996 03:01:59 -0800 (PST)
Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id DAA11369
          Fri, 5 Apr 1996 03:01:55 -0800 (PST)
Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.7.5/8.6.9) id CAA24750; Fri, 5 Apr 1996 02:59:13 -0800 (PST)
Date: Fri, 5 Apr 1996 02:59:13 -0800 (PST)
Message-Id: <199604051059.CAA24750@silvia.HIP.Berkeley.EDU>
To: davidg@root.com
CC: current@freebsd.org, nisha@cs.berkeley.edu, tege@matematik.su.se,
        hasty@rah.star-gate.com, dyson@freebsd.org
In-reply-to: <199604051021.CAA00222@Root.COM> (message from David Greenman on Fri, 05 Apr 1996 02:21:48 -0800)
Subject: Re: fast memory copy for large data sizes
From: asami@cs.berkeley.edu (Satoshi Asami)
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

 * >    size     libc             ours
 * >      32  15.258789 MB/s   6.103516 MB/s 
 * >      64  20.345052 MB/s  15.258789 MB/s
 * >     128  17.438616 MB/s  15.258789 MB/s
 * 
 *    This would be a big lose in the kernel since just about all
 * bcopy's fall into this range _except_ disk I/O block copies.

Of course we need to put a cut-off number to use the old routine, this
is what we did when we stuck it in the kernel.  Sorry if I didn't
mention that in my previous mail, the purpose of collecting these data
was to see where this threshold is going to be.

 * 								I know
 * this can be done better using other techniques (non-FP, see hackers
 * mail from about 3 months ago). You should talk to John Dyson who's
 * also working on this.

I have that mail, tried what was in there, but it wasn't as fast as FP 
copies.  Maybe I screwed up something, I'll try again tomorrow.

Satoshi