caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Alain Coste" <alaincoste@club-internet.fr>
To: <caml-list@inria.fr>
Subject: Re: [Caml-list] Local functions with arguments or closures ?
Date: Fri, 8 Jun 2012 00:10:59 +0200	[thread overview]
Message-ID: <C65495E5440647C79E635627B41877E4@Ganymede> (raw)
In-Reply-To: <1339099794.4950.8@samsung>

Hello,

This question recalls me a related one I am often asking myself  when 
writing large functions (say 50 to 100 lines) which use several auxilliary 
functions sharing the same parameters. For example

let f x =
    let g1 () = .. reference to x ... in
    .......
    let gn () = .... reference to x .... in
    calls to to g1() ... gn()

I would like to have an idea of the cost of putting the code of g1...gn 
"inside" f  rather than defining them separately and passing x as a 
parameter, or using a reference

With x as parameter:

let g1 x = .....
....
let gn x = ....
let f x = calls to g1 x .... gn x

Or with a reference:

let f =
    let xr = ref 0 in
    let g1 () = ...!xr ... in
    ....
    let gn () = ... !xr... in
    fun x -> xr := x; .. calls to g1()...gn()

Some years ago I had the same problem with an interpreted language, and the 
answer was clearly in favor of the second or third solution, as the body of 
the function f was evaluated only when the function was applied (and as many 
times it was applied).
But it seems that with a compiler things are different as the body of the 
large function is treated at compile time, and only once. So I suppose the 
extra cost is only to build a closure, but does not depend on the size of 
the body of the large function f.
I generally use the first solution, but I sometimes have some doubts 
concerning efficiency...

Alain Coste

----- Original Message ----- 
From: "Gerd Stolpmann" <info@gerd-stolpmann.de>
To: "Gabriel Scherer" <gabriel.scherer@gmail.com>
Cc: "Daniel Bünzli" <daniel.buenzli@erratique.ch>; "caml-list" 
<caml-list@inria.fr>
Sent: Thursday, June 07, 2012 10:09 PM
Subject: AW: [Caml-list] Local functions with arguments or closures ?


I think it depends very much would you do inside your loop. In
Gabriel's example, there is only an addition, so you will probably see
a difference in runtime. But that's not what you do in practice here.
Imagine the loop iterates over a data structure, and let's assume it is
big enough that it is not completely cached. Then, the few extra
register loads will make no difference, they are just hidden by the
speculative execution done by modern CPUs (i.e. the loads are done
while the CPU waits for the data from RAM).

So yes, passing the arguments explicitly is probably only worth for
extremely simple cases that do not access data massively, but otherwise
use the style you like.

Gerd


  reply	other threads:[~2012-06-07 22:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-07 17:34 Daniel Bünzli
2012-06-07 18:54 ` Yitzhak Mandelbaum
2012-06-07 19:07 ` Gabriel Scherer
2012-06-07 20:09   ` AW: " Gerd Stolpmann
2012-06-07 22:10     ` Alain Coste [this message]
2012-06-07 23:45 ` Ville-Pertti Keinonen
2012-06-16 23:14 ` Goswin von Brederlow

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=C65495E5440647C79E635627B41877E4@Ganymede \
    --to=alaincoste@club-internet.fr \
    --cc=caml-list@inria.fr \
    /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).