From: d8andjo@dtek.chalmers.se (Johan Andersson)
Newsgroups: rec.games.mud.lp
Subject: Re: Darker Realms - The Mudlib
Date: 13 Aug 92 10:53:11 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@opal.cs.tu-berlin.de's message of 13 Aug 92 03:58:58 GMT

In article <1992Aug13.035858.26673@cs.tu-berlin.de> amylaar@opal.cs.tu-berlin.de (J"orn Rennecke) writes:

 [ binaries and switch-case ]
>
> If it would be actually worth the coding effort, this could be easily 
> resolved by saving the string case label list in a persistent format, 
> and having a table of all string case label lists in the binary.
>
Or by rewriting the switch-case code. Few switches are longer than 5-10
cases anyway so compiling it to if-constructs would both delete the problem,
reduce code size and make the remaining code more readable, while losing very 
little in execution speed. If it would be worth the coding effort...

 [ uptime ]

> This really astonishes me. Does the CD driver suffer so much when the mudlib
> is on fire? as long as the critical master functions work, the game driver
> should handle all error conditions.
>
True, there is currently a bug dumping the game forcing the uptime down to
4 hours. When it is gone we will release CD.57. The normal reason for taking
down the game though, is memory shortage. After an uptime of 20-24 hours,
'status' that is the memory accounted for is around 16-18Mbytes and 'malloc'
is >28. The diff is not all leaks but some are. _That_ is the main problem.

> >>   Calls to apply_low: 33709003 Cache hits: 91.15%
> >  Global cache, Tries: 4659277  Hits: 861816  Miss: 3797461  Rate: 18.5%
> >
> >I think this tells something of the difference in mudlib complexity. We
>
> No it doesn't. the cache is rather small, and there are more malloced strings
> for function calls.
>
> >have approx 1.33Mcalls/hour whereas you have 0.25. 
>
I neither think hitrate is a good measure but Mcalls/hour might be if the load
on the mud is approx the same. A complex mudlib makes more calls/command.
The combat system is a very good example of this. 

> >your code is not the easiest in the world to grasp. I wish it were, because
>
> You can't get an omelette without breaking the eggs, and you can't program
> a computer efficently without using complex algorithms where appropriate.
>
> I have conversations with microprocessors, and they understand exactly what
> i mean.
>
While we helplessly watch the disaster... :-)

Please, I've read a lot of code by a lot of people, some worse coders than
both of us, some better than me, some better than you and some much better
than both of us, judging by functionality that is. What I've found is that
readability and functionality are almost independant variables. You can be
good at none, one or both. You are good at one and it aint readability.

> There are often points in the gamedriver where you get an svalue that is
> likely to be, but not necessarily is, a shared string, and where a shared
> string as result would be desirable. You can the simply test if you have
> a shared string, if yes, reuse it, if not, make one.
>
Like parameters and results I guess. You don't make shared string for
temporary results do you? Like in F_ADD ?

> One of the last big sources of malloced function names was call_out. When I
> changed it to use shared strings, the cache hit rate jumped up by approx.
> 10% of the total calls to aplly_low.
>
Yes, something ought to be done about call_outs. They are almost always to
the same function though so maybe the index to that function should be 
stored, like we do for call_others.

> >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.
>
> The uptimes were deplorably short with 3.1.2 .
>
Yes, but why? Our GD and 3.1.2 goes down because of memory shortage. What
is the significant difference? Why does your mud not grow faster? The high
hitrate of the cache still indicates that the answer is that nothing new
happens, it trundles along in the same old tracks. We can't accept that,
to us LPmud is as much a development environment as a game environment.

 [ smalloc ]

> I've left all old code intact, even debugged some. Preprocessor directives
> will pick the desired fit style. Apart from fast-fit, i also added code to
> support machines where sbrk() can't be used to completely redefine malloc(),
> so that you have to keep and use the old malloc(). This also added to the
> source code length. moreover, i added comments everywhere where i thought
> something was not obvious...
>
We need the functionality, this part must be almost independant from the
rest of your GD, right? I'll ask Jakob if he has the file somewhere, 
otherwise it is ftp-able from somewhere?

> You could also have a binary lookup table for 2 bytes/function.
> But the global cache performs so well, so why add yet another structure? :-)
>
The thing is, our global cache doesn't perform well with 10-20% hitrate. 

/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"