[MUD-Dev] Re: MUD Development Digest

[Nathan F Yospe]

On Fri, 3 Apr 1998, Justin McKinnerney wrote:

:First, I agree with your first comment. I have heard people claim their
:disk-based muds run faster than memory-based, but this all semantics. If a
:disk-based game does run notably faster than it's memory-based equivilant,
:it's simply due to the fact the operating system is doing a better job of
:memory managment (perhaps doing cache alignment, for instance), which
:wouldn't be suprising considering some of the code for MUDs I have seen.

Just to note that I use a mixed approach, with my own memory management... I
have not gotten enough of the engine done to give it a real test, but... it
seems that reliance of system paging is a doomed approach, unless you are
very careful about how you allocate memory. Likewise, writing small bits to
disk is going to slow everything down. This can be sidestepped by offloading
the writing of small bits to a seperate thread, but... writing big chunks is
nice.

:I think you are on the right track with the concept of using multiple
:processes. The alternative would be to use threads instead (ie: lightweight
:processes), however, not only is this not supported under all UN*X (unless
:you wanted to compile your own user-level thread library), but tends to be a
:lot less clean and relies a great deal on the thread library you are using.
:Of course, this is coming from someone who has exprienced re-entrancy
:problems in such complex calls as sleep() <grin>. On the other hand, if you
:ever want to port to NT, using threads would be highly recomended.

I'm not sure what version of UN*X you are using... or which version of NT,
for that matter! This is quite the opposite of my experiences with
commercial, network serving operating systems. The threads in IRIX 6.2 seem
to work quite well, as do these Solaris threads. Heck, even the ones in the
developer's version of Rhapsody I've testrun worked. The ones in NT 4.0 had
some itty bitty problems... like the eleventh thread and on never getting a
reasonable share of the processor, and in fact never getting ANY of it 
unless one of the others deliberately gives it up. But this is NOT the place
for an OS war... one simple statement should suffice: If you are on Solaris,
use threads. On IRIX, go ahead and use them, you might not be able to tell
if they are threads or processes (sorry, J C, but that's been my experience),
and on Linux... pray. Can't speak for the others.

:I agree with you that a RAID is a good thing to have, but I do not believe
:that it will completely eliminate the possible need for a seprate process to
:do disk IO on a large multiuser system. While it's true most RAID systems
:have hardware level memory caching, the operating system still blocks all
:accesses to the hardware. This causes a sleep state in your process, and if
:you have enough access going on, even a large buffer can be heavily
:burdened.

There are non-blocking disk access calls for most flavors of unix...

:Going with a seprate process for all blocking IO guarentees that you will
:not loose any processor cycles due to sleep states you did not design your
:application to have. This enables you to continue executing, say, the
:command of another user while disk IO relative to the first user is being
:processed. Then once you've done your roundrobin queue (or however you set
:it up) and come back to the first user, the disk IO should be ready.

:And remember! Non-blocking syncronous IO is your friend. :)

True...
--

Nathan F. Yospe - Aimed High, Crashed Hard, In the Hanger, Back Flying Soon
Jr Software Engineer, Textron Systems Division (On loan to Rocketdyne Tech)
(Temporarily on Hold) Student, University of Hawaii at Manoa, Physics Dept.
yospe#hawaii.edu nyospe#premier.mhpcc.af.mil http://www2.hawaii.edu/~yospe/