From owner-cvs-all@FreeBSD.ORG Tue Jul 22 09:42:26 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 76DC837B401; Tue, 22 Jul 2003 09:42:26 -0700 (PDT) Received: from phk.freebsd.dk (phk.freebsd.dk [212.242.86.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9939243FCB; Tue, 22 Jul 2003 09:42:24 -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 h6MGgLV3017269; Tue, 22 Jul 2003 16:42:21 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 h6MGgK5H013095; Tue, 22 Jul 2003 18:42:20 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: David Schultz From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 22 Jul 2003 09:30:07 PDT." <20030722163007.GA6080@HAL9000.homeunix.com> Date: Tue, 22 Jul 2003 18:42:20 +0200 Message-ID: <13094.1058892140@critter.freebsd.dk> cc: Paul Richards cc: cvs-src@FreeBSD.ORG cc: src-committers@FreeBSD.ORG cc: cvs-all@FreeBSD.ORG cc: Bruce Evans Subject: Re: cvs commit: src/sys/dev/lnc if_lnc.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 16:42:26 -0000 In message <20030722163007.GA6080@HAL9000.homeunix.com>, David Schultz writes: >The cost of not inlining is insignificant on i386, but it can be >very significant on architectures with sliding register windows, >such as sparc64. On sparc64, a trap is taken every time the >procedure call depth changes by more than 6. An inlining can mean >the difference between super-efficient procedure calls and having >to slide the register window back and forth at great penalty. Fine, but if you are not able to measure the difference and the code is bigger, is it worth it ? Considering that modern CPU caches are about an order of magnitude to small to avoid being a performance throttle, I think code size will prove to be a more significant issue on all current platforms. I agree that constant propagation is a worthwhile reason, but I will still tend to think that if it increases code size for no measurable performance gain, we're on slippery slope... >There is reason for concern about cases where inline really is >misused, either because it massively increases code size or >because it is unimportant to performance and detracts from >debuggability. Here we agree. >[1] In practice, just about any contentious case of inlining is > going to be a wash anyway, and neither side of the argument > is entirely without merit. I'm mostly opposed to a new policy > on the grounds that it's just another stupid rule, complete > with technicolor bikesheds, to throw in the faces of people > trying to do something useful. I far prefer to just fix the problems, but clearly the sort of inline (and register) use we have in the tree indicates that at least some of our contributors are in need of a guideline for when to inline things. -- 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.