[MUD-Dev] New Beginings

[Kwon Ekstrom]

From: "David B. Held" <dheld at codelogicconsulting.com>
> From: "Kwon Ekstrom" <justice at softhome.net>

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

> With templates? ;)

I've never used c templates, so I won't comment on them...

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

> If your load is relatively stable, and doesn't spike, then caching
> is a fine solution.  But if you have any allocation spikes, you
> are

Spiking isn't a problem since mobs and items and most of the cached
objects in the world don't go away.  There's no reason to
de-allocate a mob or an item if you know it's going to repop.

> either going to end up with a fat, empty cache, or you're going to
> wait for the GC to reclaim the unused objects all at once.  With

An empty cache isn't a bad thing, it means you're not wasting
memory, as for garbage collecting alot of objects at once, it's
doubtful that many objects are going to be disposed in that short of
a period.  Plus it's not a "flat" cache.  It checks the usage load
to determine how large a pool to maintain.

> refcounting, you pay for deallocation as soon as the object's
> lifetime is over.  The insignificant cost of adjusting the
> refcount is more than justified by the optimal memory usage.  And
> if you use a pool allocator with a smart resource, you can have
> automagic caching.

Working in c, I've noticed alot of things are prone to memory leaks,
the cost in time alone to debug these memory leaks is enormous.  You
have to maintain strict conventions on how to handle things, and a
flaw somewhere in that convention can introduce a memory leak that's
difficult to find.  Alot of so called "industrial strength" software
has problems with memory leaks and crashing (played with windows or
office lately?)

Most of the c/c++ coders I know of have nightmares about memory
leaks in their code because they're so difficult to track down.

Speed of allocation in java is slower, and the GC does have it's
issues...  but I've never had issues with performance except with
the java.io package.  Using java.nio alot of those concerns have
disappeared.  Used correctly, I have no doubts in my mind that
direct allocation is faster, and can be more efficient.  In practice
what's the percentage?

>> The simple fact is, what performance gains I'd receive using C++
>> are overcome by the development tools I get from java.

> That's funny.  C++ has a much broader user base and toolset.  It's
> also more mature, and has far more libraries than any other
> lanugage

I'm quite positive that there are more libraries available for c
than there are for java, but I've yet to run across things I "can't"
do in java reasonably well... granted I'm not trying to setup a
high-end 3d client side application, or write device
drivers... there are definitely things that c does better.

Then there's cost, alot of the tools that you get free for java
costs to get a similar product for c, and those costs are
substantial.  I don't know if you've ever visited Topcoder.com but
they've mentioned that the vast majority of people competing on
their servers use java... why?  It's alot faster to write the same
program and have it run with acceptable speed and fulfill the design
requirements.

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

> Granted.  Which is why I'm always suspicious when someone says
> that <interpreted, GC language X> is "basically as fast as C++".
> The person who wrote the benchmarks to "prove" that probably
> doesn't know jack about C++.

>From every post you've written on the subject just tells me that you
don't know jack about performance in other languages.  I won't tell
you that Java is faster than C/C++ but I will tell you that for
primitive operations, java is within nanoseconds of c/c++.  I will
tell you that depending on the operation that java is withing 1-3%
of c/c++ for object method calls.

The problem is I can't tell you exactly how fast java works, that
depends primarily on OS/JVM implementation.  There's alot of details
that go into determining how fast your code will run in Java.  I
have experience in c/c++ but it's not extensive.  I have several
professional friends in that area which agree with me.  C/C++ is
"better" at doing things "if" you know what you're doing.  Java
allows faster development with fewer bugs, has a large well
documented and easy to use toolset.  Has acceptable performance.
Allows easy documentation of your own source.

Use the tool that you need for the job, I absolutely hate VB, but
I've used it... why?  Because sometimes I needed to rapidly develop
a graphical application using COM. Would I write something like a
back-end server in VB?  Absolutely not.  Javascript is slow (even
compared to java) but I've used it as well... for simple tasks that
need done on a windows server.

Lately I've been writing AWK scripts for a friend of mine who needs
them at his work (ironically they're using a korn shell emulator on
a windows 2000 server)

Going back to C/C++, your compiler generates Assembly language (yes
that's your object files there) which then get compiled into an
executable binary.  Would you then recommend that people learn
Assembly?  (Some of my friends have learned assembly to further
optimize their code post compiling pre-linking)

There are tools I'd like to see for Java.  A pre-compiler to allow
macro defines and whatnot is definitely something that I miss from
programming in c/c++.

-- Kwon J. Ekstrom

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