Re: [Caml-list] Ocaml optimizer pitfalls & work-arounds

[Alain Frisch <alain.frisch@lexifi.com>]

On 19/01/2017 12:20, Nils Becker wrote:
> a while ago there was a proposal for deprecating the specialized
> treatment of float arrays, which was not accepted iirc.

For future reference, here are some relevant links:

   https://www.lexifi.com/blog/about-unboxed-float-arrays
   https://github.com/ocaml/ocaml/pull/163
   https://github.com/ocaml/ocaml/pull/616

> it seems that
> the slowdown of all Array.get calls is quite a high price to pay. what
> do we gain from the float array specialization? (honest question - i
> don't have a good understanding)

As far as I understand, the main argument for keeping the special 
current hack is that it helps beginners writing naive numerical code get 
something not horribly inefficient, while most proponents of removing 
the hack are advanced users who feel that the current situation gets in 
the way towards very efficient code.

Providing a FloatArray module would address parts of the concerns from 
these advanced users.  At least it would allow better optimization of 
numerical code, and pave the way for a future deprecation/removal of the 
special hack.  It would not address bad consequences of the special hack 
on (i) the performance of generic array accesses would remain and (ii) 
the complexity and corner cases in the compiler and runtime system.


(Another argument in favor of the status quo is that writing 
"FloatArray.get a i" is syntactically heavier than "a.(i)". 
Interestingly, I don't feel that the ability to write polymorphic code 
on arrays and apply it to (unboxed) float arrays is considered as a very 
important property.)

-- Alain