From owner-cvs-src@FreeBSD.ORG Tue Jul 22 16:06:22 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 3F77A37B401; Tue, 22 Jul 2003 16:06:22 -0700 (PDT) Received: from phk.freebsd.dk (phk.freebsd.dk [212.242.86.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 234E243FB1; Tue, 22 Jul 2003 16:06:21 -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 h6MN6EV3030824; Tue, 22 Jul 2003 23:06:14 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 h6MN6D5H016269; Wed, 23 Jul 2003 01:06:13 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 22 Jul 2003 15:52:41 PDT." <20030722225241.GA61493@athlon.pn.xcllnt.net> Date: Wed, 23 Jul 2003 01:06:12 +0200 Message-ID: <16268.1058915172@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 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: Tue, 22 Jul 2003 23:06:22 -0000 In message <20030722225241.GA61493@athlon.pn.xcllnt.net>, Marcel Moolenaar writ es: >vm_object_backing_scan() has 3 call-sites. Each of the call-sites >has numerous calls to other functions that may or may not be >predicted right, prefetched right or mess up the instruction or >unified caches. While the inlined code yields a larger amount of >text, I find it hard to claim that this by itself overshadows the >performance advantages of increased ILP, improved scheduling due >to dead-code elimination, better cache behaviour due to increased >locality, branch misprediction avoidance, call overhead avoidance, >or just plain better PRE (partial redundant expression elimination), >GCM (global code motion), GVN (global value numbering) or RA >(register allocation). The crucial point here is that nobody seems to have actually run any performance test on this, and the complexity is clearly way out of the "feynmann method" solution space. >Although I do support the removal of the inline keyword to allow >-Werror again and also to provide a sensible (though pessimistic) >starting point for reintroducing some of them, I do not think >there's any ground to use performance gains or losses to defend >the removal of the inline keyword without also providing the >results of measurements performed on all platforms (ok, all tier >1 platforms). The reason it was removed was, as I said earlier, to retain the status quo (since GCC had ignored it). We're arguing what it will take to actually start inlining that function. -- 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.