Smalltalk › Squeak › Squeak - Dev

[squeak-dev] The "correct" approach to multi-core systems.

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

26 messages Options

Igor Stasenko

Re: [squeak-dev] Re: The "correct" approach to multi-core systems.

On 02/03/2008, nicolas cellier <[hidden email]> wrote:

> Igor Stasenko a écrit :
>
> > On 02/03/2008, Jason Johnson <[hidden email]> wrote:
>
> >> But the question is, where do you make your trade offs. If you take
> >> the simple way *for you* then just give access to threading to
> >> everyone and let them suffer with the pain of a paradigm too complex
> >> to be done correctly.
> >>
> >> If you take the way that's simply for *everyone else* then you put
> >> this sharing inside the VM in the places it makes since and hide it
> >> from the language level (e.g. how at least Erlang does it)
> >>
> >>
> > I'd vote for *everyone* - put threading control at language side, as
> > everything else in smalltalk. Any 'magic' should be a code which i can
> > read and change, placed in image, not in VM.
> > No-magic is the spirit of smalltalk, after all.
> >
>
>
> Yes but the spirit is also to build a VM able to hide some low level
> details like memory allocation...
> Smalltalk programmers are released from these release problems...
> Free to concentrate on higher level problems.
>
> Wouldn't this apply to threads too?
>

It is, but developers should be free in choice whether use locking

semantics or use vats/islands/E.
Simply because there is no single, ultimately best solution for all
kinds of parallel computing.

>
> Nicolas
>
>
>

--
Best regards,
Igor Stasenko AKA sig.

Andreas.Raab

[squeak-dev] Re: The "correct" approach to multi-core systems.

In reply to this post by Jason Johnson-5

Jason Johnson wrote:
> As far as what advantage this approach provides in general: it allows
> the VM to fully take advantage of multiple threads on a system without
> exposing "real" threading to the language.

But that's exactly what Hydra does (thus my question). Hydra uses
separate object memories for (as you phrase it) "on OS-thread per
scheduler". Therefore it allows all the existing code to continue to run
with the current assumptions about threading (i.e., green threads only)
and requires new code to be explicit about the concurrency model it
assumes (i.e., channels for communication between the images).

Cheers,
- Andreas

Andreas.Raab

[squeak-dev] Re: The "correct" approach to multi-core systems.

In reply to this post by Nicolas Cellier-3

nicolas cellier wrote:
> Yes but the spirit is also to build a VM able to hide some low level
> details like memory allocation...

As well as the details of method lookup etc.

> Smalltalk programmers are released from these release problems...
> Free to concentrate on higher level problems.
>
> Wouldn't this apply to threads too?

Absolutely. What we need is a *model* of concurrency (just like we have
a *model* for managing memory a *model* for sending messages, a *model*
for linked stack frames) and then have the VM implement that model of
concurrency as effectively as possible.

Cheers,
- Andreas

Francisco Garau-2

Re: [squeak-dev] Re: The "correct" approach to multi-core systems.

"Andreas Raab" said:
>
> Absolutely. What we need is a *model* of concurrency (just like we have a
> *model* for managing memory a *model* for sending messages, a *model* for
> linked stack frames) and then have the VM implement that model of
> concurrency as effectively as possible.

Out of curiosity, are those models exposed as Smalltalk objects?

My interest is not to have the most efficient VM implementation but to gain
understanding on how the Garbage Collector or the PIC works.

I am thinking about something like Dan Ingalls presented in ESUG 2004 where
he showed different Smalltalk versions (72, 76, 80) running on top of
Squeak. He mentioned that the overall speed of the interpreted system was
comparable to the original one running on the xerox machines.

Cheers,
Francisco

Jason Johnson-5

Re: [squeak-dev] Re: The "correct" approach to multi-core systems.

In reply to this post by Igor Stasenko

On Sun, Mar 2, 2008 at 10:42 PM, Igor Stasenko <[hidden email]> wrote:
>
> > Wouldn't this apply to threads too?

Absolutely.

> It is, but developers should be free in choice whether use locking
> semantics or use vats/islands/E.
> Simply because there is no single, ultimately best solution for all
> kinds of parallel computing.

There is no "best" solution for memory management either. I'm sure it
would be trivial to make some kind of memory management scheme that
would work better for most applications running on GC's now, but the
productivity gain we get from GC's makes it worth it, and we can use
that extra time to find better GC algorithms.

Threading is no different; you can certainly find cases where
Vats/Messaging/whatever isn't the very best possible solution, but in
the vast majority of the cases it will be good enough and it saves the
developer huge time.

Jason Johnson-5

Re: [squeak-dev] Re: The "correct" approach to multi-core systems.

In reply to this post by Andreas.Raab

On Sun, Mar 2, 2008 at 10:47 PM, Andreas Raab <[hidden email]> wrote:
>
> But that's exactly what Hydra does (thus my question). Hydra uses
> separate object memories for (as you phrase it) "on OS-thread per
> scheduler". Therefore it allows all the existing code to continue to run
> with the current assumptions about threading (i.e., green threads only)
> and requires new code to be explicit about the concurrency model it
> assumes (i.e., channels for communication between the images).

Very cool, sounds like a nice project. Sorry for not being
knowledgeable about it, but as I said, I wasn't speaking to Hydra at
all but rather answering someone's "in general" question with an "in
general" answer. :)

Thanks for the information, I will definitely make a point to look into it.