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@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@lists.squeakfoundation.org [mailto:squeak-dev-bounces@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@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