Multy-core CPUs

Peter William Lount peter at smalltalk.org
Sun Oct 21 09:24:41 UTC 2007


tim Rowledge wrote:
> I'm sure I'm going to regret saying anything in this thread but what 
> the hell...

;--)


>>
>> Sure you could have N threads - native or green - each running ONE 
>> (Squeak) Smalltalk process running in one protected memory space as 
>> long as NONE of these threads share ANY memory between them.
> I don't think that was actually specified but yes that would be one 
> way of doing it.

That is essentially the Erlang way, isn't it?

>> That means no objects being shared.
>
> No it doesn't. Objects can be shared via communication; that's what 
> messages are  for. It only happens that the Smalltalk systems we're 
> mostly used to share by sharing memory.

I meant what you said. ;--)


>> That means each Smalltalk process is really it's own image running 
>> independently with only one user level Smalltalk process.
> Works for me. Like an ecology of cells. Now where did I hear that 
> analogy before? Oh, yes, I think it might have been either Alan Kay's 
> doctoral thesis or an early talk on the idea of objects.

It would be good to turn up a reference to that. Alan? Is your doctoral 
thesis online? If not could it be?


>> Any communication between them with objects is serialized and 
>> transmitted in some manner that - oh dear - avoids using shared 
>> memory or a shared communications "buffer" between two or more threads.
>
> Transputer.

Yeah, those were sweet. The Tile64 seems similar in many ways.


>> This is done even though sending messages via shared memory buffers 
>> in one protected memory space is very efficient or sending messages 
>> via a shared memory space when more than one protected memory space 
>> is in use is also very efficient.
> Only applies in the limited sphere of the typical single processor 
> systems we have got used to over the last few years. And for the 
> purposes of any discussion about real parallelism, current 2/4/8 core 
> systems are really a poor quality patch on the single cpu idea.

Well not really and regardless of that using a shared memory buffer is 
an efficient manner of transport for a serialized object message (with 
or without complete objects or just references or a mix of the two) in 
the case of a system with N-cores and shared memory between protected 
memory spaces. When the images are in separate server nodes then using 
TCP/IP is needed. Using TCP/IP locally on one server box may or may not 
make sense and would likely be slower than a direct shared memory buffer 
although it's possible that the OS might optimize for that case.

> A key idea that people are going to have to get used to is, oddly 
> enough, just like the one they had to get used to in order to accept 
> late binding and dynamic languages. That is, to paraphrase a old 
> quotation from Dan Ingalls (I'm pretty certain)
> "we've got past the stage of worrying about the number of 
> computational cycles. we need to start worrying about the quality"
> Nominal inefficiency in having message passing across processes done 
> by something 'slower' than shared memory may be a key to allowing 
> massively spread computation. Trading the 'efficiency' of hand coded 
> assembler for higher level languages made it more practical to build 
> bigger programs that could do more. Trading the 'efficiency' of C for 
> a decent late bound language allows more conceptually complex problems 
> to be tackled. Trading the 'efficiency' of shared memory as a medium 
> for sharing information with some other transmission method may be the 
> lever to unlock really complex systems.

I'm all for wisdom in computing, if I wasn't I'd not be using Smalltalk!


> I think it's time people read up a bit on some computational history. 
> Quite a bit of this stuff was worked on in the old days before the x86 
> started to dominate the world with a saurian single-core brutishness. 
> Learn about Occam for example.
>
> And Peter, before I "explain in full detail and completely how it 
> would actually work" how about you explain in full detail and 
> completely how you're going to fund my research? ;-)

;--) That was my next line for you!!! ;--)

Seriously, if I could I would.


Ok, so if you really are talking about a "strict" Erlang style model 
with ONE Smalltalk process per "image" space (whether or not they are in 
one protected memory space or many protected memory spaces) where 
objects are not shared with any other threads except by copying them 
over the "serialization wire" or by "reference" then I get what you are 
talking about.

However, you'll still end up with concurrency control issues and you've 
got an object version explosion problem occurring as well. How will you 
control concurrency problems with your simplified system? Is there a 
succinct description of the way that Erlang does it? Would that apply to 
Smalltalk?

If on the other hand, you are allowing more than one process per "image" 
then you don't gain anything at all since anytime you have more than one 
thread on a memory space you have all the concurrency problems that 
shared memory between operating system process give you.

You simplified concurrency system also dramatically alters the Smalltalk 
paradigm.

What have I missed or left out from what is being proposed or worked on?

Is this the approach that Cincom is using in their Visual Works system? 
They seem to not be embracing the notion of native threads. However it's 
also unlikely that they are embracing the notion of only ONE Smalltalk 
process per image either. At least in the sense of preventing a user 
from forking off additional Smalltalk processes in the same memory 
space. To truly support the above simplified model "forking" of blocks 
of code will need to slice off a copy of the entire image (some one did 
that for Squeak a while back). Then you have all the problems with 
object versions. Sigh.

One shoe doesn't fit all solutions.

All the best,

Peter




More information about the Squeak-dev mailing list