[MUD-Dev] Re: PDMud (was Re: Bruce Sterling on Virtual Community goals)

Jon Leonard jleonard at divcom.slimy.com
Fri Oct 23 13:13:29 New Zealand Daylight Time 1998


On Fri, Oct 23, 1998 at 10:42:11AM -0400, Darrin Hyrup wrote:
> At 09:18 PM 10/22/98 -0700, you wrote: 
> >On Thu, 22 Oct 1998 22:45:34 -0400
> >Darrin Hyrup<shades at mythicgames.com> wrote:
[snip]
> >> The plug-in solution allows the mud programmer a choice in how they
> >> wish to set their system up.  If they wish, they can code more in
> >> the internal language, or they can use existing mud-code, or use
> >> pre-compiled plugins (or create their own) for speed.  That way
> >> neither flexibility nor efficiency are sacrificed, and the server
> >> remains as simple and slim as possible.
> >
> >Such modular systems require what is essence is a message passing
> >system for the communication between modules.  It can be difficult
> >(witness the Mach micro-kernel) to ensure that the message passing
> >overhead does not become a significant fraction of the total
> >processing effort.  This will be especially difficult as the number of
> >boundary crossings (inter-module) for a modular plug0in-style server
> >will be difficult to keep low.
> 
> Oh, no doubt.  Seems like a great design challenge to me.

We have a few design advantages over Mach, primarily that we don't have to
context-switch for passing messages.  It'll usually involve using a function
pointer, which costs two memory references.  That's slow enough, but not
nearly as slow as saving most of the processor state.

For performance, I think we'll eventually want to make fairly heavy use of
backdoor APIs into other modules, including compiling modules together to
avoid using function pointers.

I think it's more important to start with a clean conceptual model, and
optimize when we have to.  There's a lot more features that we want to
code (all of them!) than there are complaints that it doesn't run fast
enough.

Jon Leonard




More information about the MUD-Dev mailing list