]> 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? Thanks, Fernando ------------------- 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