Multy-core CPUs

Igor Stasenko siguctua at gmail.com
Mon Oct 22 07:49:03 UTC 2007


On 21/10/2007, Jason Johnson <jason.johnson.081 at gmail.com> wrote:
> 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 there's nothing else, which can be a replacement to this model ,
then you don't have a choice, but use above.

>
> > 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.
>

Again, a question raised: how to ensure that messages are passed in
correct order and  make sure that messages are delivered?
Now lets look inside: to make it working properly, you need to
implement a message queue. And queue means that you must make an
'enqueue' and 'dequeue' operations  synchronized.
And that's exactly what i mean: even if you hide the concurrency
problems from the eyes of developer, this is not means that problems
are gone: now you have to deal with them by own.
If you know another way(s) how to make proper message passing scheme
without using synchronized object (such as queue), i am all ears.

-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list