Just reading http://wiki.squeak.org/squeak/2978
Looks great, thanks for tip. pf

On 18.10.2007, at 18:40, David Mitchell wrote:

> Check out MaClientServer (developed for Magma, but useful on its own):
>
> http://liststest.squeakfoundation.org/pipermail/squeak-dev/2004- 
> June/078767.html
>
>
> On 10/18/07, Petr Fischer <petr.fischer at praguesoft.cz> wrote:
>> Hi. What do you recommend for communication among running images?
>> RemoteMessagingToolkit (RMT)?
>> Remote smalltalk (rST)?
>> Soap (ehm)?
>> other (not via. TCP/IP stack - for multiple images running locally)?
>>
>> Thanks, p.
>>
>> On 18.10.2007, at 16:18, Sebastian Sastre wrote:
>>
>>> 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
>>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2435 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20071019/6e41da53/smime.bin