[MUD-Dev] Re: MUD Development Digest

[Justin McKinnerney]

Hey Dr. Cat,

Yet again it's one of your points that prompts me to actually post. Or mabie
I just like picking on you. The world may never know. ;)

But really, I see both sides of this particular argument. This is because I
can invision a game where 10,000 or even 100,000 people can play the game on
a single "server" (single world entity, don't pick my words apart, I know
it's possible to have a game distributed. But that's an argument for another
day)...

Just the same, perhaps fancy heap methods are unnecessary, yes, seing as
that is exactly what the O/S is supposed to manage. However, I can see some
validity to intelligent memory managment on an exceedingly large system.

As a rule of thumb, on pretty much ANY O/S, you really don't want to have
more than 1/3 your memory be in swap. If you're over that mark, you can
almost guarentee that your almost completely limited by the speed of your
hard drive at that point and not by the processor at all, as you are likely
to be page faulting on more memory accesses than not (assuming that at least
1/2 the memory you have allocated is in use).

At the point where you exceed what physical memory you wish to use by a
significant amount (without having to add anymore), you do need to start
being smart about both how that memory is arranged relative to it's
utilization and exactly what data you decide to keep in memory.

This is where the 'fancy' memory algorithms come in. Generally when you
allocate the data for a physical 'object' in your world, you want it to be
as close as possible in physical memory to whatever data it is directly
affecting/changing (ie: player in a 'room' object may be more efficent
memory wise to have the player and room data as close as possible in the
physical address space to reduse page faults).

Most of these problems are only for exceedingly large and heavily used
relational systems, and mostly are not used (or implemented properly) except
in large dbases like Sybase and Oracle.

However, it's safe to say that a system the size of, oh, Ultima Online may
benefit from this kind of system. Among other systems. :)

	- Justin -

> -----Original Message-----
> From: Petidomo List Agent,,,, [mailto:petidomo at kanga.nu]On Behalf Of Dr.
Cat
> Sent: Friday, April 24, 1998 12:44 AM
> To: mud-dev at kanga.nu
> Subject: [MUD-Dev] Re: MUD Development Digest
>
> I've been optimizing for "how much precious programmer time does this
> take to implement" for many years now.  More and more aao s we've moved
> further and further from the 1 MhZ 6502s I got started on.  With each
> advance in computing power, more problems fall into the category where I
> can use a slower but simpler algorithm rather than the best one I can
> think of, and still be far, far faster than the program needs to be.  I
> never even write in assembly any more, I can get away with doing
> everything in C now (except for a graphics library, which I licensed from
> someone else rather than write my own.)
>
> What I don't see is where writing code that simply doesn't HAVE any
> garbage to collect is harder than writing code that has some.  To me it's
> the other way around, I'd have to be using more of them new-fangled
> unnecessarily fancy data structures and dynamic reallocation
> techniques and
> stuff in order to be able to generate garbage that a garbage collector or
> heap compacter would need to go messing with.  I just allocate way more
> than I need of everything, right at startup, and then just keep on using
> it till shutdown without any fancy shuffling stuff around.  I don't see
> where there's "more hard work" involved in that than doing it some other
> way, it seems pretty straightforward to me.  :X)
>
> *-------------------------------------------**--------------------
> ---------*
>    Dr. Cat / Dragon's Eye Productions       ||       Free alpha test:
> *-------------------------------------------**
> http://www.bga.com/furcadia
>   Furcadia - a new graphic mud for
> PCs!     ||  Let your imagination soar!
> *-------------------------------------------**--------------------
> ---------*
>
> --
> MUD-Dev: Advancing an unrealised future.
>


--
MUD-Dev: Advancing an unrealised future.