[MLton] approaches to parallelism in ML

[Matthew Fluet]

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

The external dependency is a concern.

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

I would say that porting to one of these projects is actually 
significantly easier than a native codegen.  My "port" to C-- was the work 
of two weekends to get something that successfully compiled almost all 
benchmarks.  The advantage of these projects is that they are providing 
register allocation, calling convention implementation, etc.  Yes, if they 
get one of those facets wrong, you need to wait for a bug fix from them.