Time to think about parallel Smalltalk stuff
Matej Kosik
kosik at fiit.stuba.sk
Sun Jan 23 11:11:42 UTC 2005
Lex Spoon wrote:
> 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....)
I am thinking of a computational model without processes/threads/vats.
It is based on asynchronous message passing where *necessary*
synchronization happens differently than in normal concurrent languages.
My current attempt (not yet finished, I did not get to lot of important
things and there are no good examples)
http://altair.dcs.elf.stuba.sk/~kosik/V2.pdf
makes me believe that I am on the right way. It is an attempt to provide
the programmer with a concurrent computational model which is safe
(inherently interference-free) and live (inherently dead-lock free). I
have noticed that the philosophy of the Smalltalk could be transformed
from invoke/return model to eventual-send/future-like-return. The system
I am thinking of will have similar beauty as Smalltalk (everything will
be expresed by eventual-sends, everything is an object). That was my
previous attempt
http://altair.dcs.elf.stuba.sk/~kosik/V1.pdf
which moved me in the right direction. Its main problems were that
parallel activities/activations of objects were not able to cooperate
with shared object *automatically* safely (without interference). My
contemporary attempt solves that major problem.
The proposed computational model is not more difficult to use (to make
programs for it). It introduces fine-grain parallelity of the
computation (which could make the programs scalable on proper hardware)
and that it may cure the main Smalltalk's disseas. Smalltalk's images
were not able to communicate in normal ways *safely* and *lively*. It
inherited all the problems of sequential languages.
My computational model is suitable for general-purpose programming. It
is no tougher than normal sequential programming. It is currently immature.
>
> Second, a vat can be arbitrarily small.
I do not agree. Did you try it? The mechanisms provided by E are not
powerful enough to do so. For example, you will not be able express
branching by eventual-sends *safely*.
> 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.
I do not think that the Smalltalk's virtual machine could be patched
here and there to provide what I need. The whole model of computation
must change.
>
> 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.
The past showed two such directions (for fine-grained parallelism).
1. Data-parallel computation (the Cm-LISP running on Connection-Machine
(http://en.wikipedia.org/wiki/Connection_Machine) is perhaps the most
beautiful specimen). Its main disadvantage is that it is inherently not
suitable for general-purpose programming.
Solutions of some problems could be naturally expressed Cm-LISP but most
of them not.
2. Hewitt's Actors inspired many systems. The problem is how to extend
it to be able to deal with shared mutable objects *safely* and *lively*.
That is a problem I am solving and I believe that it is solvable.
I think that the second approach (though with some modifications) will
be able to:
* swallow the first approach
* conquer back the lost areas in personal computing
* conquer yet actually uncharted areas of distributed computing (for
example explicitely cooperating information systems)
>
>
> Lex
Mato
--
skype: matej_kosik
icq: 300133844
http://altair.dcs.elf.stuba.sk/wiki/Main/MatejKosik
phone: (421) 910-993-245
-=x=-
Skontrolované antivírovým programom NOD32
More information about the Squeak-dev
mailing list
|