Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Bigarray vs. array - mixing?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2003-04-24 (13:42)
From: Xavier Leroy <xavier.leroy@i...>
Subject: Re: [Caml-list] Bigarray vs. array - mixing?
> Basically I have numerical code that uses Bigarrays in some parts
> (for example in interfacing with Lacaml), but other parts that use
> arrays.  It doesn't seem to be that clean to make them co-exist.
> Which should I use?  Since I was forced to use Bigarrays for Lacaml
> (which is a wonderful interface to LAPACK -- but missing some
> drivers. :((( ), I decided to use Bigarrays for much of the rest of
> my program.  I made judicious use of blit and splice, since I assume
> that they only do two bounds checks. But my code still spends a lot
> of time in Bigarray.  In fact approx the *same amount of time* as it
> spends calculating! (according to gprof)

If the profile shows that significant time is spent in the bigarray_get_*
and igarray_set_* functions, this indicates that your Caml code is too
polymorphic.  ocamlopt can inline bigarray accesses only when the
types of the bigarrays is fully, statically known.  

It is easy to get unwanted polymorphism for Caml code that uses
bigarrays.  For instance,

        let f a = a.{0} <- 3.14

has type (float, 'a, 'b) Bigarray.Array1.t -> unit.  The assignment
determines that the Caml type of the array elements is float,
but it doesn't determine fully the underlying representation type
(could be float32 as well as float64), nor the layout of the array
(could be C or Fortran layout).  

Thus, the assignment cannot be inlined and must be performed by a C
function that discriminates at run-time on the actual representation
types and layout.  This is quite slow indeed.  To avoid this, consider
adding a type constraint:

        open Bigarray

        type floatarray = (float, float64_elt, c_layout) Array1.t

        let f (a: floatarray) = a.{0} <- 3.14

That should improve performance somewhat.  Still, the extra
flexibility of bigarrays over regular arrays causes the inlined
bigarray access code to be a bit slower than regular array accesses.

Hope this helps.

- Xavier Leroy

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: