From owner-cvs-src@FreeBSD.ORG Tue Jul 22 22:46:10 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 DD77C37B401; Tue, 22 Jul 2003 22:46:10 -0700 (PDT) Received: from phk.freebsd.dk (phk.freebsd.dk [212.242.86.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA79A43F85; Tue, 22 Jul 2003 22:46:09 -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 h6N5k8V3037135; Wed, 23 Jul 2003 05:46:08 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 h6N5k75H019837; Wed, 23 Jul 2003 07:46:07 +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 18:34:42 PDT." <20030723013442.DFA102A7EA@canning.wemm.org> Date: Wed, 23 Jul 2003 07:46:07 +0200 Message-ID: <19836.1058939167@critter.freebsd.dk> cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: Garance A Drosihn 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: Wed, 23 Jul 2003 05:46:11 -0000 In message <20030723013442.DFA102A7EA@canning.wemm.org>, Peter Wemm writes: >What has been highlighted is that inline has been abused over time. The >argument is how and where to draw the line in cost vs benefit. 'inline' is >a hint to the compiler that you believe that the increased code size cost >is worth it. The problem is that some inlines were being failed because >the gcc cost estimation was happening before optimization and was way out >of sync with reality. eg: a reference to curthread blows the estimate out >of the water, even though it accounts for 1 or 2 instructions only. That is only half the problem Peter. The other half of the problem is that since GCC ignored some of the inlines, people may have looked at the object size and thinking "Ok, that had no significant cost and I probably saved a couple of instructions" despite the fact that nothing happened at all. Once we increase the GCC limit to get the cases you mention above inlined, then these impotent inlines suddenly explode in our face as pessimizations. Those were the onces I tried to deal with yesterday. >The other problem is that many of the original measurements were done years >ago by folks who are no longer with us (eg: John Dyson) on hardware that >is no longer an accurate representative of current hardware. This is really only an issue in the few cases where measurements were actually performed. I don't see anyone saying "I always test my code to see if inline has han impact". >> Might we expect some >> performance improvements now that we know to force gcc to >> inline the functions? > >Thats an interesting question, isn't it? Somebody had previously measured >a 5% slowdown as a result of not inlining the VOP_* function wrappers. >I wonder if this is part of the 4.x -> 5.x slowdown that hasn't been >resolved yet. I dont know how many VOP_* calls are or are not presently >being inlined though. In generic all VOP's are inlined at a limit>= 270 so I think the ansker is "none". -- 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.