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 PAA17265; Thu, 8 Nov 2001 15:46:13 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA17415 for caml-list@pauillac.inria.fr; Thu, 8 Nov 2001 15:46:12 +0100 (MET) 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 VAA01513 for ; Wed, 7 Nov 2001 21:10:37 +0100 (MET) Received: from tcsnpop1.tcsn.uswest.net (tcsnpop1.tcsn.uswest.net [207.108.112.1]) by nez-perce.inria.fr (8.11.1/8.10.0) with SMTP id fA7KAa123487 for ; Wed, 7 Nov 2001 21:10:36 +0100 (MET) Received: (qmail 8742 invoked by uid 50); 7 Nov 2001 20:10:34 -0000 Delivered-To: fixup-caml-list@inria.fr@fixme Received: (qmail 8654 invoked by uid 0); 7 Nov 2001 20:10:32 -0000 Received: from 216-161-145-37.customers.uswest.net (HELO dylan) (216.161.145.37) by tcsnpop1.tcsn.uswest.net with SMTP; 7 Nov 2001 20:10:32 -0000 Message-ID: <004901c167c8$48c450f0$210148bf@dylan> From: "David McClain" To: References: <3BE94320.26654.1BF88274@localhost> Subject: Re: [Caml-list] Array Optimizations Date: Wed, 7 Nov 2001 13:10:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > P.S.: At the moment I write a wrapper for interfacing with a subset of FFTW. > I use Bigarray float64 as a complex array with re(i) = v.{2*i} and im(i)=v.{2*i+1}. > Does anybody have a better idea? FWIW, some time ago (a couple of years perhaps) I was faced with this decision, and more, in terms of interfacing to foreign numeric code and Matlab. As it happens, Matlab likes to allocate complex arrays as separate arrays of real and imaginary components. That may simplify some of their numeric coding, but I found that on PII and PIII architectures, the performance suffers tremendously due to cache thrashing. Better to use adjacent real and imaginary components. When I did the adjacent real and imaginary components, I did it just like you ask about above. What I find is that the OCaml performance, even with this doubling and offset by one, indexing is quite good. Especially important is to precompute these indices in the event of several array accesses inside of "for" loops. That helps enormously. My OCaml speeds indicate performance better than C/C++ coded internals in languages like RSI/IDL, by almost 2x. One can only wonder about the quality of the C/C++ code against which I was comparing -- that was out of my control. - David McClain ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr