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

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

On Thu, Sep 19, 2013 at 10:18:30PM -0400, Yotam Barnoy wrote:
> > 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.
> >
> > This sounds good. On 64 bit platforms, of course, you could use the second
> double word to indicate many more unboxed floats. And let's not forget that
> this impacts performance as well as memory usage.
> 
> 
> 
> > 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.
> >
> 
> Yeah. As soon as I start going down this path, I start thinking of
> haskell's heap solution, which is so elegant: a size field indicates how
> many pointers there are in the data structure, and all pointers are moved
> to the beginning of the structure. This allows them to have full size
> integers as well as unboxed floats. The cost is a less intuitive object
> layout. Of course, they don't have to worry about polymorphic compare or
> marshaling, since typeclasses cover all of these things in the form of
> attached dictionaries.
> 
> Think of how much work they're saving the garbage collector though: they
> never have to read non-pointer values. If only haskell wasn't lazy  :) ...
> BTW can anyone think of a downside to haskell's approach (other than the
> fact that ocaml needs to keep track of which values are floats for
> polymorphic reasons)?
> 
> Yotam

You could save the number of pointer, floats and other.

But comparison needs to know the order in which fields are declared.
If you sort pointers to the front then you need something to unsort
them for every comparison, not just for polymorphic compare and floats.

Also polymorphic types would have different order depending on the
actual type:

# let f (x, y) = x;;            
val f : 'a * 'b -> 'a = <fun>
# f (1, (1, 1));;
- : int = 1
# f ((1, 1), 1);;
- : int * int = (1, 1)

How would the compiler implement f? Since (1, 1) is a pointer it would
be sorted to the front so both invocations of f would get the same
data. You would have to include an index mapping for every field and
access fields indirectly through that. That would cost memory as well
as slow down every access.

MfG
	Goswin