Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Caml productivity.
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-07-26 (21:07)
From: Pal-Kristian Engstad <mrengstad@y...>
Subject: Re: [Caml-list] Caml productivity.
I agree that the C interface is pretty nice. However,
how do would you use SIMD math instructions on the
x86? Would you always call C-routines just to make use
of SIMD or multimedia-instructions? What is the
overhead for calling a function that is executing a
few assembly instructions? Is it even possible to
create a solid division line between "low-level" and
"high-level" code? 

There's something to be said for premature
optimizations, but don't you think there's something
to be gained from having inline assembly in O'Caml? In
C++, one can create inline SIMD floating point vector
operations. A.I. and behaviour code constantly use 3D
math that would benefit from inline assembly.


--- Travis Bemann <> wrote:
> On Mon, Jul 22, 2002 at 10:46:35AM -0700,
> Pal-Kristian Engstad wrote:
> > Hi,
> > 
> > Nicolas Cannasse seems to believe that
> "productivity"
> > and "performance" are orthogonal concepts. They
> are
> > not always. For some tasks the performance of the
> > algorithm determins if the program can be put into
> the
> > application. Hence, if the program executes too
> > slowly, the program is useless and the time spent
> on
> > it was a waste. In other words, there was no
> > productivity at all.
> > 
> > I commend Nicolas for trying to use O'Caml in a
> games
> > setting. We, however, can not afford this -
> instead
> > the company designed and implemented a specific
> > language in order to be able to optimize _and_ be
> > productive. This language has high-level
> constructs as
> > well as low-level constructs --- and they can be
> > freely mixed.
> Actually, speed-wise natively compiled OCaml (on at
> least x86; I
> haven't seen benches for other architectures) is
> slightly faster than
> C++ compiled by gcc 3.0, and slightly slower than C
> compiled by gcc
> 3.0.  OCaml does have an excellent C binding
> facility, which makes it
> easy to interface between OCaml and C code (so
> therefore one can use C
> for extremely speed-critical code while writing most
> other code in
> OCaml).  Thus, I see little advantage to writing a
> whole new natively
> compiled language (which would require writing a
> whole new code
> generation and optimization layer, which would be
> extremely
> time-intensive, unless such a language were
> "compiled to C" as things
> such as GCL (GNU Common Lisp) do) rather than simply
> using OCaml with
> speed-critical or otherwise extremely low-level code
> in C.
> -- 
> Yes, I know my enemies.
> They're the teachers who tell me to fight me.
> Compromise, conformity, assimilation, submission,
> ignorance,
> hypocrisy, brutality, the elite.
> All of which are American dreams.
>               - Rage Against The Machine

> ATTACHMENT part 2 application/pgp-signature 

Do You Yahoo!?
Yahoo! Health - Feel better, live better
To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: