|
what is missingwhat is missingPosted Jan 9, 2006 7:50 UTC (Mon) by guybar (subscriber, #798)Parent article: Drawing the line on inline
IMHO, is the distribution of function calls per "average" kernel.
Why not run the kernel with no inlineing and oprofile, determine which are , say, the 10% of the inlined functions called 90% of the time, and run an automated "deinlining" script ?
(Log in to post comments)
what is missing Posted Jan 28, 2006 21:39 UTC (Sat) by ringerc (guest, #3071) [Link] It's not that simple unfortunately. If one was to try to give each function a "score" for inlining, where larger numbers mean better to inline, one might use at least the following rules:
... and I don't doubt there are more factors I've missed, especially when considering cache and register use issues. I'm about as far from an expert as you might find - "not totally clueless" perhaps. As far as I know the ideal inline function is something like:
int one() { return 1; }
or
int addone(int in) { return in+1; }
or perhaps something slightly more complex that's called from relatively few places. Forcing the inlining of:
void runEventLoop()
{
// 100 lines of branch-heavy event dispatch code including
// infrequently used cases, error handling, etc
}
... could to very nasty things to your program's binary size and performance if it's called from many places at all. Whether to inline a function is not simple to evaluate from static analysis of source code. The compiler does a somewhat better job, and can be given directives to control its inlining behaviour. Given this, it seems sensible to only force inlining where you know the compiler gets it wrong, or where you know it's absolutely critical to inline a function.
|
Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds
Powered by Rackspace Managed Hosting.