From owner-cvs-src@FreeBSD.ORG Fri Jul 25 13:53:05 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9680837B401; Fri, 25 Jul 2003 13:53:05 -0700 (PDT) Received: from cirb503493.alcatel.com.au (c211-28-27-130.belrs2.nsw.optusnet.com.au [211.28.27.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B20743F85; Fri, 25 Jul 2003 13:53:03 -0700 (PDT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])h6PKr0gh035279; Sat, 26 Jul 2003 06:53:00 +1000 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost) by cirb503493.alcatel.com.au (8.12.8/8.12.8/Submit) id h6PKqqvA035278; Sat, 26 Jul 2003 06:52:52 +1000 (EST) Date: Sat, 26 Jul 2003 06:52:52 +1000 From: Peter Jeremy To: Wes Peters Message-ID: <20030725205252.GA9176@cirb503493.alcatel.com.au> References: <16642.1058917403@critter.freebsd.dk> <200307231710.46896.wes@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200307231710.46896.wes@softweyr.com> User-Agent: Mutt/1.4.1i cc: cvs-src@freebsd.org cc: Poul-Henning Kamp cc: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern init_main.c kern_malloc.c md5c.c subr_autoconf.c subr_mbuf.c subr_prf.c tty_subr.c vfs_cluster.c vfs_subr.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2003 20:53:06 -0000 On Wed, Jul 23, 2003 at 05:10:46PM -0700, Wes Peters wrote: >As a general note, I think it is quite hard to predict how any such >"optimization" is going to behave across even the common x86 family >processors. We've seen many times that optimizing for p4 is not the >same as optimizing for Athlon, etc. These days, benchmark results on a >single architecture are arguably no more valid than no benchmark >results at all. > >That said, "my athlon is your athlon" (XP 2000+, will be running >-current after this weekend) for anyone who needs one for testing. >Not a speed daemon by todays standards, but it was yesterday... Actually, I'd go so far as to suggest that you couldn't safely extrapolate from your XP 2000+ to an XP 3200+ and even less an MP 2800+. As the CPU multipliers increase, accessing main memory becomes the dominant performance factor - and SMP systems just make that worse by increasing the memory bus load. "Code size" and "instructions executed" become less relevant than "amount of code transferred to cache" and "cache misses" - and the latter is probably predominantly mis-predicted branches and data accesses. Peter