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

[Jon Harrop <jonathandeanharrop@googlemail.com>]

Eray wrote:
> It's obvious that avoiding pointer chasing, improving locality and
reducing storage
> will in some cases improve performance considerably.

Yes. Generic hash tables are my favourite example where this hurts. Java and
OCaml can be over an order of magnitude slower than .NET due to boxing in
that case.

> 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.

Yes, .NET already does what you are describing: unboxed types are called
"value types". For example, you can allocate an array of structs and refer
to them by array index rather than reference in order to avoid all
allocations and garbage collections. Some people have used this approach to
write low-latency software that never incurs a garbage collection during
steady state operation. I have recently been writing prototype garbage
collectors in F# using the same technique to great effect.

HPC programmers using OCaml will have to settle for generating code from
OCaml when you need to escape its data representation. HLVM is an example of
how this might be done and was specifically designed with HPC in mind.

Cheers,
Jon.