From: d8andjo@dtek.chalmers.se (Johan Andersson)
Newsgroups: rec.games.mud.lp
Subject: Re: Darker Realms - The Mudlib
Date: 12 Aug 92 11:59:02 GMT
	<KJETILHO.92Jul31112327@holmenkollen.ifi.uio.no>
	<1992Aug3.233739.28609@cs.aukuni.ac.nz>
	<1992Aug4.183116.3636@fy.chalmers.se>
	<1992Aug7.233248.10543@mcshh.Hanse.DE> <13226@chalmers.se>
	<1992Aug11.130723.226
Organization: Chalmers University of Technology, Sweden
In-reply-to: amylaar@mcshh.Hanse.DE's message of 11 Aug 92 13:07:23 GMT

In article <1992Aug11.130723.22603@mcshh.Hanse.DE> amylaar@mcshh.Hanse.DE (Joern Rennecke) writes:
>
> Till the end of the use of lars' 3.1.2 , TubMud needed more than 90% cpu at
> reboot time. Now its some odd 17% or 10% , with lots of idle time. Why would
> the cpu be idling, if not because the hard disk is too slow?
>
A good point. This seems to argue that the lag suffered on compilation are
due to fileaccess. I will have to check this for Genesis. The point is that
rebooting Genesis is an order of magnitude faster when old binaries can be
used, which is in fact most of the time. The only reason it is not even
faster is that binaries can't be saved in objects using your switch-case code
with string labels. This is done in a couple of preloaded objects which are
therefore automatically forced to always be compiled.

>
> Reboots are sheduled to get a new game driver version, which will typically
> compile LPC differently, thus all old binaries are crap.
>
Not so lucky here. We have 20-24 hours uptime with regular reboots. This
is quite possibly due to not having a well tested 2.4.5 mudlib but a much
more demanding critter. Also, there seem to be memory leaks. We have hunted
down a few, one in your cache code, but it is tedious work.

> At reboot time, hardly any file will be cached by the file system ( unless it
> is read in several times ).
>
With all the #include files in CDlib, those are read many times. 

> >We have your 'global cache', what size do you use to get 88-97% hit rate?
>
> 1024 entries. But it's not only the cache size, but also shared string
> propagation. (Which, as a side note, saves time & space in other places too.)
>
I'd say this is really due to a noncomplex 2.4.5 mudlib. Here, even if each
function call got its own slot in a 1024-entry cache it would not even
nearly cover ~90% of the calls made. Still it is quite likely that at some
limit the most regular calls can be contained in the cache. What that 
limit might be is of course an interesting question worth investigating.

> From your stats:
>   The clock shows 5 days 12 hours 22 minutes 5 seconds
>
>   Calls to apply_low: 33709003 Cache hits: 91.15%
>
Current from Genesis:
  Local time: Wed Aug 12 13:10:37 1992
  The game has been up since: Wed Aug 12 09:30:04 1992

  Global cache, Tries: 4659277  Hits: 861816  Miss: 3797461  Rate: 18.5%

I think this tells something of the difference in mudlib complexity. We
have approx 1.33Mcalls/hour whereas you have 0.25. 

> You have some kind of draft version... Genesis pretended to have 3.0.51
>
Quite probably, but getting yours and trying to incorporate it into our GD
is not something any of us wishes very much to do. As Jacob stated somewhere,
your code is not the easiest in the world to grasp. I wish it were, because
there is a lot of what you do that we would gladly use, simply because it
is beautiful functionality-wise, at least to my humble judgement ;-)

> >  Function calls:
> >  --------------------------
> >  Global cache, Tries: 1525036  Hits: 312647  Miss: 1212389  Rate: 20.5%
> >  Funmap calls: 15390
> >  Call Cache,   Tries: 1196999  Hits: 850649  Miss: 346350  Rate: 71.1%
>
> >Where 'Call cache' is our 'smalltalk-like' late binding of call_others.
>
> >'Funmap' is for some objects where we use a hashed list for the functions. 
>
> This would amount to 22.7% overall miss rate. I'd like to know how you got
> these figures, i couldn't find the profilig code in the Lpmud-CD.56.tar.Z .
>
It will be there in CD.57. It was something I added a month ago.

> To explain something about the statistics of TubMud:
> It starts with very high apply_low cache hit rates for the first 1 or
> two days, like up to 98% .
>
This effectively means that almost all calls are in the cache. We should 
make an experiment as to the cache size needed to accomplish that. I'm
not entirely sure what you refer to by 'shared string propagation' but
all function names are shared strings and if the first thing apply_low does
is to find the shared string equivalent of the function name called, I see
no hitrate increase possibility there.

Moreover, the first time a function is called in a new program. It must be
a miss. If you, as we, have a lot of wizards coding and testing new things
a significant number of cachemisses must occur. A 98% hitrate indicates to
me that not much developing is going on. Might this also be a reason for
the long uptimes? To my knowledge noone has yet fixed the fact that memory
is lost when compilation fails. But if there isn't much developing, there
isn't many faulty compilations and therefore not much lost memory.

> The running driver uses FAST_FIT in smalloc.c
>
Yes, that would speed up the mud to when it is big, too. Again I wish we
could use your code. I think Jacob took a look at it and said smalloc.c had
grown a factor 3 since your fast-fit code was added. I recently rewrote
your subtract_array and intersect_array reducing the code size at least
the same factor. The alist code is now totally gone from the CDdriver.

> . F_SIMUL_EFUN still uses
> apply_low; the successor (testmuds running for some days) will use a lookup
> table and a direct call of eval_instruction, thus it is pretty close to an
> inherited function;
>
Our /secure/simul_efun is 'function mapped' so here we have a 100% 'hitrate'.
I'm debating with myself if to do the same for the player files.

/Johan
--
Johan Andersson           | "You don`t have conversations with microprocessors
Chalmers, Sweden          | you tell them what to do, and then you helplessly
Email:                    | watch the disaster when they take you literally."
d8andjo@dtek.chalmers.se  |	Sah`ot in David Brins "Startide Rising"