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 KAA10011; Sat, 24 Jan 2004 10:36:07 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id KAA10128 for ; Sat, 24 Jan 2004 10:36:06 +0100 (MET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id i0O9a5P23956; Sat, 24 Jan 2004 10:36:05 +0100 (MET) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA10174; Sat, 24 Jan 2004 10:36:04 +0100 (MET) Date: Sat, 24 Jan 2004 10:36:04 +0100 From: Xavier Leroy To: Nuutti Kotivuori Cc: Jan Kybic , caml-list@inria.fr Subject: Re: [Caml-list] Q: Efficient operations on complex numbers Message-ID: <20040124103604.A9502@pauillac.inria.fr> References: <87broukwzk.fsf@naked.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <87broukwzk.fsf@naked.iki.fi>; from naked+caml@naked.iki.fi on Sat, Jan 24, 2004 at 02:31:59AM +0200 X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 0.98:01 fishy:01 cmx:01 inlining:01 inlining:01 -inline:01 -inline:01 boxing:01 slower:01 implemented:01 boxing:01 unboxing:01 unboxing:01 compiler:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > > 3) I could improve the OCaml time to 0.98s by including the code > > from the Complex module in my source file. (Is there a way of > > achieving the same result without actually copying it?) On the other > > hand, it did not matter whether I used tuples or records to > > represent the complex numbers, whether I defined the 'add' and 'mul' > > functions locally or at the top level, and whether I asked the > > compiler to inline or not. > > I am not well versed enough to answer your other questions properly, > but this made me think there might be something fishy going around. > > OCaml doesn't inline functions from other compilation units right > now. Yes, it does, if the .cmx files for the other compilation units are available. So, I'm a bit surprised about what Jan Kybic observed. What I would have expected is that referring to the Complex module or copying it inside the source file shouldn't change the generated code, at least if you stay at the default inlining level. Whether a function from a module M is inlinable or not is determined when A is compiled, as a function of the inlining level (the -inline option) given for that compilation. Hence, copying the source for Complex in your module and compiling with high -inline could allow more inlining than what you'd get by referring to the precompiled Complex and setting a high -inline level. But you should get the same results by recompiling Complex with the same -inline level. Moreover, using tuples instead of records to represent complex numbers results in additional boxing and should therefore be somewhat slower. Coming back to Jan's initial question: > > So far, I have implemented a part of the computational kernel in > > OCaml that calculates approximations using spherical harmonics. It > > uses complex values. The Ocaml version is basically is straightforward > > rewrite of the C++ version and is almost exactly twice as slow as the > > C++ version. This is intriguing because the parts code that only uses real > > arithmetic is about as fast as the corresponding C++ version. So why > > is working with complex numbers so expensive in OCaml and what can be > > done about it? You're correct that boxing (of complex numbers) contributes significantly to the overhead. For float arithmetic, the OCaml compiler has special local unboxing elimination rules that enables it to avoid the overhead of boxing in many situations (but not always). These unboxing optimizations don't extend to data structures such as complex numbers. This said, a slowdown by a factor of 2 due to boxing alone is a bit surprising -- usually, it's more like 1.5. There might be other tricks that the C++ compiler plays and that OCaml doesn't. I'll look at your code more carefully when I have some more time. - 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