RE: [Caml-list] Caml productivity.

["Pal-Kristian Engstad" <engstad@naughtydog.com>]

I am also quite surprised by ocaml's speed. It's doing quite well on a lot
of platforms. And I would concur that it does quite well when compared to C
and Fortran. However, that is not quite enough. For me, it isn't enough that
the compiler is doing a decent job. I want to have the capability to make
the code even better. To do that, one needs to be able to make use of the
hardware, i.e. get down to the bare bones of your platform. Yes, it will
mean that you are giving up portability. Yes, it might be "unsafe", but then
again, why are there unsafe set and get operations for arrays in ocaml?

Now, I am not saying that C or C++ is inherently that much better. Even
gcc's inline syntax is really awkward in practice. But I would love to see a
superior system in ocaml! So, what is needed in order to support inline
assembly in ocaml? Is it at all possible?

Imagine that there is a special LZWC instruction that counts the number of
leading zeroes in a 64-bit word. I would love to be able to write something
like:

let lzc (x:int64) = inline
regs res : int32 of  (** Work registers **)
lzwc res, x (** Opcodes sent to the assembler **)
return res              (** result of the computation **)

let main =
	Printf.printf "lzc %d = %d\n" 12 (lzc 12)

PKE.

-----Original Message-----
From: owner-caml-list@pauillac.inria.fr
[mailto:owner-caml-list@pauillac.inria.fr]On Behalf Of William Chesters
Sent: Saturday, July 20, 2002 8:16 AM
To: caml-list@inria.fr
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_
serious.

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

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