Re: [Caml-list] Bigarray map & set/get (long)

[Xavier Leroy <xavier.leroy@inria.fr>]

> Now, if I specify the
> full type of the arrays I want (here
> 
> type mat =
>   (float, Bigarray.float64_elt, Bigarray.fortran_layout) Bigarray.Array2.t
> 
> ) then the code runs much faster: 0.87 sec (still more than 5 times
> the C version unfortunately).  That sould be mentioned in
> http://caml.inria.fr/ocaml/speed.html IMHO -- and maybe this page
> could be better advertised?.

It should be mentioned, but really this is the same phenomenon as for
regular arrays: efficient array access code cannot be generated unless
the full type of the (big-) array is statically known.

> * The Lacaml modules does contain some "matlab like" operations on
>   vectors (and, in the future, on 2D arrays).  That will make easy to
>   write fast code for this example.  However, one thing that will
>   always be necessary is to make CAML functions act on arrays.

In the applications for which Bigarray was initially intended, the
Caml code that manipulates directly the bigarrays isn't
time-critical: the time-critical computations are done by external
libraries such as BLAS, Lapack, etc.  Your matrix multiplication code
is a good example: if you care about its performances, then you need
to make it a lot more sophisticated so that it will be cache-friendly
(e.g. blocking); better use an existing, well-tuned C or Fortran
implementation than try to do your own in Caml.

Put it another way, bigarrays are oriented towards efficient
communications with external libraries, not towards writing efficient
numerical code in Caml; for the latter purpose, regular arrays are
actually more efficient.

> * Are bound checks responsible for the difference between the "fully
>   typed" version [mac (out:mat) (a:mat) (b:mat) (c:mat)] and C??

Partially responsible, but another source of overhead is the
address computations when accessing a big array: these involve linear
formulas of the form X * dim1(a) + Y, which are not optimized inside
loops, while most C and Fortran compilers do extensive optimizations
for this kind of computations (hoisting of loop-invariant code,
transformation of multiplications into iterated additions, etc).

> P.S.  Is it possible to write a "let module A = B" (i.e., module
> renaming) in camlp4?

That's a standard feature of the OCaml module language; it's written
"module A = B".  What a surprise :-)

- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners