[Caml-list] Re: OCaml speed

[Caml-list] Re: OCaml speed

[Rolf Wester]

Christophe Raffalli wrote:
> Rolf Wester a écrit :
> >
> > Hi,
> >
> > I used the array access example from
> > http://www.bagley.org/~doug/shootout/ to compare c/c++ speed against
> > ocaml. The sources I used are attached below. Unfortunately I could
> > not confirm the given cpu times which are 0.11 sec for gcc and 0.13
> > for ocamlopt. My results on a Compaq Alpha True64 are 0.05 for cxx,
> > 0.1 for g++ and 0.29 for ocamlopt. Does anybody have an idea what
> > could be the reason for this inconsistency? Did I do anything wrong?
> >
>
> Your code mainly does integer operations and array accesses.
>
> The main difference between C and Ocaml are the reserved bit in integer
> used by ocaml for the GC. Then the generated assembly code are really
> different and it is possible that this diffrence cost nothing (almost)
> on a pentium and a lot on a Alpha True64.
>
> May be Xavier Leroy could look at the assembly code to tell if I am
> right ?
>
> You could also try with float arrays which should make less difference
> for your code ?
>
I tried it with floats. The differences are quite similar. With -unsafe I
get a speedup of almost 100%.

I mostly do numerical computations with heavy use of arrays. OCamls
array performance is sufficient for some of my applications but there are
still quite a lot of problems that need better performance so I'm stuck
with C/C++ either as OCaml extension or without OCaml. I'm thinking about
a numerical extension written in C comparable to the Python Numpy package.
At the moment I try to interface with the FFTW library. The biggest
problem is that there is no OCaml build in type complex and that the
Bigarray doesn't have complex too (sometime ago I read that someone was
thinking about adding complex numbers to the Bigarray module, I would
appreciate this very much).

Rolf Wester
-------------------------------------
Rolf Wester
rolf.wester@ilt.fraunhofer.de
-------------------
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

Re: [Caml-list] Re: OCaml speed

[Markus Mottl]

Rolf Wester schrieb am Dienstag, den 06. November 2001:
> I'm thinking about a numerical extension written in C comparable to
> the Python Numpy package.

If you want, you might consider steeling some code from (even better:
adding some code to ;) Lacaml:

  http://lacaml.sourceforge.net/

It's intended as a low-level library that should support the
Fortran-interfaces of BLAS/LAPACK with Bigarrays as close as possible +
some extras, which are written in C.

Currently only the functions that I need are implemented (mostly linear
regression stuff), but adding further ones is very easy. You may also
want to write a higher-level maths package that makes use of this
low-level library.

> The biggest problem is that there is no OCaml build in type complex
> and that the Bigarray doesn't have complex too (sometime ago I read
> that someone was thinking about adding complex numbers to the Bigarray
> module, I would appreciate this very much).

Xavier once told me that he is intending to add support for the complex
domain to the Bigarray-module. I don't know whether this will be possible
for the next release. It's not important to me, because I (currently)
don't need complex numbers.

Regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
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

Re: [Caml-list] Re: complex bigarrays

[Xavier Leroy]

> The biggest problem is that there is no OCaml build in type complex
> and that the Bigarray doesn't have complex too (sometime ago I read
> that someone was thinking about adding complex numbers to the
> Bigarray module, I would appreciate this very much).

Adding complex arrays to the Bigarray module is on my to-do list.

One issue is how these arrays should be represented to allow
no-copying exchange between C and Fortran.  My understanding is that
in C, arrays of complex are generally represented as arrays of pairs
of floats (or doubles), while in Fortran some codes use the C
representation (one array of pairs) while others use a pair of arrays.
The array-of-pairs representation fits well the Bigarray interface,
but the pair-of-arrays approach does not.  

Could someone with numerical experience in Fortran provide more
information on this?

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

Re: [Caml-list] Re: complex bigarrays

[Rolf Wester]

Hi Xavier;

can you please tell me when this complex Bigarrays are likely to be
available?

Rolf Wester
-------------------------------------
Rolf Wester
rolf.wester@ilt.fraunhofer.de
-------------------
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

Re: [Caml-list] Re: complex bigarrays

[Thorsten Ohl]

Xavier Leroy writes:

> while in Fortran some codes use the C representation (one array of
> pairs) while others use a pair of arrays.

>From section 4.3.1.3 of the Fortran standard:
    
    The values a complex type are ordered pairs of real values.  The
    first real value is called the real second real value is called
    the imaginary part.

