On 10/21/07, Igor Stasenko siguctua@gmail.com wrote:
Hehe, then all we need is to implement ST with Erlang and we are fine. Yes? :)
There is always room for improvement. Especially when we start getting more flexibility on the hardware side. But Erlang shows a good way of dealing with concurrency that Smalltalk can learn from.
I'm really pointing on, how efficient it can be (depends on proposed solutions) and what we can do to make good VM competing by speed with other language platforms. If we not taking speed into account, then there's nothing to talk about.
And don't tell me that trying to make ST to run as fast as can is pointless... Such thoughts are only for people, who taking a car and drive to wall-mart to buy a glass of water, located in 20 feets from their house.
Of course I care about speed. I have a few ideas for speeding Squeak up myself. But in this case don't assume that message passing is fundamentally slower. Keep in mind that in a pure message passing environment there are no locks to slow everything down, and the system is easier and more likely to be designed to maximize concurrent operations. So I would expect it to be faster then other approaches as the scale gets larger. Yaws vs. Apache is a perfect illustration of this.
As side note, i don't want to make one ST Process === single native thread. Such solution is really 'obsolete' and lead to nowhere. I'm talking about VM which conserves all CPU(s) power while managing execution/GC seamlessly to language. The in-language Processes and semaphores must not have any relation to native threads or number of cores. It's just a language level abstraction, nothing more. In that case, i can't see how 'manual fine grained locking' can do any harm.
The harm is that it's simply the wrong abstraction. Having the option there leads people to use it and gives us a code base that using a model that can't scale or compose.
If you need to synchronize access to some object you simply can't avoid that - at any level of abstraction (being in Erlang or OS, or assembler).
That's the point: you *don't* have synchronized access to any object. All you have is messages. Think of it as an OO view of processes. You can't see what's inside, you can only ask the process to do things on your behalf.