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
next in thread | previous in thread | raw e-mail | index | archive | help
> > >>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? John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611290519.AAA07832>