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

[Yotam Barnoy <yotambarnoy@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2772 bytes --]

Why do doubles need special handling though, even on a 32-bit system? My
suggestion is that the Double_tag be changed to Flat_tag, meaning that all
non-pointer objects can reside in this tag. The only issue I've found so
far is that polymorphic <, <=, > and >= would not work. However, these
operators should not be allowed on a vector anyway since there is no
natural ordering scheme for vectors. If there are other issues, please let
me know.

I agree regarding the expansion of 246 constructors. This must have been
kept for compatibility with 32 bit systems. I think what should happen in
32 bit systems is that one constructor should be reserved for having >246
constructors, in which case another word of memory could be utilized for
the constructor code. In fact, you'd only need to use that extra word if
the particular constructor exceeds 246. In 64 bit systems, the constructor
count could easily be increased by a few bits, with the same backup
mechanism for when you have more than X constructors (X being the maximum
number of constructors).

Regards,
Yotam


On Mon, Sep 16, 2013 at 12:29 PM, Markus Mottl <markus.mottl@gmail.com>wrote:

> On Mon, Sep 16, 2013 at 11:26 AM, Yotam Barnoy <yotambarnoy@gmail.com>
> wrote:
> > Having looked through some of the ocaml runtime's code, I have a question
> > regarding the Double_array block tag. Why not use a single tag for all
> block
> > content that doesn't contain pointers instead? This would allow
> optimization
> > of all cases where no pointers are involved, including float tuples,
> records
> > with ints, bools and floats etc.
>
> Floats are a little tricky, because they are always doubles (64 bits),
> even on 32-bit platforms.  This requires some special identification.
>
> Adding new tags by reducing the "No_scan_tag" might be a bad (and not
> backward compatible) approach, too: the maximum number of non-constant
> constructors is already pretty low at 246.  I think this number is too
> small these days where 64-bit platforms are standard.  It's probably
> hard to change this design decision now by reducing the overly
> generous maximum "wosize".  Some automatically generated APIs can
> easily blow the current limit on non-constant constructors and require
> annoying, less efficient workarounds.
>
> I guess it might be possible to allocate blocks that are known to be
> all integers or atomic sum types by using the already available
> Abstract_tag.  Large arrays would benefit most from that.  Doing this
> in the compiler might break old marshaled data.  But if performance is
> really critical, I could imagine trying that in a library with
> well-hidden type representations.
>
> Regards,
> Markus
>
> --
> Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com
>

[-- Attachment #2: Type: text/html, Size: 3512 bytes --]