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
Comparison of OCaml and MLton for numerics
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-06-01 (05:30)
From: Alain Frisch <Alain.Frisch@i...>
Subject: Re: [Caml-list] Comparison of OCaml and MLton for numerics
skaller wrote:
> So what I believe Jon and Xavier mean here is that the
> Ocaml compilers compile code down to stuff which is easily
> predicted in terms of the input syntax. no magic like
> invariant code motion: What You See is What You Get.

I generally agree that automatic optimizations should not change
too much the behavior of programs unless they are very easy to
understand and predict; indeed we don't want to rely on subtle
properties of the code and see the performances degrade unexpectedly
when we change a tiny thing.

Having said that, I don't see how opposing a more effective inlining and
specialization strategy would let the programmers write better code.
Quite the contrary (manual inlining? come on...) in my opinion. These
optimizations are not so much about producing more efficient programs;
there're about letting the programmer write cleaner code. So maybe the
current Ocaml compiler expects good code as Jon says, but it forces us
to write not-so-good one :-/  A functional programmer has reasons to
become schizophrenic if he must ask himself questions such as "should I
make this piece of code a function or write it inline?" or "should I
restrict the type of this polymorphic function?" or "should I use
Array.iter or write a for loop?" all the time. MLton's strength is that
you don't have to pay the price for abstraction, i.e. cleaning up your
program (by factorizing it or making it more modular) does not degrade
performance. I have no experience with MLton, but I don't believe that
performances are much more difficult to predict than with OCaml (Stephen?).