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

[bluestorm <bluestorm.dylc@gmail.com>]

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

I don't think it is easily possible inside Caml, as the data representation
is tightly bound to the runtime system, and it would be very delicate to
change it.

If you are interested in the relevant litterature, you may want to see for
example the bibliography on "Unboxing data representations" of
  http://pauillac.inria.fr/~xleroy/talks/references-pldi98.html
In particular, you may be interested in the Peyton-Jones and Launchbury
paper, as they implemented their ideas into the GHC Haskell compiler which
support some unboxed types.

If you want to optimize the kernel of an existing OCaml program with unboxed
manipulations, I think your best bet would be to switch to a lower-level
language for your kernel. This is very common in scripting languages where
you generally implement the -- hopefully tiny -- performance-sensitive parts
of your program in C. You still reap the benefits of OCaml abstractions for
the larger, less performance-sensitive part of your program.


On Sat, Jan 15, 2011 at 1:02 PM, Eray Ozkural <examachine@gmail.com> wrote:

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

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