Multy-core CPUs

Jason Johnson jason.johnson.081 at gmail.com
Sun Oct 21 20:44:01 UTC 2007


On 10/21/07, Igor Stasenko <siguctua at 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.



More information about the Squeak-dev mailing list