caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* Re: ocaml inlining
@ 1997-03-27 20:21 Mark Hayden
  1997-04-01  9:23 ` Xavier Leroy
  0 siblings, 1 reply; 4+ messages in thread
From: Mark Hayden @ 1997-03-27 20:21 UTC (permalink / raw)
  To: caml-list

>> In the recent versions of Ocaml, are functions inlined
>> across modules? Across files?
>
>Yes to both. (Remember: this applies only to the native-code compiler.)
>The body of an inlinable function is stored in the .cmx file for its
>defining module, thus it can be inlined from other modules.
>
>> If so, what is the effect of
>> compiling several files with different levels of inlining?
>
>The inlining level (-inline n) is taken into account when compiling a
>function definition, but not when compiling a call to this function.
>If the function is small enough (w.r.t. the inlining level at that
>time), it is marked inlinable, and all uses of this function will
>inline its body, regardless of the value of -inline at the time of use.

   Doing things in this fashion seems to prevent functions
in the standard library from being inlined (other than with
the default level).  It would seem that there could be many
advantages to inlining functions such as List.iter.  Is
there any way to get around this limitation without
recompiling & reinstalling the standard library or compiling
private versions of the standard library modules?
   Also, I tried compiling the following to see what
assembly code was being generated:

  let rec map f = function (* from List module *)
      [] -> []
    | a::l -> let r = f a in r :: map f l

  let list_incr l =
    map (fun i -> succ i) l

Unfortunately, no matter how large an inlining level was
used, the map function would not be inlined.  When I looked
at the compiler sources, I found that "let rec" expressions
are never inlined.  Is there a reason for this?
  As a final note, I ran some tests to see the effect of
inlining on the size of Ensemble, the system I'm working on.
Ensemble is a distributed communication system with around
30,000 lines of ML code.  With varying levels of inlining, I
compiled, linked, and stripped all of Ensemble, and then
printed the size of the resulting executable.

  inline  executable
  level   size
  0       757024
  1       757424
  2       765584
  3       769776
  4       772928
  8       782032
  16      787488
  20      792064
  24      795136
  28      803056
  32      803056

--Mark





^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: ocaml inlining
  1997-03-27 20:21 ocaml inlining Mark Hayden
@ 1997-04-01  9:23 ` Xavier Leroy
  0 siblings, 0 replies; 4+ messages in thread
From: Xavier Leroy @ 1997-04-01  9:23 UTC (permalink / raw)
  To: Mark Hayden; +Cc: caml-list

>    Doing things in this fashion seems to prevent functions
> in the standard library from being inlined (other than with
> the default level).  It would seem that there could be many
> advantages to inlining functions such as List.iter.

As you found out yourself, List.iter is never inlined because it's
recursive.

> Is there any way to get around this limitation without
> recompiling & reinstalling the standard library or compiling
> private versions of the standard library modules?

Given the current inlinng technology, I strongly doubt there is any
standard library function that could usefully be inlined and which is
not marked inlined at level 1 (the default inlining level). Actually,
level 1 inlining already does a number of useless inlinings.

> Unfortunately, no matter how large an inlining level was
> used, the map function would not be inlined.  When I looked
> at the compiler sources, I found that "let rec" expressions
> are never inlined.  Is there a reason for this?

It's much harder than inlining simple functions. Basically, a local
copy of the recursive function must be made, and then subject to
constant propagation and elimination of unused function arguments
(e.g. to get rid of the function parameter of List.iter). None of
these transformations, especially elimination of unused arguments, is
performed by the current compiler.

> With varying levels of inlining, I
> compiled, linked, and stripped all of Ensemble, and then
> printed the size of the resulting executable.

And what kind of speedups did you get in return? On my tests,
the default inlining level gives about 5% speedup for a 5% increase in
code size; higher levels increase code size, but have no noticeable
impact on speed.

- Xavier Leroy





^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: ocaml inlining
  1997-03-25 15:36 Mark Hayden
@ 1997-03-26 10:20 ` Xavier Leroy
  0 siblings, 0 replies; 4+ messages in thread
From: Xavier Leroy @ 1997-03-26 10:20 UTC (permalink / raw)
  To: Mark Hayden; +Cc: caml-list

> In the recent versions of Ocaml, are functions inlined
> across modules? Across files?

Yes to both. (Remember: this applies only to the native-code compiler.)
The body of an inlinable function is stored in the .cmx file for its
defining module, thus it can be inlined from other modules.

> If so, what is the effect of
> compiling several files with different levels of inlining?

The inlining level (-inline n) is taken into account when compiling a
function definition, but not when compiling a call to this function.
If the function is small enough (w.r.t. the inlining level at that
time), it is marked inlinable, and all uses of this function will
inline its body, regardless of the value of -inline at the time of use.

- Xavier Leroy





^ permalink raw reply	[flat|nested] 4+ messages in thread

* ocaml inlining
@ 1997-03-25 15:36 Mark Hayden
  1997-03-26 10:20 ` Xavier Leroy
  0 siblings, 1 reply; 4+ messages in thread
From: Mark Hayden @ 1997-03-25 15:36 UTC (permalink / raw)
  To: caml-list


In the recent versions of Ocaml, are functions inlined
across modules?  Across files?  If so, what is the effect of
compiling several files with different levels of inlining?

The Ocaml documentation describes the inlining option as follows:

-inline n
     Set aggressiveness of inlining to n, where n is a positive integer. Specifying -inline 0
     prevents all functions from being inlined, except those whose body is smaller than the call
     site. Thus, inlining causes no expansion in code size. The default aggressiveness,
     -inline 1, allows slightly larger functions to be inlined, resulting in a slight expansion in
     code size. Higher values for the -inline option cause larger and larger functions to
     become candidate for inlining, but can result in a serious increase in code size.

thanks, Mark





^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~1997-04-01 10:47 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-03-27 20:21 ocaml inlining Mark Hayden
1997-04-01  9:23 ` Xavier Leroy
  -- strict thread matches above, loose matches on Subject: below --
1997-03-25 15:36 Mark Hayden
1997-03-26 10:20 ` Xavier Leroy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).