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

[skaller <skaller@users.sourceforge.net>]

On Fri, 2007-06-01 at 07:30 +0200, Alain Frisch wrote:
> 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.

Clearly I'm not opposing anything: just making a point that there
is a good reason to have 'dumb' code: not that the reason is universal
or pervasive.

> Quite the contrary (manual inlining? come on...) in my opinion. 

Well actually, inlining is a good example to consider IMHO.

Good inlining algorithms are very hard. Felix relies *heavily*
on inlining to create optimisation opportunities via monomorphisation,
parameter replacement, and simply eliminating calling overheads.

But still, the algorithm is crude and I found it necessary
to allow:

	fun f ...           // maybe inline
	inline fun f 	    // try REALLY HARD to inline
	noinline fun f      // never inline


Whilst this isn't "hand inlining" it is a weak form of manual 
control over a difficult algorithm.

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

hehe .. obviously best to start off schiz, then there's no
problem becoming so! :)

>  or "should I
> restrict the type of this polymorphic function?" or "should I use
> Array.iter or write a for loop?" all the time. 

Or ..

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

.. choice of functors vs type variables for polymorphism? Which all
SML/Ocaml programmers have .. the language is clearly Schizoid here:)

We need a good doctor (theorist) to get rid of this malady.



-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net