Date: Sat, 17 May 2003 21:40:12 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: freebsd-hackers@freebsd.org Subject: Re: Optimizations. Message-ID: <7314.1053200412@critter.freebsd.dk> In-Reply-To: Your message of "Sat, 17 May 2003 12:23:23 PDT." <20030517192323.GA539@athlon.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20030517192323.GA539@athlon.pn.xcllnt.net>, Marcel Moolenaar writes : >On Sat, May 17, 2003 at 07:14:40PM +0200, Poul-Henning Kamp wrote: >> In message <20030516184626.GB537@athlon.pn.xcllnt.net>, Marcel Moolenaar writes >> : >> >On Fri, May 16, 2003 at 09:59:52AM +0200, Poul-Henning Kamp wrote: >> >> >> >> >That's right:) >> >> >Look at functions in /sys/kern/kern_tc.c. There are so many little >> >> >functions. How about put __inline here and there? >> >> >> >> Try it, and you'll find that things get slower because the code >> >> gets bigger. >> > >> >Observed on what architecture? >> >> i386, but it takes a _lot_ to get a stddev on your measurements >> which allow you to measure this in real-world applications. > >Some are called from hardclock so I can imagine that if inlining has >a positive effect, the effects are generally more indirect. I expect >that (selective) inlining could make a difference on ia64. There's >hardly any ILP now. It's also not important now :-) It all depends on the architecture, and the timecounter hardware. I _really_ think that there are much more low-hanging fruit for optimizing performance, than struggling with MD inlining of functions in the timecounter code. -- 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?7314.1053200412>