[MLton] Multicore CPU's and MLton

[Neophytos Michael]

--- Matthew Fluet <fluet@cs.cornell.edu> wrote:

> 
> > Anway, I was wondering is there any quick and dirty way for MLton to 
> > take advantage of that extra core... SML/NJ CM has a parallel build.. 
> > option which is nice.. 
> 
> But SML/NJ's parallel build just launches a separate sml process and 
> coordinates which source files it should compile.  I.e., it is process 
> level parallelism, not thread level or even SML function level 
> parallelism.
> 
> > but it seems like the whole program approach to 
> > MLton seems to be in conflict with the hardware CPU trends... 
> 
> Perhaps; I don't actually understand multi-core...  From the application 
> level, do they look any different than a SMP system?  Which is to say, 
> I've been running dual processor systems for over 5 years now, and I've 
> never felt like I needed more parallelism in any application.  I want 
> multi-processors so that I can run multi processes -- a mlton build, xmms, 
> oggenc, mythtv, etc. -- simultaneously.

>From the application level they look exactly like an SMP system.  It's just a
cheaper way to build an SMP system.

> Anyways, I just don't get the hype around multi-core, because it seems to 
> have started this frenzy that suggests that there is all this parallelism 
> that has just been languishing due to the lack of sufficient processing 
> units -- when, it's just the opposite.  We can't even keep a modern 
> processor's pipeline full for more than a few cycles at a time, let along 
> more than one.

Some of it is hype and some of it is not.  To you it may be, given the kind of
applications you want to run on an SMP machine (i.e. separate processes).  But
there are applications out there where it isn't hype at all.  I value
multi-dimensional integrals for a living, mostly in Monte Carlo.  And there
isn't a more embaracingly parallelisable algorithm on the face of this earth
than MC.  I typically get more than a factor of 2 speedup on a 2-way SMP
machine (sometimes more due to the extra cache of the second CPU and so on). 
Other algorithms for valuation are also parallelisable (trees, or finite
difference methods ...).

The fact that I can't use mlton to do this kind of work is regratable.  As to
what kind of model one adopts for GC, I personally would be happy even with the
simplest one (stop all the mutators and run the single collector) -- even this
is better than nothing.  If I could get pre-emptive threads, I would be happy
to make sure that my programs don't allocate much when the main thread forks.

> > On, a related note. are there any cool opitmizations that could be 
> > applied to make ML programs more concurent in a some what transparent 
> > way. 
> 
> Perhaps.  The mostly-functional nature of ML seems to suggest that it is 
> parallelizable, but not that even pH (parallel Haskell) didn't make much 
> headway.
> 
> > Multi-core systems with lots of concurent threads seem to be the 
> > future.
> 
> I'll believe it when I see it.  

I agree with Dan.  I don't think you will have to wait that long.

Neophytos



		
__________________________________ 
Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail