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 map & set/get (long)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Fernando Alegre <fernando@c...>
Subject: Re: [Caml-list] Bigarray map & set/get (long)
On Mon, Jul 22, 2002 at 11:31:36AM +0200, Xavier Leroy wrote:

> 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

However, the current implementation of bigarrays does not cooperate
with libraries that need to manage the memory allocation in special ways.
Some efficient libraries need special malloc and free that align the data
for faster cache use. But current bigarrays are unsafe in that kind of
setting. We had modify the source code of bigarrays (alloc and update_proxy)
so that proxies are also updated for externally allocated bigarrays, and
created custom bigarray_alloc and bigarray_finalize.

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

I have done somewhat extensive tests, and my results indicate that bound
checks are in fact the main source of slowdown. Address computation seemed
negligible in comparison. It was also surprising that setting a value was
much faster than retrieving it. Any ideas why this is so?


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