Date: Wed, 21 Mar 2001 23:16:01 +0000 From: David Malone <dwmalone@maths.tcd.ie> To: Bruce Evans <bde@zeta.org.au> Cc: Dag-Erling Smorgrav <des@ofug.org>, current@FreeBSD.ORG, jhb@FreeBSD.ORG, jake@FreeBSD.ORG, Ian Dowse <iedowse@maths.tcd.ie> Subject: Re: Interesting backtrace... Message-ID: <20010321231601.A73422@walton.maths.tcd.ie> In-Reply-To: <Pine.BSF.4.21.0103191442510.33513-100000@besplex.bde.org>; from bde@zeta.org.au on Mon, Mar 19, 2001 at 02:47:34PM %2B1100 References: <Pine.BSF.4.21.0103191051110.32350-100000@besplex.bde.org> <Pine.BSF.4.21.0103191442510.33513-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 19, 2001 at 02:47:34PM +1100, Bruce Evans wrote: > > npx.c already has one "fix" for the overflow problem. The problem > > is may be that clocks don't work early any more. > > It must be that microtime() doesn't work early any more. I did a quick check, and it does seem that i586_bzero can be faster on the k6-2. I found it was about twice as fast for large buffers. This was timed in userland using the TSC. With a slightly simplified version of i586_bzero (I removed all the kernel specific stuff and had it always save the floating point state on the stack). A graph is at: http://www.maths.tcd.ie/~dwmalone/comp/bzero-band.ps The graph seems to peak at about 160kB/s, which seems plausable. The code is at: http://www.maths.tcd.ie/~dwmalone/comp/-time.S http://www.maths.tcd.ie/~dwmalone/comp/-time.c (It's crude, but seemed to produce moderately OK results. You get ocasional dips in the bandwidth due to using the tcs for timing. I only tried sizes which were a power of two, aswell...) David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010321231601.A73422>