Date: Tue, 22 Jul 2003 16:28:11 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Bruce Evans <bde@zeta.org.au> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/lnc if_lnc.c Message-ID: <11951.1058884091@critter.freebsd.dk> In-Reply-To: Your message of "Wed, 23 Jul 2003 00:17:24 %2B1000." <20030722235600.X8165@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?11951.1058884091>