Time to think about parallel Smalltalk stuff

Lex Spoon lex at cc.gatech.edu
Thu Jan 20 01:41:53 UTC 2005


Matej Kosik <kosik at fiit.stuba.sk> wrote:
> Concerning E I have come to the following conclusion:
> 
> "E objects do not migrate (for security reasons). It makes it 
> unscalable. Also the existence of ''vat''-s is awful. It does not seem 
> to be suitable for fine-grained parallel computation because E's 
> constructs for asynchronous message passing are not powerful enough in 
> order for the programmer to be able to express everything solely by 
> means of them. Furthermore, the computation inside the ''vat''-s happens 
> in so called ''turns''. These turns cannot execute concurrently because 
> inside each turn programmers usually do normal call/return-s and thus 
> they would need to use additional synchronization mechanisms on the 
> shared mutable data.
> 
> E seems to be a good platform for creating loosly coupled (information) 
> systems."

I disagree with this analysis.  E's networking approach does not solve
the problem and tie a bow on it, but it moves you in the right
direction.

First, vats are a practical necessity for making parallel programs that
actually give correct answers.  If you have multiple user-visible
threads munging through the same heap, you are very likely to screw
things up.  Call them aweful if you like, but if you want to write
programs that are correct, then you need something like vats.  (Or, you
need to dip into formal verification....)

Second, a vat can be arbitrarily small.  It is a unit of organization,
much like a thread in a pthreads program.  If a programmer wants to have
lots of parallelism, and is willing to micro-optimize, then they can
create zillions of tiny vats which can then perfectly and safely run in
parallel.

Third, *Smalltalk* semantics is that bytecodes happen one after another.
 Smalltalk implementations are allowed to cheat, however, and run
bytecodes in parallel so long as they don't interfere.  Likewise, a
sophisticated E VM could run multiple turns in parallel, if it can 
determine that they won't interfere.  In general, automatic
parallelization in E is likely to be easier than in Smalltalk, because
the division into vats gives you a head start.  In particular, vats give
you free alias analysis.

Of course, someone should really go ask on e-lang.  I have found the E
guys to be very imaginative and to be ready to discuss a variety of
topics.  They aren't just security nerds; if they were, I doubt they
would have come up with the architecture they have.


Anyway, as far as I can tell on the subject of the thread, you want to
have a special language to get massive parallelism, not just a spiffy
VM.  If there were good compilers or VM's around that automatically
parallelized, then parallel processing would be much more popular than
it is.  Someone mentioned that Self got automatic parallelization to
about 5 processors.  There's a long way to go to get 100.  So, try
thinking of cool parallel operations, especially ones that avoid side
effects and thus can safely happen in arbitrary orders.


Lex



More information about the Squeak-dev mailing list