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

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

On Sun, 2007-06-10 at 13:10 +0100, Jon Harrop wrote:

> More generally, applications such as term rewriters can benefit from 
> specialized higher-order functions that incorporate this physical equality 
> based optimization. My term rewriter used an "id_map" function:
> 
> val id_map : ('a -> 'a) -> 'a array -> 'a array
> 
> which returns the input when possible. This can avoid a lot of unnecessary 
> allocation during rewriting and doubled the performance of the whole program!

Generally this often comes up rewriting terms:

	match x with
	| A a -> A (f a)
	| B b -> B b
	| ...

This is slower than

	match x with
	| A a -> A a
	| B _ as p -> p
	| ...

for the same reason: it avoids creating a new term equal
to the old one by just using the old term. This is particularly
useful with polymorphic variants:

	| #subtype as s -> s

In general though, Ocaml won't attain the performance Felix or
Mlton gain from whole program analysis, unboxing, and monomorphisation.
It compensates by providing (usually) rapid compile and build times,
a fast run time engine, and moderate optimisations.

It's somehow a pity the project isn't a bit more open, because
some of this stuff: more inlining, monomorphisation, additional
analysis, semantic axioms, etc, could be written by interested parties. 

However the only hooks available at the moment are in the 
front end with camlp4.

I might be interesting if the build system could "slot in"
third party analysis phases in a standardised way. The idea
here is that such modification would be strictly isolated,
extending the compiler by:

(a) an initialisation hook
(b) a term -> term analysis
(c) a command line switch to enable

so that the result is more or less guaranteed to be 
the standard Ocaml unless you switch on the extra feature.
When switched on, the analysis has an obligation to preserve
semantics (i.e. only optimisations are permitted).

With such a build system modification, more users could
choose to 'plug in' such optimisations in testing
builds of the compiler.

Obviously, such optimisations have limited opportunities
compared with arbitrary patches, but still, perhaps this
could provide a way for the community to build and assess
a limited but hopefully useful contribution. The INRIA team
could also supply testing optimisations using the same
mechanism.

With the bytecode compiler, it may even be possible to
direct loading of the optimisation phases dynamically
with the command line switches.

Well, I know nothing about the ocaml compiler at all,
so I have no idea whatsoever if this suggestion has
any merit. I do know, however, that at certain points
in compilation of Felix codes, it would be possible
to add in arbitrary optimisation passes which are close
to if not totally purely functional (and thus easy to
make optional).

I believe Mlton also supports "optional optimisations" at
various points in compilation.

How possible is this for Ocaml?

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