I agree Dan. I was simply alluding to some peoples preference to consider
performance on a single "system" as the measurement for any reason to make
something distributed. It's usually much better to think about all the other
pluses in a distributed system, such as distribution of failure points so that
single "power" or "destruction" events don't take down everything. If you are
can visualize an object graph with well structured dependencies and data flows,
you can usually see how to write code that works well with JavaSpaces.
Gregg
On 10/13/2011 2:17 PM, Dan Creswell wrote:
This is certainly true however, performance is not always the number
one consideration. Some algorithms are more easily expressed using the
'spaces API which can be invaluable in that it makes implementation a
more tractable problem.
Dan.
On 13 October 2011 19:00, Gregg Wonderly<[email protected]> wrote:
<snip>
The scale of the computations involved has to dwarf the network transit
times before it gets interesting. Something on the remote machine has to
provide an automated scaling factor that provides a big benefit that a
single machine can not.
For example, enterprise grade multi-core and multi-processor machines, can
make it convenient/possible to do some pretty large tasks on one machine in
one memory space. But, the cost of such machine can get quite high, quite
quickly, compared to the mid range desktop computer that you might use as a
JavaSpace client/worker computer. The network/JavaSpace mandated latency
needs to be considered so that you can partition the "job" into the right
sized tasks so that more "work" than "communications" is occurring.
Gregg
