[e-lang] Multi-Core Processor Software

David Hopwood david.nospam.hopwood at blueyonder.co.uk
Fri Feb 23 22:53:56 CST 2007


Bill Frantz wrote:
> At our Friday meeting, Alan, Chip, Norm, and I discussed software
> approaches to make use of multi-core processor architectures.  We noted
> that Intel has announced that they will be delivering 80 cores on a chip
> in 5 years.  One interesting observation we made is that if an E program
> is written to use all or mostly eventual sends, it might be possible to
> automatically break it into multiple vats, with the limit being one
> object/vat.

If a program used *only* eventual sends, then this would be trivial (you
would essentially have the actor model, which is easily parallelisable).

As soon as you have any immediate calls, this suddenly becomes much
more difficult, and I'm somewhat skeptical of doing it automatically. It's
not that it's an NP-hard problem; I just don't see any algorithm to do it
at all that would work for realistic E programs, and that wouldn't end up
with the trivial result of not being able to break up any vats.

In a strictly statically-typed language, especially one that is *not*
object-oriented, it would be feasible for a whole-program analysis to
generate a graph of potential callers and callees, and from that infer
where objects allocated in a particular expression can possibly get to.
In fact some language implementations already do something like that (in
order to eliminate locking for thread-local objects, for example). In a
soft-typed OO language, my intuition is that the call graph will usually
end up saying that (almost) anything can potentially call (almost)
anything else.

OTOH, I don't think that automatic parallelisation is really necessary.
I think that manually breaking up programs to use a larger number of vats
is likely to be quite feasible in most cases. Perhaps allowing limited
use of shared-state Software Transactional Memory (e.g. allowing *some*
objects to be explicitly shared between vats and atomically updated) would
make that easier.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>



More information about the e-lang mailing list