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

[Darrin Hyrup]

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:
>
>> IMO, one of the main sufferings of softcode heavy muds is that they
>> use the internal language for too much.  It slows down the server
>> and takes up a lot of CPU, cutting down the number of users one can
>> support and adding delays/lag.  
>
>This is a myth originated by partially competant authors and users of
>softcode servers.  It is a very long way from the truth.  Go have a
>look at properly (ie efficiently) constructed and written softcode
>based MUDs (ColdX and BatMUD are good starters).  Also look at the
>(very few) stats available from Marcus Ranum

It depends on what you're comparing, where, and how you're comparing it.

>  Note: Some statistics for ColdX were posted to this list quite some
>time back by either Brandon Gillespie or Miro.  There are also a few
>quoted messages from Marcus in the archives.
>
>Want the truth?  Well written softcode servers are entirely capable of
>outperforming moderately well written hardcoded servers.  

Hmm... I disagree.  Take, for example, Chris Grey's posts about the
efficiency of his mud language.  Its the fastest I've seen, and its still
12x slower than native code.

Now, that's not a problem when you only use the softcode for things that
not used so much, or when there is a small player base.  But when you code
your event system, I/O, and most all significant interfaces with the
softcode, and you have more than a handful of users on the system, you're
going to see some CPU impact vs hardcode.  I'm used to systems where the
operating goal is to support 1000+ simultaneous users per server without
significant application induced delay.  I hope you're not trying to tell me
that a well written heavy softcode mud will outperform a well written
hardcode mud with 1000+ simultaneous users.

Softcode is nice because it allows a great deal of flexibility, with little
CPU impact, but I still maintain that it should not be used for the
low-level coding, nor for heavily trafficked aspects of the system.  An
intelligent combination of the two would be best.

>> 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.

Best,

Darrin