Michael Latta wrote:
> The other approach is 
> to change the Smalltalk semantic to be more concurrent.  This can be 
> done with proxy objects that defer computations until needed.  A 
> prototype in the Self community saw up to 5 way concurrency in simple 
> usage with no change in coding.

I assume the "proxy objects" here are as following:

A method is "invoked". Instead of actually invoking that method, a proxy 
object is given in return, which will eventually be replaced with the 
real result of the method. The method can then be executed on a separate 
CPU or deferred until later.

Alternatively, separate O/S threads (one on each CPU) would run the 
interpreter loop. They would use memory locking to prevent data 
corruption. When one is idle, it could steal an invocation from 
somewhere in the call stack, replacing it immediately with a 
return-value proxy that the other process would eventually fill with the 
return value.

...except that it wouldn't work because executing Smalltalk code has 
side-effects. Hmm.. more thinking required.

> The question is do programmers want a concurrent language, or a 
> sequential one?  If multi-core computers are where all vendors are 
> going, we software types should get on board.  Rather than treating 
> concurrency as an exception case to the nice sequential way of viewing a 
> problem, we should explore turning it on its head.  If we embrace 
> concurrency we get the performance benefits from any concurrent 
> hardware, we just need to readjust our thinking.

Have a look at erlang, http://www.erlang.org. Unfortunately it uses 
Emacs as its IDE. Squeak is much nicer in that regard :-).

Also, it wouldn't hurt to use more [[do something] fork] in code, 
especially for long-running calculations such as downloads, compilations 
  or software updates. This is one of my pet peeves - Smalltalkers have 
everything there to do concurrent programming but tend not to think 
outside of their sequential square too much.

> On the practical side of things, since the Squeak interpreter is 
> basically one big C loop, how would we make use of concurrency?

One idea would be to make better use of pipelining. An experiment would 
be to rewrite the interpreter a bit, doubling up each step and using two 
stacks. I.e:

Load bytecode A
Load bytecode B
Process bytecode A using stack A
Process bytecode B using stack B
Jump to the next bytecode for A
Jump to the next bytecode for B

My theory is that this would be slightly faster because the CPU's 
pipeline would be more full, and more cache would be used.

Mikevdg.