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
next prev parent 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