On 23/10/2007, Peter William Lount <peter at smalltalk.org> wrote:

[ your message was here ]
>  Peter William Lount
>  Peter at smalltalk.org
>
A BIG +1 to your point. You expressed most things which i had in mind
(i'm not native English speaker, so sometimes its hard to say what i
have in mind).

Absolutely, there is no magical cure for concurrency. And hoping that
we can deal with it by using __insert tool__ is an illusion.

And what is more frustrating (unfortunately), that a concurrency can
be solved only when we come to problem from both sides: VM and
language. By changing VM and not touching a bit in ST codebase we will
have a crappy solution. By changing ST codebase, but using old
one-threaded VM we have also crappy solution - while its very useful
for generic distributed computing its too ineffective for
computationally heavy problems (for example - raytracing). While you
can do things in parallel, but in the end you must gather results into
same memory space. Its good when your problem domain can be simply
splitted onto smaller parts, which can be computed in parallel and
overhead of objects serialization is too low comparing to time of
computing partial results. But as Peter said in general case we may
expect that overhead will be too high for some tasks, and some tasks
can't be parallelised at all making single OS process working, while
others simply hanging in memory eating space and consuming CPU
resources by computing nothing.

Also, by spawning parallel OS processes we hand over many aspects of
our parallel processing control to OS and losing many elegant and
simple solutions. For example, why i have to lose simple 'send and
receive' and be it replaced by 'send and pray' paradigm?

And don't take me wrong: i'm a big fan of spoon and Croquet islands,
still these solutions hardly can be considered as generic in
perspective of Multi-Core.
Lets make it clear: a Multi-Core is _NOT_ distributed computing. Yet
they have many in common, but to use them most effectively we need
different approaches.

-- 
Best regards,
Igor Stasenko AKA sig.