[MLton] approaches to parallelism in ML

Kip Macy kmacy at fsmware.com
Tue Oct 10 13:30:20 PDT 2006

> I hear from my local computer shop 4 core AMD64 will be
> available commercially next month .. the time may be
> sooner than they think :)

Single chip commodity hardware with 32 threads (T1) is already available
and 64 threads will be available shortly (T2).

> > Perry Cheng's work indicates that a parallel GC does
> > incur sufficient additional overhead to not make sense in a UP
> > context, but can in an SMP context can provide substantial benefit.
> Cheng describes a *parallel* collector of interest only when
> you have around 64 processors. It is a step beyond a 'merely'
> concurrent collector, which has one collector thread.
> Such a concurrent collector can collect for multiple
> worker threads on small numbers of CPUs, and is sufficient
> for desktop machines for some time, probably another decade.

His test cases were for 1-8 cpus and 4-32 cpus. If you look at his
graphs you'll see that even in the 2 cpu case a speedup was achieved.
Thus, I disagree.

> > How do mlton developers feel about supporting same address space
> > parallelism in mlton?
> They need to get the 64 bit port going before worrying
> about such luxuries .. no one is going to run significant
> SMP apps on a 32 bit machine :)

I didn't realize that it couldn't even generate C code for x86_64. That
is obviously critical.


More information about the MLton mailing list