Re: [Caml-list] Unboxing: how to do it best?

[Guillaume Yziquel <guillaume.yziquel@citycable.ch>]

Le Saturday 15 Jan 2011 à 14:02:11 (+0200), Eray Ozkural a écrit :
>    It's obvious that avoiding pointer chasing, improving locality and
>    reducing storage will in some cases improve performance considerably.
>    I've found many discussions about unboxing, but I haven't seen any
>    solutions that would satisfy high-performance-computing programmers,
>    who would probably like to have better (i.e. fine-grained) control over
>    memory layout (unboxing double arrays isn't enough). In C++ this is
>    trivial, because C++ is just an abstraction of assembly code. To cut it
>    short,  could not we have basically the same affordances of C++ in
>    ocaml by annotating type definitions to indicate where unboxing would
>    be forced? Such annotations aren't a new idea in programming languages,
>    specifically HPF was based largely on parallel storage annotations.
> 
>    Regards,
>    --
>    Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University,
>    Ankara

If you do not care about having the annotation available at runtime
instead of being something static (after all, MPI datatypes are
available at runtime), you could go for encapsulating type information
in first class modules representing datatypes.

Then, for instance, given a datatype, you may wish to construct the
datatype of an array of such types. Such a function needs to know
details about the way OCaml boxes or unboxes different kinds of arrays,
and it can be done (though rather awkwardly in my case).

So first-class modules encapsulating datatype information seems to me a
worthwile option and the only solution I could come with to mimic what
would be done in C++ with traits.

As for 'annotating type definitions', where would you put the line as to
what 'annotating' means? Using type-conv-like Camlp4 processing?

But as to avoiding pointer chasing, I think there's no workaround to the
way OCaml handles memory. The only solution I can come of is the
obvious: use arrays or bigarrays and smart datatypes.

-- 
     Guillaume Yziquel