From owner-cvs-src@FreeBSD.ORG Wed Jul 23 17:10:58 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 51FD137B401; Wed, 23 Jul 2003 17:10:58 -0700 (PDT) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84FBC43FAF; Wed, 23 Jul 2003 17:10:57 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from salty.rapid.stbernard.com (corp-2.ipinc.com [199.245.188.2]) by smtp-relay.omnis.com (Postfix) with ESMTP id 18C599BE83; Wed, 23 Jul 2003 17:10:56 -0700 (PDT) From: Wes Peters Organization: Softweyr.com To: "Poul-Henning Kamp" , Peter Wemm Date: Wed, 23 Jul 2003 17:10:46 -0700 User-Agent: KMail/1.5.2 References: <16642.1058917403@critter.freebsd.dk> In-Reply-To: <16642.1058917403@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200307231710.46896.wes@softweyr.com> X-Mailman-Approved-At: Wed, 23 Jul 2003 18:09:27 -0700 cc: "Alan L. Cox" cc: src-committers@FreeBSD.org cc: Bosko Milekic cc: Bruce Evans cc: cvs-src@FreeBSD.org cc: Steve Kargl cc: cvs-all@FreeBSD.org cc: Marcel Moolenaar 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: Thu, 24 Jul 2003 00:10:58 -0000 On Tuesday 22 July 2003 16:43, Poul-Henning Kamp wrote: > > I think we all, me included, have to admit that we have seldom if > ever actually benchmarked or even just checked the size impact of > the inlines we have put in, mostly we have relied on our intuition > to determine where an inline made sense. > > And now GCC has told us that we were wrong in some number of > the cases and that should prompt us to trust our intuition a little > bit less and rely more on actual facts instead. 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... -- "Where am I, and what am I doing in this handbasket?" Wes Peters wes@softweyr.com