Re: [Caml-list] Expanding the Float Array tag

[Goswin von Brederlow <goswin-v-b@web.de>]

On Wed, Sep 18, 2013 at 11:10:00AM -0400, Yotam Barnoy wrote:
> So here is my tentative proposal:
> 
> For 32-bit platforms, a specific tag will signify the extra header word.
> This word will have 16 bits' worth of tag. I think 65000 tags are enough,
> right? This isn't one of those "128KB will always be enough" kind of thing,
> is it? The top 16 bits can be used for other things. For example, a
> constructor with up to 16 words could specify using a 16-bit bitfield which
> of its members are floats. So a constructor with floats would automatically
> use the expanded header. An array of records (with no floats) could have
> the record size specified in 16 bits.
> 
> For 64-bit platforms, the expanded 16-bit tag could reside in the same
> header, with one bit extra used to specify the extra header word for any
> given tag. With 64 bits available, this extra header can be very powerful:
> it could be used to specify 64 words worth of floats for constructors, or
> it could specify a 5-bit record size for an array together with 32 bits to
> specify the floats in the record.
> 
> Yotam

You have 2 issues here:

1) unboxed floats

The double_array_tag saves a lot (50%) of ram because the floats are
not individually boxed. For mixed blocks a bitfield could also allow
unboxed floats.

Inspecting the contents of such a block would be more complex then
because, on 32bit, a is-float bit means the float is stored in 2
fields and the inspection has to combine the current field with the
next and skip over the next field.

You want to use a 16-bit bitfield to indicate which members are float.
This would work for record and constructors with up to 16 members. I
would modify this a bit. The lower 15 bit indicate which of the first
15 members are float while the 16th bit indicates if all remaining
members are floats. If you declare the 16-bit value as signed and use
arithmetic shift right to iterate through the bits you get this
naturally.

2) values the GC doesn't need to scan

This would probably be far more often usefull. There are tons of
tuples and records that contain only primitive types (int, bool, unit,
...). This is also true for a lot of variant types. So a simple
flat_tag would only cover half the cases. A flat bit would be better.
On the other hand a bitfield for values the GC doesn't have to inspect
seems pointless. Each value already has a bit for that.

MfG
	Goswin