caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: John Max Skaller <skaller@ozemail.com.au>
To: Oleg <oleg_inconnu@myrealbox.com>
Cc: caml-list@inria.fr
Subject: Re: inlining tail-recursive functions (Re: [Caml-list] O'Caml vs C++: a little benchmark)
Date: Sat, 31 Aug 2002 11:13:04 +1000	[thread overview]
Message-ID: <3D701820.1040600@ozemail.com.au> (raw)
In-Reply-To: <200208281720.NAA06955@dewberry.cc.columbia.edu>

Oleg wrote:

> On Wednesday 28 August 2002 09:47 am, John Max Skaller wrote:
> 
>>> BTW does O'Caml inline tail-recursive functions?
>>>
>>Do you mean loop unrolling? I hear that it doesn't
>>do loop unrolling. [There's nothing to gain from
>>a simple inlining, unless the loop is only executed
>>once or twice - you'd only save a single function call]
>>
> 
> It's been mentioned that O'Caml can inline functions that are not recursive 
> (including inlining across module boundaries). Tail-recursive functions can 
> be, basically, transformed into non-recursive functions by the compiler. So I 
> was wondering if O'Caml inlined them. The benefits of inlining tail-recursive 
> functions should thus be the same as the benefits of inlining non-recursive 
> functions.


I don't think so. For a tail rec function transformed into
a loop, there is little difference between inlining
the loop, or just doing a standard call to a
function containing the loop .. assuming functional
code, and assuming the loop is executed many times.

If the loop is very short, there may be some advantage
in unrolling it.

The difference would only be a single function call,

which has negligible cost compared to a large number
of loop iterations.

There *might* be a small architectural advantage
inlining the loop, if that tends to localise
all the variables (more efficient caching of
memory blocks). This happens to be the case
in my Felix compiler, where a reference to a variable
from another function costs an extra indirection,
and probably requires two pages of virtual
memory instead of the one page and no indirection
required if the loop were inlined.

But Ocaml doesn't work the way Felix does, so I doubt
there would be any advantage (all values are separately
heap allocated anyhow, which is not true in Felix,
which uses 'frames' to reduce heap allocations]

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


      reply	other threads:[~2002-08-31  1:13 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-18 17:17 [Caml-list] O'Caml vs C++: a little benchmark Oleg
2002-08-18 18:00 ` William Chesters
2002-08-18 19:06   ` Oleg
2002-08-18 21:37     ` William Chesters
2002-08-19 13:02   ` Xavier Leroy
2002-08-19 13:58     ` [Caml-list] Inlining across functors (was: O'Caml vs C++: a little benchmark) Thorsten Ohl
2002-08-19 21:16       ` malc
2002-08-19 22:06         ` [Caml-list] Specialization (was: Inlining across functors) Thorsten Ohl
2002-08-20  6:35           ` [Caml-list] " malc
2002-08-20  6:25         ` [Caml-list] Inlining across functors (was: O'Caml vs C++: a little benchmark) malc
2002-08-19 14:39     ` [Caml-list] O'Caml vs C++: a little benchmark Oleg
2002-08-19 15:15     ` William Chesters
2002-08-18 19:16 ` Markus Mottl
2002-08-18 19:58   ` Oleg
2002-08-18 22:59     ` Markus Mottl
2002-08-19 13:12 ` malc
2002-08-19 13:22 ` malc
2002-08-23 21:05 ` John Max Skaller
2002-08-23 21:35   ` Oleg
2002-08-28 13:47     ` John Max Skaller
2002-08-28 14:34       ` Alain Frisch
2002-08-28 17:23       ` inlining tail-recursive functions (Re: [Caml-list] O'Caml vs C++: a little benchmark) Oleg
2002-08-31  1:13         ` John Max Skaller [this message]

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=3D701820.1040600@ozemail.com.au \
    --to=skaller@ozemail.com.au \
    --cc=caml-list@inria.fr \
    --cc=oleg_inconnu@myrealbox.com \
    /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;
as well as URLs for NNTP newsgroup(s).