FWIW, I did some parallel computation work with Javaspaces about 5 years ago and ISTR the overhead for putting/getting from the space was about 10ms. Not sure how much of that was computational versus network latency. This was on a LAN with gigabit Ethernet.
R. On 2011-10-13, at 3:17 PM, Dan Creswell <[email protected]> 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 >> >>
