Re: [Caml-list] Alternative Bytecodes for OCaml

["Basile Starynkevitch [local]" <basile.starynkevitch@inria.fr>]

On Sat, Aug 28, 2004 at 08:38:35AM +0900, Yamagata Yoriyuki wrote:
> From: Richard Jones <rich@annexia.org>
> Subject: Re: [Caml-list] Alternative Bytecodes for OCaml
> Date: Fri, 27 Aug 2004 23:18:01 +0100
> 
> The doc is somewhat vague, but Parrot seems to use conservative
> mark&sweep GC.  http://www.parrotcode.org/docs/pdd/pdd09_gc.html
> 
> There are a lot of people in academia in this list.  Maybe
> OCaml->Parrot compiler is a good project for undergraduates?

Unfortunately, I am not sure it would be a good thing - and I think
that it is quite sad that Parrot designers did not consider more
cooperation (or feedback?) with the functional language communities.

I think that Ocaml programs

  use a lot of "tuples", as seen by the runtime system (ie a tagged
  block of value pointers) ; tuples are essential in Ocaml for tuples
  and recorda in the Ocaml source language.

  need to allocate tuples quickly (because functional programming style
  means lots of allocations of small immutable tuples), and to test
  quickly the tuples' tag, and to fetch quieckly the n-th component of a
  tuple (for implementation of pattern matching)

  need to have efficient closures - quickly allocated, and quickly
  applied (both thru ordinary and tail-recursive terminal calls).

Unfortunately, Parrot http://www.parrotcode.org/docs/intro.html
implement all structured objects as PMCs, which are opaque data chunks
on which all operations goes thru a table of functions (similar to C++
vtables). So, using PMCs for tuple implementations would require an
indirect call (even with Parrot JIT technology) for every basic tuple
operations (ie allocation, tag fetching, field fetching). Also, I am
not sure that Parrot has terminal (tail recursive) calls which are
essential to Ocaml (and other functional languages).

So, I would guess that a Parrot-based Ocaml implementation (even using
Parrot JIT technology) would probably be at least two times slower
than the current ocaml byterun implementation (hence about 4 times
slower than my OcamlJitRun implementation, at least on x86).

An alternative not yet considered in this interesting "bytecode"
related thread would be to *extend* a competitive VM (eg Parrot, or
maybe CLR or JVM) to add the few features needed to Ocaml, notably:
quick tuple allocation & access (both to fields and to tag), quick
closure allocation and application, tail-recursive calls.

Alos, note that Ocaml (and other functional languages) need a
performant garbage collector (because immutable tuples and closures
are allocated and accessed a lot), and that conservative GCs (à la
Boehm) have lots of interesting features (in particular,
conservativeness which makes then C-friendly, and multithreading), but
are slower than naive generational copying precise GC (see
http://starynkevitch.net/Basile/qishintro.html for some benches).


So, instead of porting Ocaml to Parrot, I would favor an extension of
Parrot (or any other competitive VM) - by adding the few needed
features suggested above) and then a port of the Ocaml compiler to
this extended VM. I do recognize that it is a big work, and that the
result might be disappointing (in terms of performance at least)
w.r.t. the current Ocaml bytecode VM.


Regards.


NB: in this post, all tuples are (unless explicitly said) in the
runtime sense of a tagged block of GC-ed pointers - not in the Ocaml
source sense. tuples (in the runtime sense) implements both Ocaml
tuples & records.

-- 
Basile STARYNKEVITCH -- basile dot starynkevitch at inria dot fr
other email : basile at starynkevitch dot net
Project cristal.inria.fr - temporarily
http://cristal.inria.fr/~starynke --- all opinions are only mine 

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