Using the value as an argument to a call: let y = foo !x in .... Call to "float" native functions are excluded (exp, sin, cos), because they accept unboxed floats.

I always wondered if the compiler should not produce two versions of some functions: for, say, let f x = x +. sin(x**2.), shouldn't f be compiled to a version accepting and returning unboxed floats, the boxing occurring only when needed (thus in essence f is like a primitive function with the "float" qualifier).

Assigning the value to a variable: let y = !x in

Shouldn't this be recursive? If y can be unboxed, then one may want to do it for x too.

Returning the value:

This is more tricky. See http://caml.inria.fr/mantis/view.php?id=5133

The bug 5133 should be fixed with this patch.

See also http://caml.inria.fr/mantis/view.php?id=5204 and the more_unboxing branch in OCaml SVN. The idea there was to box lazily, by keeping a reference to the boxed value for future use (before it is re-used, its content is compared to the current unboxed variable). This ensures that (i) there is never more boxing than with the current strategy (ii) there is no boxing if the boxed value is not actually required.

let s_value = !s in

Why are references (turned in local mutable variables) treated differently from non-mutable variables in your strategy? It would make sense to apply the same treatment to non-mutable float variables (bound to an expression which yields an unboxed float), no? In which case your work-around above (to force boxing) would not work anymore, but this still seem a better default. One could argue that a non-mutable variable would be boxed at most once in the current strategy, while it could be boxed several times if we delay the boxing, but the same is also the case for mutable variables, and a general way to address that would be the strategy I suggest (i.e. box really lazily, i.e. by caching the boxed value computed on demand).

This has been discussed yesterday during a caml-devel meeting, and there is an agreement in principle about switching to the proposed strategy (without my "caching" variant). I'll do some more tests on LexiFi's numerical code to see the impact on performance and if everything goes well, I'll merge the patch.

I cannot observe big impacts on LexiFi's tests, performance wise (perhaps partly because we optimized around the previous unboxing scheme; but also because most of the time is spent in actual computation, not boxing). There is a consistent gain in terms of total allocations, which is good anyway. And I trust @vbrankov that on some real applications, the gain in runtime could be noticeable (this can be trivially seen on micro-benchmarks and some real-world code is not so different from such tight loops). Moreover, the change makes the optimizer more predictable and avoids the need/temptation to add "... +. 0.", while simplifying the code of the optimizer itself.

I'll merge the patch.

It could be interesting to refine the new strategy to box only once, as before, when the identifier is not mutated, but the boxed value is used (potentially/certainly) multiple times. I doubt this would lead to significant improvements, though (although again, micro-benchmarks could show the difference).

Merged in trunk, commit 16215.

Why are references (turned in local mutable variables) treated differently from non-mutable variables in your strategy? It would make sense to apply the same treatment to non-mutable float variables (bound to an expression which yields an unboxed float), no? In which case your work-around above (to force boxing) would not work anymore, but this still seem a better default. One could argue that a non-mutable variable would be boxed at most once in the current strategy, while it could be boxed several times if we delay the boxing, but the same is also the case for mutable variables, and a general way to address that would be the strategy I suggest (i.e. box really lazily, i.e. by caching the boxed value computed on demand).

In the current strategy, cmmgen.ml determines that a variable is float only if it is a result of a float operation. In the case of my workaround the variable is a result of dereferencing so the value is boxed. I completely agree with you that the compiler should use more clues to determine whether a variable is float, which would break the workaround. I already discussed it with @lpw25 and @def-lkb to make the compiler smarter in that matter but as far as I know it's still sitting on our to-do lists.

Apologies for a delayed response.

@vrbankov : can you have a look at http://caml.inria.fr/mantis/view.php?id=6940 and review the attached patch?

This new unboxing strategy, which decides whether to unbox an id or not purely based on the bound expression, actually enables to simplify the whole unboxing scheme, by doing it "on the fly" instead of requiring a post processing part. See http://caml.inria.fr/mantis/view.php?id=7022 and https://github.com/alainfrisch/ocaml/tree/unbox_earlier .

I'm sorry Alain, I completely missed your email from Jul 28th. I'll review the code right away.