caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Alain Frisch <alain@frisch.fr>
To: Joel Reymont <joelr1@gmail.com>
Cc: caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] optimizing numerical code
Date: Thu, 19 May 2011 12:59:35 +0200	[thread overview]
Message-ID: <4DD4F817.9060901@frisch.fr> (raw)
In-Reply-To: <09C897B9-05FC-486C-A126-C644D04BAE94@gmail.com>

On 05/19/2011 10:37 AM, Joel Reymont wrote:
>
> On May 19, 2011, at 10:24 AM, Alain Frisch wrote:
>
>> Actually, even in this branch, acc would not be unboxed. The new heuristic unboxes float variables unless they are both needed in boxed form AND mutated, which is the case for acc in your function.
>
> Shouldn't it be unboxed, though?

Yes, in this case, it would make a lot of sense to work with an unboxed 
variable and only box it when needed. But finding a good heuristic is 
not trivial. Always applying this approach of "on-demand" boxing might 
have drawbacks: more allocations (if the same value is used several 
times in boxed form) and less sharing of allocations (the compiler 
combines adjacent allocations to avoid some overhead). In the example, 
it is easy to find out that the variable is used only once in boxed form 
(in a context executed at most once).

Here is another "lazy" approach that could be worth trying. Consider a 
float variable x which is assigned and used both in boxed and unboxed 
form in the same function. Internally, we keep two variants of it: 
x_boxed and x_unboxed. When x is assigned the result of some float 
expression e:

- if e can be computed directly in unboxed form (e.g. it is the result 
of some numerical operation), assign x_unboxed only;

- if e comes in boxed form (e.g. it is the result of some function 
call), assign x_boxed and x_unboxed (by dereferencing x_boxed);


When x is used an an unboxing context, use x_unboxed. When x is used as 
a boxed value (e.g. as an argument to a function call, or as the return 
value of the current function), check (at runtime) if the content of 
x_boxed is equal to x_unboxed; if yes, return x_boxed; otherwise, box 
x_unboxed, store the new block in x_boxed and returns it.

This scheme guarantees that at most one allocation happens between two 
successive assignment to the variable, and that no allocation happens if 
it turns out that the current value is never used in boxed form. This 
comes at the price of some extra equality checks between floats and 
conditional jumps, but it might be worth trying.


-- Alain

  reply	other threads:[~2011-05-19 10:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-18 18:35 Joel Reymont
2011-05-18 18:50 ` Alain Frisch
2011-05-19  8:24   ` Alain Frisch
2011-05-19  8:37     ` Joel Reymont
2011-05-19 10:59       ` Alain Frisch [this message]
2011-05-19 12:40         ` Gerd Stolpmann
2011-06-09  9:02           ` Alain Frisch

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=4DD4F817.9060901@frisch.fr \
    --to=alain@frisch.fr \
    --cc=caml-list@inria.fr \
    --cc=joelr1@gmail.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).