Re: the Evil Effects of Inlining

It seems to me that all such evaluations are incredibly dependent on the
source language and on the programming style. I would expect to see no
improvement for Fortran code that was written by people who believed that
procedure calls are very expensive and should be avoided like the plague.
They presumably already did the profitable inlining themselves (and
perhaps a little more). I wouldn't expect a lot of improvement in an
average Pascal program either.


In my experience, the place where inlining pays off a lot is for languages
and coding styles that encourage operations on abstract data types to be
expressed as separate procedures. In a well-written Modula-3 or Oberon
program, I would expect to see a reasonable number of procedures that can
be inlined to 2 or 3 instructions, with perhaps no additional register
usage.


A similar effect also occurs in the presence of generic functions, though
that requires more work. If I invoke qsort with integer comparison, I
would expect to gain a fair amount by cloning qsort, and inlining the
comparison (which may effectively have a zero instruction count, since I
save the test on the function result).


My experience with inlining in Russell is very different from Preston's
experience. But then both of the above issues apply (though I don't
create more than one clone of a procedure). Furthermore all of the
"primitives" like integer addition are conceptually procedures (that may
be passed as parameters or assigned or reused by user defined types).
Russell programs compiled without inlining are intolerably slow. (I don't
recall exact numbers. A factor of 3-5 slower is a guess.) This is
largely due to what would be primitives in other languages. But since
it's common to slightly modify an existing type like "Float" to derive new
types, the notion of a "primitve" is unclear, and a more general mechanism
is clearly needed. I also like the idea of supplying most language
"primitives" in predefined modules, and then letting inlining remove the
performance distinction.


None of this is astonishing or inconsistent with what Preston said. But
it's important to only apply these results to their proper context.


Hans
(boehm@xerox.com)
--

Return to the comp.compilers page.
Search the comp.compilers archives again.