From: amylaar@opal.cs.tu-berlin.de (J"orn Rennecke)
Subject: Re: Darker Realms - The Mudlib
Organization: Techn. University of Berlin, Germany
Date: Thu, 13 Aug 1992 22:07:34 GMT

d8andjo@dtek.chalmers.se (Johan Andersson) writes:

>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

That is probably due to your low mudlib complexity. Generalisation is
inappropriate.

>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 

The size of the compiled code would increase. It's quite perplexing
that you keep complaining about memory shortage, while at the same time,
you make changes that unnecessarily bloat the memory usage.

>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.

Watch out also for mappings, arrays and strings that are allocated without
need. These will be shown as normal usage in status, but never freed.


>> >>   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. 

The map functions do a lot calls of apply_low too, and from what i've seen
from CDlib there are a number of places wher it is used just to make calls
in this_object(). A simple loop is faster and can do the same, but statistics
get less impressive. Not to say that this will be the reason for the entire
difference, but some kind of correction factor might be appropriate.

>> >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.

Has somebody out in networld some driver code that is commonly belived to
qualify for both categories? If it should fail as example, the discussion
of the reasons might still some clues :-) give some clues :-) .

>> 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 ?

No, not for typically temporal strigs like the ones made by 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.

As call_outs are always locals, and often use string constants, that is a job
for the compiler.

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

Not necessarily. Some wizards use a lot of tools to support their design
activity.

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

Because the mudlib triggered a number of slow, but fatal bugs. Because
it used some constructs the driver designer had not thought of, or
features that were never really debugged... A vanilla 2.4.5 mudlib uses
a somewhat better-tested part of the 3.1.2 gamedriver.

>is the significant difference? Why does your mud not grow faster? The high

With the absence of gross memory leaks, growing of the allocated memory is
mainly determined by the number of new objects
( TUBMUD has more than 11000 objects now...) . The amount of memory allocated
for program blocks THAT ARE NOT SWAPPED sooner or later meets an equilibirum.

>hitrate of the cache still indicates that the answer is that nothing new

New things happen, but their ratio in terms of function calls is not so high...

>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.

This is why i'm working on the bug free game driver, and have implemented
a fast compiler.

> [ 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, 

The smalloc is usable independent from the rest of the game driver, while the
latter, as soon as  smalloc is enabled, will use a #define for xalloc,
since smalloc already incorporates the xalloc functionality. But you willneed
some fragments of lint.h, because xalloc will use a different routine than
malloc, which will now allow another alignment size than 4. With the
combination of gcc 2.2.2, yacc and sparc, the old cludge would cause crashes.

>otherwise it is ftp-able from somewhere?

mud.cs.tu-berlin.de , directory /pub/mud.

>> 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. 

You should try 10 CACHE_BITS (1024 entries) and more shared strings.
Only if this fails to give the desired results, it's worth the effort to
invesigate other possibilities to make function calls faster.

	amylaar