From owner-cvs-all@FreeBSD.ORG Tue Jul 22 07:28:16 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 8E07A37B401; Tue, 22 Jul 2003 07:28:16 -0700 (PDT) Received: from phk.freebsd.dk (phk.freebsd.dk [212.242.86.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D14643F93; Tue, 22 Jul 2003 07:28:15 -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 h6MESCV3009074; Tue, 22 Jul 2003 14:28:12 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 h6MESB5H011952; Tue, 22 Jul 2003 16:28:11 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Bruce Evans From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 23 Jul 2003 00:17:24 +1000." <20030722235600.X8165@gamplex.bde.org> Date: Tue, 22 Jul 2003 16:28:11 +0200 Message-ID: <11951.1058884091@critter.freebsd.dk> cc: Paul Richards cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org 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 14:28:17 -0000 In message <20030722235600.X8165@gamplex.bde.org>, Bruce Evans writes: >Several places, including if_lnc.c, used __inline to get cleaner code >at no cost in performance. Removing __inline adds a tiny cost. You know, I would have agreed with you on that, if we were talking about a CPU with no caches, no branch-prediction and no prefetching. For modern CPUs however it would be hard to prove the above statement true or false with any sort of measurement setup we have access to, and it would be even harder if not downright impossible to prove that the result was generally applicable to a majority of the current hardware on the market. In this particular case I think, any effect, positive or negative, will depend on the ratio of transmitted and received packets (because RX-only or TX-only irq's might be able to prefetch over the call but not the inline version) I would _really_ love to nail up a policy note which says that "inline" should only be used if it is possible to show an effect, either because inlining reduces the code size (in this particular case less bytes to execute is generally an indication of better performance) or by showing actual performance improvements from the inlining. -- 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.