[MLton] approaches to parallelism in ML

[Stephen Weeks]

> if someone wants to invest the time in a low-level target, their
> best bet is to write a MLRISC or C-- or LLVM codegen, and gain
> multiple targets at one go.

It's hard to argue with the logic here.  But I will point out that one
possibly serious drawback of using one of those projects is having to
deal with a moving target and bugs that are beyond our control.  I
believe it would have been a mistake had we chosen to use MLRISC or
C-- at the time we added MLton's x86 codegen.  Also, witness the
difficulties that Matthew encountered with his C-- MLton backend.

> How much of a performance gain do generated executables get from the
> NCG?

The link that Matthew sent

   http://mlton.org/pipermail/mlton/2005-June/027143.html

showed an average 35% hit for using the C codegen.  My rule of thumb
is no worse than a 2X slowdown, and usually less than 50%.  This on
x86 of course.  It's quite possible that the hit on other, less
forgiving, platforms is worse.

> LLVM appears to be the most actively developed of the three. Is this
> correct? Would porting to one of these be the same amount of work as
> to a specific architecture?

As a rough guess, yes.  Although my above point about instability does
apply.  LLVM is a less stable target than SPARC assembly.