Hey this sounds a an interesting path to me. If we think in nature and it's
design, that images could be analog to cells of a larger body. Fragmentation
keep things simple without compromising scalability. Natural facts concluded
that is more efficient not to develop few supercomplex brain cells but to
develop zillions of a far simpler brain cells, this is, that are just
complex enough, and make them able to setup in an inimaginable super complex
network: a brain.

Other approach that also makes me conclude this is interesting is that we
know that one object that is too smart smells bad. I mean it easily starts
to become less flexible so less scalable in complexity, less intuitive (you
have to learn more about how to use it), more to memorize, maintain,
document, etc. So it is smarter but it could happen that it begins to become
a bad deal because of beign too costly. Said so, if we think in those
flexible mini images as objects, each one using a core we can scale
enourmusly and almost trivially in this whole multicore thing and in a way
we know it works.

Other interesting point is faul tolerance. If one of those images happen to
pass a downtime (because a power faliure on the host where they where
running or whatever reason) the system could happen to feel it somehow but
not being in a complete faiure because there are other images to handle
demand. A small (so efficient), well protected critical system can
coordinate measures of contention for the "crisis" an hopefully the system
never really makes feel it's own crisis to the users.

Again I found this is a tradeof about when to scale horizontally or
vertically. For hardware, Intel and friends have scaled vertically (more
bits and Hz for instance) for years as much as they where phisically able to
do it. Now they reached a kind of barrier and started to scale horizontally
(adding cores). Please don't fall in endless discussions, like the ones I
saw out there, about comparing apples with bannanas because they are fruits
but are not comparable. I mean it's about scaling but they are 2 different
axis of a multidimensional scaling (complexity, load, performance, etc).  

I'm thinking here as vertical being to make one squeak smarter to be capable
to be trhead safe and horizontal to make one smart network of N squeaks. 

Sometimes one choice will be a good business and sometimes it will be the
other. I feel like the horizontal time has come. If that's true, to invest
(time, $, effort) now in vertical scaling could happen to be have a lower
cost/benefit rate if compared to the results of the investiment of
horizontal scaling. 

The truth is that this is all speculative and I don't know. But I do trust
in nature.

	Cheers,

Sebastian Sastre

> -----Mensaje original-----
> De: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] En 
> nombre de Ralph Johnson
> Enviado el: Jueves, 18 de Octubre de 2007 08:09
> Para: The general-purpose Squeak developers list
> Asunto: Re: Multy-core CPUs
> 
> On 10/17/07, Steve Wart <steve.wart at gmail.com> wrote:
> > I don't know if mapping Smalltalk processes to native 
> threads is the 
> > way to go, given the pain I've seen in the Java and C# space.
> 
> Shared-memory parallelism has always been difficult.  People 
> claimed it was the language, the environment, or they needed 
> better training.
> They always thought that with one more thing, they could "fix"
> shared-memory parallelism and make it usable.  But Java has 
> done a good job with providiing reasonable language 
> primitives.  There has been a lot of work on making threads 
> efficient, and plenty of people have learned to write 
> mutli-threaded Java.  But it is still way too hard.
> 
> I think that shared-memory parallism, with explicit 
> synchronization, is a bad idea.  Transactional memory might 
> be a solution, but it eliminates explicit synchronization.  I 
> think the most likely solution is to avoid shared memory 
> altogether, and go with message passing.
> Erlang is a perfect example of this.  We could take this 
> approach in Smalltalk by making minimal images like Spoon, 
> making images that are designed to be used by other images 
> (angain, like Spoon), and then implementing our systms as 
> hundreds or thousands of separate images.
> Image startup would have to be very fast.  I think that this 
> is more likely to be useful than rewriting garbage collectors 
> to support parallelism.
> 
> -Ralph Johnson
>