From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA18238; Mon, 22 Jul 2002 17:43:31 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA18233 for ; Mon, 22 Jul 2002 17:43:30 +0200 (MET DST) Received: from gato.phys.clemson.edu (gato.phys.clemson.edu [130.127.188.133]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g6MFhST15187; Mon, 22 Jul 2002 17:43:28 +0200 (MET DST) Received: from adsl-156-180-196.gsp.bellsouth.net ([66.156.180.196] helo=elefante.local) by gato.phys.clemson.edu with asmtp (Exim 3.35 #1 (Debian)) id 17WfLK-0006Gz-00; Mon, 22 Jul 2002 11:43:26 -0400 Received: from oso.local ([192.168.1.3]) by elefante.local with esmtp (Exim 3.35 #1 (Debian)) id 17WfLV-0000Pr-00; Mon, 22 Jul 2002 11:43:37 -0400 Received: from fernando by oso.local with local (Exim 3.35 #1 (Debian)) id 17WfLJ-0001Xe-00; Mon, 22 Jul 2002 11:43:25 -0400 Date: Mon, 22 Jul 2002 11:43:25 -0400 To: Xavier Leroy Cc: Christophe TROESTLER , "O'Caml Mailing List" Subject: Re: [Caml-list] Bigarray map & set/get (long) Message-ID: <20020722154325.GH2940@oso.local> References: <20020719.155940.19123621.Christophe.Troestler@umh.ac.be> <20020722113136.A10720@pauillac.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020722113136.A10720@pauillac.inria.fr> User-Agent: Mutt/1.3.28i From: Fernando Alegre Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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