[MUD-Dev] Re: PDMud (was Re: Bruce Sterling on Virtual Community goals)
shades at mythicgames.com
Fri Oct 23 10:42:11 New Zealand Daylight Time 1998
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.
More information about the MUD-Dev