From owner-cvs-all@FreeBSD.ORG Tue Jul 22 15:52:45 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 90C7437B401; Tue, 22 Jul 2003 15:52:45 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6719743F75; Tue, 22 Jul 2003 15:52:44 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h6MMqfwO015923; Tue, 22 Jul 2003 15:52:41 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h6MMqfw9061557; Tue, 22 Jul 2003 15:52:41 -0700 (PDT) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h6MMqfTG061556; Tue, 22 Jul 2003 15:52:41 -0700 (PDT) (envelope-from marcel) Date: Tue, 22 Jul 2003 15:52:41 -0700 From: Marcel Moolenaar To: Poul-Henning Kamp Message-ID: <20030722225241.GA61493@athlon.pn.xcllnt.net> References: <3F1DA5B9.A877E8D9@imimic.com> <15381.1058909578@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15381.1058909578@critter.freebsd.dk> User-Agent: Mutt/1.5.4i 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-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 22:52:45 -0000 On Tue, Jul 22, 2003 at 11:32:58PM +0200, Poul-Henning Kamp wrote: > > text data bss dec hex filename > inlined: 17408 76 420 17904 45f0 vm_object.o > regular: 14944 76 420 15440 3c50 vm_object.o > ----- > 2464 > > At least I find that 2k+ code is a non-trivial amount which is > likely, through prefetch and cache flushing, to have a negative > performance impact. Oh? 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). 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). -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net