From owner-cvs-src@FreeBSD.ORG Tue Jul 22 18:34:43 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 99D0C37B401; Tue, 22 Jul 2003 18:34:43 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 092C043F3F; Tue, 22 Jul 2003 18:34:43 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id DFA102A7EA; Tue, 22 Jul 2003 18:34:42 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Garance A Drosihn In-Reply-To: Date: Tue, 22 Jul 2003 18:34:42 -0700 From: Peter Wemm Message-Id: <20030723013442.DFA102A7EA@canning.wemm.org> cc: cvs-src@FreeBSD.org cc: src-committers@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: Wed, 23 Jul 2003 01:34:44 -0000 Garance A Drosihn wrote: > At 5:32 PM -0700 7/22/03, Peter Wemm wrote: > > > >Take the i386 interrupt vector code. Thats an example where > >it is massively inlined. Having a non-inlined function that > >does all the calculations and bit shifting is much smaller > >in code size, but slower at runtime. > > If I understand this discussion correctly, then the previous > version of gcc (in freebsd-current) was NOT inlining these > sections event though we thought it was. In some cases, yes, that was happening. Not the interrupt code though because thats generated by hand in assembler. Things like some kobj and VOP_* wrappers were not being inlined as they should be. 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. 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. On the other hand, many of us still use that older hardware and so tuning there is a much bigger issue. eg: my home desktop predates John Dyson leaving. Meanwhile, -Werror is still disabled. We have been sneaking in potentially fatal errors. eg: kern_umtx.c has what looks like a legitimate problem to me, but its lost in the inline noise. > 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. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5