Date: Sat, 26 Jul 2003 06:52:52 +1000 From: Peter Jeremy <PeterJeremy@optushome.com.au> To: Wes Peters <wes@softweyr.com> 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 Message-ID: <20030725205252.GA9176@cirb503493.alcatel.com.au> In-Reply-To: <200307231710.46896.wes@softweyr.com> References: <16642.1058917403@critter.freebsd.dk> <200307231710.46896.wes@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030725205252.GA9176>