[MUD-Dev] Re: processors

[Mik Clarke]

diablo at best.com wrote:
> I am guessing the problem is processor-related becuase I was able to solve
> most of the problem by reducing the number of calls per second our main
> mobile ai routine gets. This fixed the problem we were having, which was
> that our tasks (timed events) were taking WAY too long to go off. A 3
> second task would take 20 seconds, but this only happened with a heavy
> player load. Our tasks are held in a table indexed to some number (some
> sort of ticker in linux? I don't know the proper names for anything). That
> table is polled every time the game searches for player input (it cycles
> through all our player lines constantly), and if a task is found to be
> either overdue or ready to go off, it goes off. The problem comes when
> those tasks start taking too long. This of course causes a cascading
> effect as more and more tasks build up.

Sounds like a combination of CPU and design/algorythms.  Having hundreds
of calls for mob AI is ok, as long as the calls are short ones.  You can
fit in 100x9ms calls or 10x90ms calls and have breathing space.  Fixing
a CPU and fixing the code both make the call length shorter.  By the
sounds of it, you may have one or two processes that are taking
exceptionally long (maybe you could add code to time each call). 
Finding and fixing those is probably a good idea.  I'd suggest you start
looking for things in the area of mob navigation - one of those horrible
algorythms that searches the whole mud for object/mob x getting called
four or five times a second will kill almost anyones performance (and
its performance gets worse as the mud gets bigger).
 
> Generally, the way the author of our language/engine explained it to us is
> that the engine and language are not Object Oriented in order to be
> faster, and in order to allow for more proactivity (as opposed to
> reactivity). We will try reduce the drain that things like mobile ai put
> on the processor, but it's a pretty heavy task, complete with string
> manipulation and interpreting a mini-programming language we have inside
> the game.

Ummm. Yuk. OO doesn't mean slower and it doesn't mean stupider.  What it
does mean is that the programmer has to be more aware of the hidden
implications of what they are doing. A good programmer can get OO just
as fast as non (and with source code that's a lot more maintainable). 
You want to absolutely minimise the string manipulation, expecially any
analyses of actions or speach (ala the classic ROM MobProgs).  Numbers
are a lot cheaper.  That's why I'm recoding to an event subsystem.  A
lot of work to make the code issue the events, but comparisons and
checks on them are very fast (maybe 10 instructions vs 1000).  Consider
precompiling (or at least tokenizing) your internal language.  Also look
out for looping mobs - you may get 3 or 4 mob loops, which burn tons of
CPU even when no-one is there to watch them.
 
> Could someone like yourself, or someone similarly erudite about such
> matters speed things up by recoding? Probably, but there's a lot of code,
> and probably a _lot_ that needs doing.

Yep, and every little bit helps. As JCL says, it find out which bit is
the most important that's the tricky bit.

Mik
--
http://www.geocities.com/SoHo/Cafe/2260