[MLton] questions on mlton

[Matthew Fluet]

Heath,

> I'm interested in using CML with mlton on the x86 with OpenBSD.

Great.  We'd be very interested in getting feedback on both CML and
OpenBSD, as they are new features with this release.

> Assuming I get my port working, I'll be doing a simple ping/pong
> benchmark under OpenBSD with sml/nj and mlton. As it is, I only have
> sml/nj.

As "port" and "ping/pong" can have a variety of meanings in the same
context, I'll try to address some issues that might arise.

If by "port" and/or "ping/pong" you mean someting to do with sockets, you
should be aware of a socket related issue on OpenBSD:
  http://mlton.org/pipermail/mlton/2004-June/015894.html
It seems that MLton is simply reflecting the OS behavior up to the
application (which we believe is the correct thing to do), but this means
that the behavior is different from other platforms.

If by "port" you mean modifying code from SML/NJ to MLton, that shouldn't
be an issue at the CML level.  The CML and related modules in MLton have
the same interface and semantics as the corresponding ones in SML/NJ
(although MLton does not (yet) provide a version of the Basis Library with
CML enabled IO).

As for "ping/pong," the MLton/CML sources has a test/ping-poing.sml
benchmark that measures how fast two CML threads can ping/poing back and
forth by send/recv on a channel.  The MLton sources has a regression
suite, including a number of which use MLton's threads; one is
prodcons.sml, which measures how fast produce/consumer threads can pass
data.

If on the other hand, "ping/pong" is networking, then you might look at
the Great Computer Language Shootout (http://shootout.alioth.debian.org/),
which, IIRC, has some client/server and echo benchmarks.  Some of those
benchmarks are also found in the regression suite of the MLton sources.
Although, I believe that these generally fork a process, rather than using
threads.

Finally, if indeed you are thinking of a networking benchmark, then I must
warn you that the missing IO functionality in the MLton/CML might be a
stumbling block.  Since there are not CML event versions of IO functions,
you will need to carefully wrap IO calls with MLton.Thread.atomically and
probably use some form of non-blocking IO and CML.timeout events (to
simulate sleeping).  Getting the Basis Library closer to thread safe and
providing event based IO are the next steps in MLton/CML; and I'm happy to
point anyone interested in working on in what I think are the right
directions.

> Is it correct that the essence of a CML port is getting the threads
> right? As you mention, it doesn't use many smlnj-isms.

Yes, overcoming the semantic differences in SML/NJ's first-class
continuations and MLton's first-class threads are the crux of
_implementing_ MLton/CML from SML/NJ/CML.  But, this is a ONE TIME cost --
a CML program should behave the same in both SML/NJ and MLton, without any
additional "porting" necessary.

> Is there any documentation for mlton's thread concept? I saw that this
> is an issue (in the port you had to change a few things), but I didn't
> get why the changes had to be made (something about crossing the
> threads).

The best documentation of the MLton's thread are the UserGuide entry:
  http://mlton.org/MLtonThread
which includes examples of building preemptive and non-preemptive
threads's on top of MLton's threads.

The problem in porting CML to MLton (in that one instance) is that MLton's
threads are essentially "one-shot" -- there is only one chance to switch
to them and start running.  SML/NJ's continuations are "may-shot" -- one
can restart them multiple times.  There details are bit subtle; I can try
to explain it a little more verbosely if you are interested.

> Also, I saw some comparisons between O'Caml and mlton. It looks like
> O'Caml was (is?) faster, in general, than mlton. Do you know if this
> is still the case? I can't really imagine using O'Caml (no CML, can't
> see how to port it myself), but I'm wondering if this is still the
> case.

I'd estimate that O'Caml and MLton are about even; if you are thinking of
the Shootout, then I'm pretty sure that O'Caml and MLton are about even.
I'd also guess that MLton would do even better than O'Caml on large
programs.  MLton shines on whole-program optimization, which single file
micro benchmarks don't really highlight.

> Also, I'm wondering if there are any resources related to mlton's
> runtime requirements. This was pretty well documented for sml/nj at
> some point. I'm wondering if it is feasible to use mlton in supervisor
> mode.

The whole-program analyses in the compiler can require large amounts of
memory; compiling MLton (over 140K lines) requires at least 512M RAM.  On
the other hand, the resulting executables do not (necessarily) require
signifcant memory.

There shouldn't be any problem running mlton (or mlton produced
executables) as root (or setuid).  There is a special compiler option
(-runtime no-load-world) that prevents the resulting executable from
loading some strange world.

If you are asking if one can run a MLton produced executable in the
kernel, I don't know.

Hope that answers some of your questions.