Re: [Caml-list] Q: Efficient operations on complex numbers

[Xavier Leroy <xavier.leroy@inria.fr>]

> > 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