and from section 14.6.3.1 of the Fortran standard:

    (1) A nonpointer scalar object of type default integer, default
    real, or default logic occupies a single numeric storage unit;

    (2) A nonpointer scalar object of type double precision real or
    default complex occupies two contiguous numeric storage units;

If you declare

      COMPLEX C(2)

it is layed out as

      Re[C(1)] Im[C(1)] Re[C(2)] Im[C(2)]

Fortran compilers have no freedom here, because they must support
EQUIVALENCE and COMMON aliasing.

OTOH, there are many numerical libraries (e.g. LAPACK) that
explicitely declare two REAL arrays and use the entries as real and
imaginary parts.  However, this is a library choice and sidesteps
Fortran's COMPLEX type altogether.

-- 
Thorsten Ohl, Physics Department, TU Darmstadt -- ohl@hep.tu-darmstadt.de
http://heplix.ikp.physik.tu-darmstadt.de/~ohl/ [<=== PGP public key here]
-------------------
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

Re: [Caml-list] Re: complex bigarrays

[Thorsten Ohl]

shiv@mac.com writes:

> But most of the LAPACK complex routines do expect to see regular
> FORTRAN COMPLEX arrays

You're right.  I was incorrectly generalizing from DGEEV etc. that
take real arrays as input return (among others) complex vectors.  The
latter are represented as two real array.  Routines that take complex
inputs represent them as COMPLEX arrays.

> So I would vote to represent complex bigarrays using a single array 
> with real and imaginary parts of each element adjacent to each other in 
> that order.

I fully agree.  Even if my generalization had been correct, I would
still have voted for this, because it conforms to the Fortran language
definition.

> I have read (some where) that this might cause problems with some C
> compilers on some machines. That is, if we define struct {float re;
> float im} A[10]; Then the entries in A may not be packed together as
> we might expect.

AFAIK, the C compiler is free to pad structures for better alignment,
resulting in better performance.  Isn't it even free to reorder
elements?
-- 
Thorsten Ohl, Physics Department, TU Darmstadt -- ohl@hep.tu-darmstadt.de
http://heplix.ikp.physik.tu-darmstadt.de/~ohl/ [<=== PGP public key here]
-------------------
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

Re: [Caml-list] Re: complex bigarrays

[Joerg Czeranski]

On Thu, 8 Nov 2001 18:56:09 +0100
Thorsten Ohl <ohl@hep.tu-darmstadt.de> wrote:
> shiv@mac.com writes:
> > I have read (some where) that this might cause problems with some C
> > compilers on some machines. That is, if we define struct {float re;
> > float im} A[10]; Then the entries in A may not be packed together as
> > we might expect.
>
> AFAIK, the C compiler is free to pad structures for better alignment,
> resulting in better performance.  Isn't it even free to reorder
> elements?

No, it isn't.  Order must always be preserved, and no padding is allowed
in front of the first component.

You can always use an array of two elements for each complex:
float A[10][2];  (Or rather typedef float complex_t[2]; complex_t A[10];)
Then the compiler isn't allowed to use any padding.

C99 has introduced complex float, complex double, complex long double,
but I don't think there's a definition of the representation.

regards,
jörch
-------------------
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

Re: [Caml-list] Re: complex bigarrays

[Ken Rose]

Thorsten Ohl wrote:

> AFAIK, the C compiler is free to pad structures for better alignment,
> resulting in better performance.  Isn't it even free to reorder
> elements?

No, it's not free to reorder them.  C89, section 6.5.2.1 semantics,
paragraph 9

"Within a structure object, the non-bit-field members and the units in
which bit-fields reside have addresses that increase in the order in
which they are declared."

They can be padded anywhere except at the beginning.

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

Re: [Caml-list] Re: complex bigarrays

[David McClain]

> AFAIK, the C compiler is free to pad structures for better alignment,
> resulting in better performance.  Isn't it even free to reorder
> elements?

No C compiler in its right mind would dare reorder the elements of an array
or struct.... padding is another issue. C is a high-level Assembly language,
and as such it produces what you write for the most part.

I used to write C compilers for a living, and I became intimately familiar
with the old specs... I used to be able to write C and see in my mind as I
went along, exactly which registers were being banged on (back in the days
of the MC680x0).

If this implicit contract were broken by some vendor an enormous amount of
legacy code would also break. They wouldn't dare!!!

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