From owner-cvs-all@FreeBSD.ORG Tue Jul 22 16:43:30 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4523D37B401; Tue, 22 Jul 2003 16:43:30 -0700 (PDT) Received: from phk.freebsd.dk (phk.freebsd.dk [212.242.86.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04E5B43F75; Tue, 22 Jul 2003 16:43:29 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by phk.freebsd.dk (8.12.8/8.12.8) with ESMTP id h6MNhOV3031330; Tue, 22 Jul 2003 23:43:24 GMT (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.9/8.12.9) with ESMTP id h6MNhN5H016643; Wed, 23 Jul 2003 01:43:23 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Peter Wemm From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 22 Jul 2003 16:32:58 PDT." <20030722233258.6913E2A7EA@canning.wemm.org> Date: Wed, 23 Jul 2003 01:43:23 +0200 Message-ID: <16642.1058917403@critter.freebsd.dk> 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-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2003 23:43:30 -0000 In message <20030722233258.6913E2A7EA@canning.wemm.org>, Peter Wemm writes: >"Poul-Henning Kamp" wrote: > >> If Y < X, then you have by definition a performance gain. > >Only if you look at the classic model where you ignore things like >speculation and assume that every instruction is executed exactly once etc. >Mainframe optimization strategy is not necessarily applicable to to >contemporary cpus. You overinterpret now. My criteria #1 says: If inlining a function reduces the code size, it is by definition beneficial. It does not say anything about what happens when you removing an inline, and it does not say what happens when inlining increases the code size. It only says that if you can reduce the code size by adding an inline request, then you are on right track, and will not have to run further benchmarks to prove that it is beneficial. There can be corner cases where this in fact hurts your performance, for instance by expanding a function of non-executed code in a much repeated loop, but I certainly trust that you wouldn't even think about inlining the function in the first place then. >I suspect Alan Cox already knows the answer to 'which is faster' in >the vm_object_backing_scan() case and he's waiting for you to put your foot >in it. :-) So far he has not said "I actually measured it", despite having had several good chances to do so :-) 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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.