Hi Peter, look.. I've implemented RemotedObjects that is remake of rST available in squeaksource but even with the peformance improvments of using the sockets in full duplex I was hoping better results so I've freezed development there. I can't say anything about the RMT nor SOAP because I had no experience with them. Honestly I think we should consult someone with more experience in squeak and network than me. Perhaps people envolved with Croquet or Spoon can bring some experience/ideas/frameworks?
Cheers,
Sebastian Sastre
-----Mensaje original----- De: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] En nombre de Petr Fischer Enviado el: Jueves, 18 de Octubre de 2007 12:36 Para: The general-purpose Squeak developers list Asunto: Re: Multy-core CPUs - communication among images
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