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