[MUD-Dev] [TECH] monitoring RMI-type systems

[Chris Gray]

> From: Bruce <bruce at puremagic.com>

> I'd be happy to hear about non-MUD systems as well since they've
> surely had the same types of design issues.

In a previous life (up until about 2 years ago), I worked for a
parallel computing company. We went from our own custom hardware to
porting our system to Unix's and Windows NT.

Our system didn't use explicit RMI or message passing at the user
level.  Instead it presented a distributed sortof-shared memory model
with special semantics to avoid most ping-ponging. Worked not bad for
some things.  However, many of the same issues still come up. Because
our model was better at large-to-medium grained parallelism than
fine-grained parallelism, it wasn't quite as easy to forget out the
distributed aspects. However, people still did, and it still cost them
performance. Some people got pretty good at it, and rarely fell into
the trap. Others didn't, possibly due simply to not enough experience
with it.

I would say that if the remote/distributed aspects of a system are
hidden from view (e.g. inside C++ methods), and so look syntactically
like local invocations, then you are asking for trouble. People simply
aren't that good at spotting when they are doing bad things. This can
be made worse during maintainance, where the maintainer isn't even
aware of the costs, and is simply doing what he/she sees done
elsewhere. Don't try to hide the distributed stuff - make it obvious
in the function/method names used.  Don't assume people are good at
difficult things like that - they want to concentrate on *their*
problem, not on trying to correctly use the tools that you are giving
them.

Not terribly on topic, but Bruce did ask...

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev