[MUD-Dev] New Beginings

[Kwon Ekstrom]

From: "David B. Held" <dheld at codelogicconsulting.com>
> From: <ceo at grexengine.com>

>>   - less power than C++ provides = since you don't mention
>>   performance as a number one priority [NB Java/Python/etc are
>>   often within 5% of the performance of C++ these days -
>>   sometimes faster [normally better at memory management]]

> I don't buy that Java or Python are "often within 5% of the
> performance of C++", unless you hand-pick the worst C++ coders you
> can find.  I also reject the claim that they are "better at memory

Actually JVM's are VASTLY improved, if you look at performance
comparisons, primitive operations are withing nanoseconds of c++.
Java's real slowdown is actually from overridden methods.  I'm sure
someone will tackle that problem shortly.

Sure, Java performance isn't as good as you'd get with c++, but if
you have a decent idea of performance programming in java, then
you'll get results that are good enough except for the most extreme
situations.

> management".  GC != "better memory management".  In fact, RAII is
> very nearly optimal usage of memory in most cases, is easy to make
> exception-safe, and doesn't stall your application while the GC
> thread kicks in.  And if you really feel you need the crutch of
> GC,

I agree that GC isn't necessarilly "better" but I don't see it as a
stall for your program unless you're throwing away objects at an
ungodly rate.  In which case a simple pooling mechanism will
drastically increase your performance (see above).  I've noticed in
my server that the a relatively small number of objects get thrown
away... Mostly Strings (and I'll mention that I tend to avoid
Strings for the most part, preferably using StringBuffers) while
parsing user input.

> you can always use a GC lib in C++.  However, you can never use
> manual allocation in Java or most other GC langs, even if you know
> there are places where it would significantly improve performance
> (and something like a MUD is an app where you are quite likely to
> be able to identify such cases).

I don't see how direct allocation will drastically improve my mud's
performance.  I simply cache my objects and don't pay the allocation
fee repeatedly.  I don't need to dump objects constantly so the GC
isn't a major issue.  The simple fact is, what performance gains I'd
receive using C++ are overcome by the development tools I get from
java.  Cross-platform, extreme stability (short of a stack overflow,
I haven't done anything capable of actually crashing my server),
easy to use documentation (I don't use the standard doclet, I wrote
a doclet which "mirrors" the doclet API in XML, and I generate the
html with XSL, allows me to write in analysis which the standard
doclet doesn't support, when it's finished I'll release the doclet
it's quite interesting)

My program has performance advantages of muds written in C by using
inheritance models that cut out the need to do alot of the state
checks that a purely proceedural mud would need (C++ has this
advantage as well).

The minor performance loss really isn't an issue.  Especially since
I'm coding on a win2k machine and uploading to Scion's *nix machine
to run my server on.  It's doubtful that Java will ever do things
like super-high-end graphics or any variety of high-end computer
work that requires an ungodly amount of processing power.  But for
the standard mud it'll work just fine.  The SMAUG codebase for
example was able to host 300+ players on a 333mhz machine...  We're
up to 2ghz and climbing (rapidly).  Figure in your performance gains
by removing alot of your state checking, and the performance loss of
an interpreted language, even one with a GC... isn't all that bad.

You have to know what language you're writing in... the same
techniques don't work in all languages.

-- Kwon J. Ekstrom

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev