Version française
Home     About     Download     Resources     Contact us    
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: -- (:)
From: William Chesters <williamc@p...>
Subject: [Caml-list] Caml productivity.
Pal-Kristian Engstad writes:
 > Some proponents of this mailing list seem to be
 > convinced that Ocaml is so much more productive than
 > C++. I find this to be a terrible mistake. From an
 > industry where performance is crucial (games
 > programming), I find quite a few aspects of Ocaml hard
 > to unify with productivity.

You are saying that for some tasks the superior productivity of ocaml,
in terms of development time, is irrelevant because you cannot achieve
the required level of performance.

I (myself, personally) thought your mail contained several
misconceptions about ocaml.  I work with C++ in HPC, and I've played
with a variety of different languages and coding idioms; I have to say
that ocaml is generally quite competitive with "general purpose" C and
Fortran compilers, if you write your inner loops in a Fortran style.

ocaml will lose in some cases against serious Fortran compilers that
do heavyweight HPC optimisations, but as far as I know very few C++
compilers have that capability (Intel's?).  And for some tasks the
superior performance of Fortran is irrelevant because you cannot
achieve the required level of productivity :-P.

ocaml also loses performances as soon as you start trying to put nice
abstraction features in the inner loops.  This is disappointing but
not specific to ocaml: templated inner loops in C++ are fast if they
only use scalars, but loops involving e.g. lightweight objects as
"iterators" are not, unless you are using the KAI compiler.

(Which has just been bought up and killed off by Intel, grrr.  KAI was
way ahead of its time; it really made it possible to write incredibly
"high level" C++ and get fast code out the back.  I wish all that
effort had been done in a university, put into a more sensible
language, and liberated so that nobody could take it away :( .)

I don't agree that the lack of operator overloading is a problem, per
se.  If you follow the argument (passim ad nauseam in the archives)
you eventually reach the conclusion that the real problem is that the
compiler doesn't inline across module boundaries---and that _is_

If access to machine-specific instructions is a problem, then ocaml
isn't the right tool.  Of course, if your uses of them occur in
library routines which can naturally be written in C, then you don't
have a problem.

In short, ocaml is really not so bad for high performance, provided
that you take care to write your inner loops in a "dumb" way and save
the nice language features for the rest of the code (and you have to
do that anyway, although maybe not so stringently, with C++).
To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: