Re: [Caml-list] Comparison of OCaml and MLton for numerics

[Jon Harrop <jon@ffconsultancy.com>]

On Friday 01 June 2007 06:30:51 you wrote:
> Having said that, I don't see how opposing a more effective inlining and
> specialization strategy would let the programmers write better code.

My impression is that this is unsolved in the context of OCaml. The compiler 
lets you fiddle with the inlining threshold but the results are 
unpredictable: inlining often worsens performance in symbolic 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 :-/

I see no better alternative. In this case, I don't even think a well-written 
version would be significantly longer. Look at my ray tracer, the fast OCaml 
is as ugly as the fast C++ even though the C++ compiler does many of the 
optimizations that people have cited.

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

I think you should do whatever is clearest if you ask yourself such questions. 
Only rewrite in a more efficient form if the profiler tells you that you 
must.

I agree that more optimization by the OCaml compiler might be nice (e.g. 
specializing higher-order functions over float arrays) but I do not believe 
it would have helped in this case.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/?e