Re: Need to recompile a Java Applet as an Executable
Antoninus Twink wrote:
To be honest, whatever stories people come up with about how good their
JIT compiler is at optimizing on the fly and such like, the truth is
that for many applications, rewriting the bottleneck in C will gain you
an order of magnitude.
And for many, many, many more, it won't. It can most definitely lose you an
order of magnitude, also.
Java performance in some cases is superior to equivalent C code.
In others, it isn't.
On average, most CPU-bound stuff seems to be about 50-90% as fast as C code,
but the difference is much smaller if memory allocation/deallocation are
involved, or if HotSpot converts the code to native code, in which case one
can often find the Java code to be faster.
As always, predictions in any particular scenario are useless. Measurement
will tell.
I believe the principal two reasons for this are:
1) No overhead in basic data types. AIUI, Java will take many bytes to
store a simple int, just because of all the OO book-keeping that needs
Java takes four bytes to store a simple int.
to accompany every single object. Therefore, smaller slices of every
array can fit in cache ---> performance death.
An 'int' in Java is not an object. Some think of this as a flaw.
2) Java hides what's going on under the hood from the programmer. This
abstraction is great for reducing coding time, but it means people
unwittingly do things that cause lots of temporary variables to be
created (which might themselves depend on constructing half a dozen base
classes), or they keep generating lots of junk on the heap instead of
making one allocation and recycling it themselves, so that GC becomes a
killer.
Maybe, but you state this as if it were a sure thing, which is far from the
truth. If GC were to be a "killer", as you cutely put it, that would be
because you are allocating lots of objects. If you are allocating lots of
objects in C or C++, then memory management will be a "killer" there, too.
The difference is that the C/C++ code will require much more code to do the
trick, it'll actually take longer to manage its memory than the Java program,
and the risk of wild pointers or memory leaks is much, much higher.
It doesn't do any good to get a bug to crash your C program in half the time
it takes a Java program to run correctly.
Are you a Java programmer? Because you don't sound like it.
In Java (and C++ for that matter), the possible expansion factor of a
single source line into assembly instructions is essentially unlimited,
whereas with C you generally see what you're getting.
B.S.
--
Lew