[MLton] approaches to parallelism in ML

[skaller]

On Tue, 2006-10-10 at 13:30 -0700, Kip Macy wrote:
> > 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).

What's T1/T2? Is that Sun stuff? That would be server class ..
of course multiple CPU boxes are available now, even for
AMD64 you can get an 8 CPU dual core board -- but you'd never use
one on a desktop, the fans would be too noisy (even one chip
with load controlled fans is too noisy .. I sleep 2 metres
from mine .. my next box is going to be water cooled :)

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

Yes but in practice the costs will be higher, and remember the
real comparison is with a concurrent collector running 1 thread
in parallel: that is going to be faster for sure, provided it
can keep up.

If you assume 20% of time is spent collecting, it means you
need 6 cores before you have to go to a parallel collector.

If you have a generational collector, then your major
heap collection is more likely to be 2% .. in which case
you only need a parallel major collection when you have
around 50 cores -- because minor heap collection is already
easily made parallel.

AFAIK in GHC the minor heap collection is already parallel, 
but the major heap is stop-the-world (i.e. not even concurrent).

Of course I'm guessing about the numbers -- 
and I don't have a 64 CPU box to test on (yet :)

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

I doubt the problem is with code generation as much as the
run time system and libraries -- they're hand written C
code which makes non-portable assumptions. In any case most 
of MLton compiler will probably
be doing high level stuff, and either won't be affected,
or be easy to modify.


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net