Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Xavier Leroy <xleroy@pauillac.inria.fr>
To: hayden@cs.cornell.edu (Mark Hayden)
Cc: caml-list@pauillac.inria.fr
Subject: Re: ocaml inlining
Date: Tue, 1 Apr 1997 11:23:05 +0200 (MET DST)	[thread overview]
Message-ID: <199704010923.LAA03776@pauillac.inria.fr> (raw)
In-Reply-To: <199703272021.PAA01643@gulag.cs.cornell.edu> from Mark Hayden at "Mar 27, 97 03:21:34 pm"

>    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





  reply	other threads:[~1997-04-01 10:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-03-27 20:21 Mark Hayden
1997-04-01  9:23 ` Xavier Leroy [this message]
  -- strict thread matches above, loose matches on Subject: below --
1997-03-25 15:36 Mark Hayden
1997-03-26 10:20 ` Xavier Leroy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199704010923.LAA03776@pauillac.inria.fr \
    --to=xleroy@pauillac.inria.fr \
    --cc=caml-list@pauillac.inria.fr \
    --cc=hayden@cs.cornell.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox