From: amylaar@mcshh.Hanse.DE (Joern Rennecke)
Newsgroups: rec.games.mud.lp
Subject: Re: Darker Realms - The Mudlib
Date: 20 Aug 92 03:34:30 GMT
Organization: Point of Presence & MCS Hamburg

mmcg@cs.monash.edu.au (Mike  Mc Gaughey) writes:

>amylaar@opal.cs.tu-berlin.de (J"orn Rennecke) and
>>d8andjo@dtek.chalmers.se (Johan Andersson) snipe:

>Will you boys tear yourselves away from each others throats
>long enough to insert some profiling code please?  I'm pretty sure we'd
>all be be particularly interested in the following:

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

>>The size of the compiled code would increase. It's quite perplexing

>Can you chuck some code in to count average and median switch statement

This would lead nowhere. The main applications for switch are yet to come...

>size?  (hell, there has to be an optimal size under which you compile

Huh? what kind of optimal size do you mean? switch can handle case label lists
from a single one to as much code as a struct program can handle.

>it to case examination anyway; easiest to simply compute it by hand and

again, computing what?

>write it into your compiler).

>>>> >>   Calls to apply_low: 33709003 Cache hits: 91.15%
>>>> >  Global cache, Tries: 4659277  Hits: 861816  Miss: 3797461  Rate: 18.5%

>Global function cache:
>    Precisely what do you hash on (18% hit rate looks like function name pointer)

Both is hashed on pointers. But the CD driver uses different pointers for the
same string more often.

>    Hash table size/implementation?
size: read th postings		implementation: read the source.

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

>Profile it - how much time is spent in inserting shared strings?

This can't be done well, since the overall locality of the program is affected
when you have extra shared strings. Strings that are added together are likely
to be unique strings, and quite long ones at that. Having them in the hash
chains means to reference this otherwise seldomly referenced part of memory
every time a string is newly created in this hash chain.

Do you have any profilers for THAT ?

>How much extra time is spent if you also insert (non-constant) temporaries?
>(even our non-compiled 2.3 folds constant expressions :)

>How much time does string hashing take (% of total CPU)?  Which of the (various)
This will depend a lot on the way your CPU handles the modulo operator.
could be replaced with a multiplication,
(actually, you need only a 16*16 bit multiplication with a 32 bit result.
 Expressing this in 68000 assembler is definitly superiour to compiling the
 c code for 680x0 machines.
 But try to express this with c... )
but i don't know if this will degrade the hash distribution in any way.
Is there an electronic form of the article hash.c was originally based on?

>shared string packages do you use?  Is it worth your time and effort to save

Hmm, lars included only one. Of course, the code gets modified when you work a
 bit on the driver, like speeding things up & correcting handling of high ref
 counts.
What other packages are there?

>a small percentage of CPU?

>How much time is spent in the various efuns?  Can you profile time
>for simul_efuns yet?  How much time (as a % of total CPU used by the

How could you do this, with efuns that are leaner than the rusage system call?
The hardware caches will behave different when you have this massive overhead,
so simply subtracting the time for profiling won't do the trick. Moreover,
the profilers i know of won't mix with optimising compilers.

>driver) is saved by your function caches?  Is it >5%, or is it the (much
>more likely) embarrassingly low figure of 0.1%?  After all, all the
>function string pointers will be stored in the same memory page...

But you sometimes want very simple functions to be called very often, like
with sort_array(). This efun, like all the map efuns, wasn't usable on arrays
of interersting size till the cache was introduced.

>(Unfortunately, true profiling is broken on our decs at the moment - we know
>not why.  In any case figures from Shattered are hardly applicable here).

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

>Mmm.  What about call-other?  Or don't you usually compile those to bytecodes?

The object that the call_other is applied on can never be determined in a
static way. Even if called by a string constant, the source for this object
might be changed, and the object updated.

>>You should try 10 CACHE_BITS (1024 entries) and more shared strings.

>_ALL_ strings should be either shared or in compile space.  And they

Hmmm. Why? do you want to eleminate the string_type field? You should then
go ahead and delete the type field as well... could be done without loss
of compatibility and would save a lot of memory, but cost some cpu time...
and it looks like muds will need cpu time more than memory when they grow
complex, judging from the requirements of current NLP systems...

>don't stay in compile space long :)

	amylaar