Multy-core CPUs

Jason Johnson jason.johnson.081 at gmail.com
Fri Oct 19 20:20:04 UTC 2007


On 10/19/07, Peter William Lount <peter at smalltalk.org> wrote:
>
>  That may be the case from your - and others - perspective - and I have
> empathy for it -, however they are still valid techniques and others, such
> as myself, don't share your perspective.

Sure, just as manual memory management is still valid and needed at
the lowest levels of programming.  It's just not valid in most
applications.

>  Smalltalk should let people - the (educated) users - choose the mechanism
> of concurrency, not dictate it. In my humble opinion.

But herein lies the problem.  As discussed in the previous thread I
liked to; adding actor style message passing should be relatively
easy.  Adding state transactional memory is doable.  Making the Squeak
VM fully multi-threaded (natively) is going to be a lot of pain and
hard to get right.  Just ask the Java VM team.

The pay back of adding this obsolete (except in the lowest level
cases) method of dealing with threading just isn't going to be worth
the pain to implement it.

>  The reality of processor designs like the Tile 64 require us to have all
> available techniques at our disposal.

Why?

>  Exactly my point. Thus the solutions proposed as being "simplier" are just
> an illusion.

?  They are unquestionably simpler to the programmer who is using them
(which is what I meant).

> They might be simplier in some cases but when you really need
> complex concurrency controls sometimes you need the other "dirtier"
> techniques at your disposal.

This is like saying that Smalltalk is wrong to not expose manual
memory management to you for when you need to get "down and dirty".
It's simply not the case.  You move to a higher level, just as we do
with all abstractions.

> Smalltalk is supposed to be a computer language
> with general power to control the computer and access it's true power and
> potential. Limiting the solution space by only implementing a limited set of
> concurrency primitives makes no sense. You'll just give the market to other
> lesser systems like Erlang and Java type systems.

This last sentence is quite odd, and to be frank not well reasoned at all.

First of all Erlang is not lesser, it is in fact currently the leader
in this area.  It's funny though, that you suggest we would "give the
market over" to Erlang, since Erlang supports precisely *one* form of
concurrency:  share-nothing message passing.  Erlang can run in
multiple threads, but only the interpreter does that, and it's
transparent to the processes running in the VM.

Second of all, do you seriously think adding fine-grained threading to
Smalltalk automatically will cause it to take over the market?  Of
course not, everyone would just say "what?  You *just now* got that?",
except Erlang who would simply laugh at a language who put in so much
effort to add a feature that gets less relevant all the time.

Ironically, the fact of the matter is: the languages that make
threading *simpler to implementers* are going to be the ones who win
in the apparently coming multi-core world.    Just ask Tim Sweeny.

>  For example, when building hard core operating systems.

If you want to build a hard core operating system in Smalltalk you
have other more pressing issues to deal with then how threading is
accomplished.  And actually there has been some work done in operating
systems that do not support this silly pthreads module we have today,
but use something closer to the Erlang model.  It's interesting work,
but sadly one still can't get much traction with an OS other then
Windows, Mac or a Unix variant.

>  Not really.

Aren't you the one who always requests well thought out arguments? :)
I really don't see what it is you think you lose not having this old,
out dated fine-grained threading model.

>  There are many paths. I'm excited about the path that you are forging. All
> I ask is that you don't make that the only path to travel for people using
> Smalltalk.

Well, at the moment I'm forging nothing, only stating what I know of
the situation.  At some later point I do intend to look at what's
required to make this happen in Squeak, but I have some other more
pressing issues for the present.

>  While I support Smalltalk inventing the future, keeping it from supporting
> valid concurrency techniques is ignoring the future (and the past) of what
> works!

We have very different definitions for "works".  Here you are using it
the same way someone would use for <insert crappy programming
language>.  It works in the same way you can paint a house with a
tooth brush.



More information about the Squeak-dev mailing list