From owner-freebsd-hackers Fri May 7 9:39:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id BE7FF152AE for ; Fri, 7 May 1999 09:39:48 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA45587; Fri, 7 May 1999 09:39:45 -0700 (PDT) (envelope-from dillon) Date: Fri, 7 May 1999 09:39:45 -0700 (PDT) From: Matthew Dillon Message-Id: <199905071639.JAA45587@apollo.backplane.com> To: Zach Brown Cc: Andrew Reilly , freebsd-hackers@FreeBSD.ORG Subject: Re: Pentium-III and FreeBSD? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :On Thu, 6 May 1999, Matthew Dillon wrote: : :> trying to fine-tune some of the weirder instructions, though... it's :> usually a waste of time and tends to obscure the larger issues that, :> if fixed, would have yielded an even greater gain. A good example of : :do some profiling after doing clever things with the cache in some of :the bulk operations (memcpy/memset/tcp checksumming/software raid/etc), :thats all I'm suggesting :) Oh, I agree for block ops! In fact, FreeBSD already does clever things with the cache when doing block ops. Not quite as clever as it could, but some cleverness. For example, on a 686 class cpu the zeroing code forces cache line reads prior to issuing writes to get around the slowness in the bus write-allocate crap, and then only issues writes for elements which are found to be non-zero. On the otherhand, FreeBSD is even more clever in that it avoids having to do a considerable amount of page zeroing on the fly by caching pre-zero'd pages ( and zeroing pages when the cpu is otherwise idle ). This yields a much larger improvement in performance then the cache cleverness. But, as I said... better for the clever optimizations to be hand-coded assembly then to try to put that sort of cleverness in the compiler. :> In regards to FP: The best place for extreme FP optimization is in :> a high level FP library, not in native compiler-produced code. The : :yes. : :-- zach -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message