Remove float array optimisation

[lpw25]

The float array optimisation has a number of negative consequences. Alain's blog post contains a good description of the most important ones.

So here is a patch to remove the float array optimisation. It does three things:

• It adds a FloatArray (and corresponding FloatArrayLabels) module to the standard library. The type FloatArray.t is abstract and is represented using the optimised float array representation. It provides the same operations as Array, as well as a create function similar to the one in String. The primitives used by FloatArray are defined in double_array.c.
• It removes the optimised representation for float array.
• It allows float lazy values to be short-circuited by the garbage collector -- since the risk from float arrays is gone.

[alainfrisch]

Thanks, this is great! I'm not sure that this could be integrated directly, however, since it would directly degrade performance of any numerical code that rely on float arrays. What do you think of the migration path I describe in my blog post? First make available the new FloatArray module and add some helpers to find out when they should be used (static analysis of .cmt files to find occurences of "float array" and/or runtime warnings to detect and report the creation of such float arrays [e.g. with some stacktrace]); and only remove the support for the unboxed representation in a later version.

[hhugo]

Any consequences for records of float ?

[lpw25]

What do you think of the migration path I describe in my blog post?

I would love to see it gone as soon as possible, but you're right that it might be worth doing the removal in stages. This would mean applying the first two commits of the patch now, and the rest later.

I'm not sure that static analysis of .cmt files would be significantly more useful than grep. A warning might be more useful, since it would inform people that didn't know that the change was coming.

Any consequences for records of float ?

No, they are unchanged.

[alainfrisch]

A warning might be more useful,

Yes, indeed.

I would love to see it gone as soon as possible

Me too! For the records, I think I remember Xavier saying he was still fond of automatically unboxed float arrays. It's probably best to wait for his opinion before spending too much time on that. (Maybe the argument about Coq will facilitate the discussion :-) )

[xavierleroy]

It would have been better to discuss this proposal on caml-devel before starting coding. For the record, I am opposed to removing the float array optimization.

[gasche]

Why doesn't Floatarray use the new support for custom index operators (.()) and (.()<-) introduced by #69 ? This would reduce the readability cost of moving from Array to FloatArray.

[chambart]

One potential slow way to move forward would be to introduce an new 'array' type that always box float value. If it gets used, some day the array type could be deprecated. But that would need quite a lot of time to get rid of special cases for float (if it can ever happen).

[bluddy]

@xavierleroy, could you outline your rationale for keeping the float array optimization? So far, I have only seen good arguments for removing it.

[DemiMarie]

What about Int32array, Int64array, IntArray, and NativeIntArray?

[lpw25]

This proposal has been subsumed by another (which doesn't have a PR yet) that will allow users to created unboxed array types for types other than float.

[lpw25]

I guess I'll close this in favour of #1294.