Date: Fri, 29 Nov 1996 00:19:29 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, phk@critter.tfs.com, current@freebsd.org Subject: Re: users of "ft" tapes, please test! Message-ID: <199611290519.AAA07832@dyson.iquest.net> In-Reply-To: <199611290447.PAA13253@godzilla.zeta.org.au> from "Bruce Evans" at Nov 29, 96 03:47:56 pm
index | next in thread | previous in thread | raw e-mail
> > >>I have been thinking about un-inlining spls. This saves 29K out of > > >I generally use the rule of thumb that unless the text-size is > >smaller as a result, then inlining is wrong. > > A good rule, I think. Of course it is wrong if the code is in a tight > loop, but that isn't common. > > I think the inlines for min(), etc. break this rule. There aren't many > inlines that follow it. E.g,. the inline spltty(), which is approximately > only 2 C instructions (save = cpl; cpl |= tty_imask;) is twice as large > as the non-inline version. > I built the system with a de-inlined splx() and found an approx 10K savings. My equiv changes for vm_wait saved approx 4K. In both cases, I could not detect a significant speed impact (if anything, it appears that the system ran faster.) Note that this is on a P6 -- which has really good caching. Hope to soon get my P5-166 back up, for P5 testing. If there is not a significant negative speed impact, I would be tempted to make the changes. It would be very suprising to see that an appropriately coded splvm/splimp/splxxx would be much smaller than the subroutine call... Have you considered coding the splxxx inlines in tight asm? Would that help? Johnhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611290519.AAA07832>