[MUD-Dev] bytecode results

Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA
Thu Jul 15 16:21:25 New Zealand Standard Time 1999


As some of the folks who have been on the list for a while may remember, I've
been messing around with a bytecode engine for my MUD. It already has a
parse-tree interpreter, but I wanted to see if I could squeeze more speed
out of it. Also, its been great fun doing it. Anyway, I've now finished
off the X86 version of the bytecode engine, and thought I would report
the results here in case someone else is thinking of doing something like
this. Everything is straight ANSI C code, except that I've used gcc's
language extension of label variables. Here is a cut from one of my
documentation files I've just updated:


The final results for this machine (300 Mhz P-II running Linux) are (the
test program in this case is 100 iterations of the 256x256 fractal terrain
generation, done in a very straightforward way):

	Unoptimized MUD server:

	    tree interpreter:	187 seconds
	    bytecode machine:	77 seconds

	Optimized MUD server:

	    tree interpreter:	93 seconds
	    bytecode machine:	31 seconds

	Native code:

	    unoptimized:	4 seconds
	    optimized:		2 seconds


So, in this case, the bytecode machine is about 15 times slower than
native execution and only about 3 times faster than the tree interpreter,
fitting in with the conjectures above.

Repeating the original "Towers of Hanoi" experiment:

	Unoptimized MUD server:

	    tree interpreter:	n = 22: 57	n = 23: 114
	    bytecode machine:	n = 22: 14	n = 23:  29

	Optimized MUD server:

	    tree interpreter:	n = 22: 34	n = 23:  68
	    bytecode machine:	n = 22:  4	n = 23:   9

	Native code:

	    unoptimized:	n = 22: 0.53	n = 23: 1.08
	    optimized:		n = 22: 0.68	n = 23: 1.40

The native code times are wierd. Proper optimization flags to gcc (I just
used '-O') should get better optimized times than unoptimized. With this
example, bytecode is 4 - 8 times faster than the tree interpreter, and
7 - 8 times slower than native code.

--
Don't design inefficiency in - it'll happen in the implementation.

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA
               http://www.GraySage.Edmonton.AB.CA/cg/



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev




More information about the MUD-Dev mailing list