Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Ocaml efficiency
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Xavier Leroy <xavier.leroy@i...>
Subject: Re: [Caml-list] Ocaml efficiency
>   Some people are sometimes writing or thinking about writing
>   applications in OCaml without knowing it OCaml is suitable
>   for the kind of applications they're writing.
> 
>   So my question is for what kind of applications isn't OCaml
>   suitable for and better written in a lower lever language?

One example is software components that take a low-level view of the
memory (as an untyped collection of bytes or words accessed via
addresses): memory managers, garbage collectors, device drivers, and
to some extent virtual machine interpreters.

Another example is heavy-duty number crunching, either on floats
(simple, brute-force numerical methods on dense matrixes; signal
processing) or integers (cryptography, compression, signal processing).

In both cases, OCaml will not only give you lower performance than
say C, Fortran or assembly, but the OCaml code will not be
cleaner nor easier to write than the C or Fortran code.

Caml becomes interesting again as soon as your application manipulates
higher-level data structures, or performs significant amounts of
dynamic allocation, though.

>   What is the real cost (in CPU) of interfaces to C libraries
>   since some processing have to be performed in order to convert
>   lower level types to Caml types?

You probably need to do your own measurements here, but the cost can
be quite low.  For instance, consider a C function that is the
identity on Caml integers, i.e. it takes a Caml integer, converts it
to a native integer, then back to a Caml integer, and returns this.
One call from OCaml to this function takes approximately 16 cycles
on a Pentium III and 50 cycles on an Alpha 21164.  (The Alpha suffers
from a more expensive Caml/C context switch and a less efficient
branch prediction engine.)

Caml/C conversions on other data types can be more expensive, though.
Still, as long as the C function does some real work (e.g. 1000 cycles
of computation), the overhead of calling it from Caml should be
negligible.

- 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