Java performance

B

borophyll

I am just interested in the latest stats on Java performance. A lot
of the literature appears to be out of date in this respect. Is it
true that Java performance is close to that of native compiled code?
I suppose it could be said that Java *is* natively compiled (at run
time), but there will surely be performance penalties due to bytecode
translation, at least at program startup.

Can Java be used for graphics-intensive applications, such as the
latest 3D game, such as Doom/Quake/whatever is the current hot game.
If not, what are the issues that prohibit Java from being suitable.

Finally, I have read that garbage collection is generally more
efficient than manual memory management. Is this true, and if so,
why?

Please feel free to mention anything else that is relevant...

Regards,
B.
 
H

Hunter Gratzner

I am just interested in the latest stats on Java performance. A lot
of the literature appears to be out of date in this respect. Is it
true that Java performance is close to that of native compiled code?
Yes.

I suppose it could be said that Java *is* natively compiled (at run
time), but there will surely be performance penalties due to bytecode
translation, at least at program startup.

Yes, at startup.
Can Java be used for graphics-intensive applications, such as the
latest 3D game, such as Doom/Quake/whatever is the current hot game.

Current? Well, there is e.g. a Quake 2 engine port to Java
http://bytonic.de/html/jake2.html

There are other game engines, too. E.g. http://www.jmonkeyengine.com/

And there are other types of graphic intensive applications, too. CAD
systems have been written in Java, so have GIS systems. People do
complex simulations in Java and all kinds of computational intensive
stuff.
If not, what are the issues that prohibit Java from being suitable.

For what? Games? Game users might be used to all kinds of long startup
times, so Java's typical long startup times might not be an issue.
Game users are also used to be able to use a number of HID devices
(joysticks, wheels). There is a total lack of out-of-the-box support
in Java for such devices. There are third-party libraries to overcome
this. There is also an almost total lack of out-of-the-box integration
into advanced sound engines. Java-sound does not cover all details.
There are maybe third-party libraries to fix this, I am not aware of
any. There is at best mediocre media support (video playing, MP3
playing). The Java media framework has been neglected for years.

What is really bad in Java is desktop integration. Interaction with
native installation management or package management does not exist.
All things which are closer to the system are bad. Dealing with
removable media in general is bad, e.g. figuring out if a CD or DVD is
in a drive can't be done with Java alone. Dealing with all kinds of
system services is bad. Typical desktop I/O (serial, USB, parallel
ports, Firewire) is not or badly supported.

There is only one compelling technical reason to do a desktop
application in Java. When you really, really, really badly, need the
cross-platform features of Java so your application runs on multiple
platforms. The price you will have to pay for this is that the
application will look and behave slightly alien on all supported
platforms. And some things won't work at all.
Finally, I have read that garbage collection is generally more
efficient than manual memory management. Is this true, and if so,
why?

It has advantages and disadvantages. You can study the details for
ages. But in short it usually doesn't hurt and is in general "better",
unless you mess up things.
 
L

Lew

Hunter said:

Or faster, sometimes.
It has advantages and disadvantages. You can study the details for
ages. But in short it usually doesn't hurt and is in general "better",
unless you mess up things.

Whereas platforms without GC require more code to handle allocation and
deallocation, and will cause trouble if you mess up things.

Allocation of a new object on the heap in Java is on the order of 10x fewer
machine instructions than in C++. Deallocation of young objects, on the order
of 95% of all objects in most programs (particularly if you're versed in Java
idioms), is essentially zero cost.

More importantly, GC greatly reduces the window of opportunity for
memory-management bugs. As Hunter says, there are ways to defeat its advantages.

Furthermore, there are multiple algorithms available. Try to duplicate the
scalability of Sun's parallel GC algorithms in a non-GCed environment. The
era of the single-processor computer is giving way to a multi-processor world.

Never mind how Java's GC harmonizes with Hotspot compilation.

-
Lew
 
C

Christian

I am just interested in the latest stats on Java performance. A lot
of the literature appears to be out of date in this respect. Is it
true that Java performance is close to that of native compiled code?
I suppose it could be said that Java *is* natively compiled (at run
time), but there will surely be performance penalties due to bytecode
translation, at least at program startup.

Can Java be used for graphics-intensive applications, such as the
latest 3D game, such as Doom/Quake/whatever is the current hot game.
If not, what are the issues that prohibit Java from being suitable.

I would say problematic is that for example OpenGL needs native
librarys.. calling these via jni has an overhead that will kill your
performance.

The other thing which I have seen is that java may have caught up with
performance.. though a little overhead stays .. specially if you not
program c++ but hack c++ you can gain some bits of performance that may
be relevant for one of the latest games to even run on a machine (like
doing bitflipping in a pointer to traverse a list of vertices really fast).

Java is a great language but it doesn't fit for everything. Thinking
Java and its features like the runtime optimization will fix everything
for you in speed that the additional security like typechecking or
nullpointer checking costs you is I think hybris.
 
L

Lew

Christian said:
I would say problematic is that for example OpenGL needs native
librarys.. calling these via jni [sic] has an overhead that will kill your
performance.

Well, maybe not "kill", but it will have an impact. The trick is to have the
native method do enough work to make up for the overhead of the JNI barrier.

Unfortunately, you are correct about OpenGL needing JNI.
 
K

Knute Johnson

Hunter said:
Yes, at startup.


Current? Well, there is e.g. a Quake 2 engine port to Java
http://bytonic.de/html/jake2.html

There are other game engines, too. E.g. http://www.jmonkeyengine.com/

And there are other types of graphic intensive applications, too. CAD
systems have been written in Java, so have GIS systems. People do
complex simulations in Java and all kinds of computational intensive
stuff.


For what? Games? Game users might be used to all kinds of long startup
times, so Java's typical long startup times might not be an issue.
Game users are also used to be able to use a number of HID devices
(joysticks, wheels). There is a total lack of out-of-the-box support
in Java for such devices. There are third-party libraries to overcome
this. There is also an almost total lack of out-of-the-box integration
into advanced sound engines. Java-sound does not cover all details.
There are maybe third-party libraries to fix this, I am not aware of
any. There is at best mediocre media support (video playing, MP3
playing). The Java media framework has been neglected for years.

What is really bad in Java is desktop integration. Interaction with
native installation management or package management does not exist.
All things which are closer to the system are bad. Dealing with
removable media in general is bad, e.g. figuring out if a CD or DVD is
in a drive can't be done with Java alone. Dealing with all kinds of
system services is bad. Typical desktop I/O (serial, USB, parallel
ports, Firewire) is not or badly supported.

There is only one compelling technical reason to do a desktop
application in Java. When you really, really, really badly, need the
cross-platform features of Java so your application runs on multiple
platforms. The price you will have to pay for this is that the
application will look and behave slightly alien on all supported
platforms. And some things won't work at all.


It has advantages and disadvantages. You can study the details for
ages. But in short it usually doesn't hurt and is in general "better",
unless you mess up things.

The coming JRE is going to have greatly improved startup performance.

https://jdk6.dev.java.net/6uNea.html

I've played with it a little bit on windows and there does seem to be
some performance increase.
 
R

Roedy Green

Can Java be used for graphics-intensive applications, such as the
latest 3D game, such as Doom/Quake/whatever is the current hot game.
If not, what are the issues that prohibit Java from being suitable.

There is VolatileImage which gives you ability to rapidly bitblt
inside the regen.

I have not played with Java 3D.

In the old days you poked the hardware directly with machine code. I
presume today you have device drivers to access the clever parallel
processing hardware in the video cards. The key would be how
impedance matched the Java API is to the device driver API on any
given platform. Java is always constrained my the least common
denominator principle. In general, it can't use features of a
platform unless all platforms support it.
 
J

Joshua Cranmer

I am just interested in the latest stats on Java performance. A lot
of the literature appears to be out of date in this respect. Is it
true that Java performance is close to that of native compiled code?
I suppose it could be said that Java *is* natively compiled (at run
time), but there will surely be performance penalties due to bytecode
translation, at least at program startup.

In the extreme short-term (i.e., in the first few minutes), Java is
going to have noticeable impact: one comparison metric gives it about
1.2-1.3 times native code (after taking startup into account). Over
longer periods of time--especially if the server VM is used--Java
performance is near, at, or better than native compiled code.
Finally, I have read that garbage collection is generally more
efficient than manual memory management. Is this true, and if so,
why?

In most cases, yes. Part of the problem is that manual management is
manual and people are not quite as good at profiling memory as computers
are. In addition, garbage collection can more easily benefit from
parallel execution, a bonus in the coming days of multi-core CPUs and
other parallelization techniques.
 
C

Christian

Joshua said:
In the extreme short-term (i.e., in the first few minutes), Java is
going to have noticeable impact: one comparison metric gives it about
1.2-1.3 times native code (after taking startup into account). Over
longer periods of time--especially if the server VM is used--Java
performance is near, at, or better than native compiled code.


In most cases, yes. Part of the problem is that manual management is
manual and people are not quite as good at profiling memory as computers
are. In addition, garbage collection can more easily benefit from
parallel execution, a bonus in the coming days of multi-core CPUs and
other parallelization techniques.

though there seem to be other problems with compiling in java ...
I once heard the term "hotspotless" code used for GUI parts written in
pure java..
meaning that java's guis have the problem that they are not hot spots
... as a user won't klick each button that often resulting in gui code
not being compiled down to native code but just allways being
interpreted which might result in an unreactive GUI as an effect (or at
least a GUI that is less reactive than a native couterpart)
 
R

Roedy Green

In the extreme short-term (i.e., in the first few minutes), Java is
going to have noticeable impact: one comparison metric gives it about
1.2-1.3 times native code (after taking startup into account). Over
longer periods of time--especially if the server VM is used--Java
performance is near, at, or better than native compiled code.

On an older machine you will notice a difference the Swing GUI makes.
It has an extra layer of overhead between the application and the
hardware. With a 2 GHz machine you likely won't notice it. It as fast
enough to keep up with a human.
 
J

Joshua Cranmer

Christian said:
.. as a user won't klick each button that often resulting in gui code
not being compiled down to native code but just allways being
interpreted which might result in an unreactive GUI as an effect (or at
least a GUI that is less reactive than a native couterpart)

I don't really understand the first part of your sentence, but I can
deal with the last part of it:

Unresponsive GUIs are more a symptom of poor programming skills (e.g.,
someone's doing too much in the EDT that could be done elsewhere) than
of native-versus-non-native code problems. I have seen native GUIs
become unresponsive just as much--in both Windows and Linux implementations.

In fact, from the little I know of various toolkit implementations, this
is just as much a problem in Java Swing code as it is GTK2 or Windows API.
 
R

Roedy Green

though there seem to be other problems with compiling in java ...
I once heard the term "hotspotless" code used for GUI parts written in
pure java..
meaning that java's guis have the problem that they are not hot spots
.. as a user won't klick each button that often resulting in gui code
not being compiled down to native code but just allways being
interpreted which might result in an unreactive GUI as an effect (or at
least a GUI that is less reactive than a native couterpart)

The whole point of hotspot is you don't waste the RAM for native code
or the CPU time to optimally compile unless the method is frequently
used.

Sun people are primarily thinking today about server code that runs
for days at time. What counts is how well it performs after the first
5 minutes of running.

The big desktop or Applet performance hit today is the time it takes
to load the Java run time and hotspot hundreds of standard classes. I
have suggested ever since I first encountered Java they could greatly
speed up launch by precompiling a set of commonly used classes and
capturing the RAM image with a process I call gespenstering I used in
DOS Abundance to create relocatables out of raw RAM images.
 
S

Sherman Pendley

I am just interested in the latest stats on Java performance. A lot
of the literature appears to be out of date in this respect. Is it
true that Java performance is close to that of native compiled code?

True in many cases, yes.
I suppose it could be said that Java *is* natively compiled (at run
time), but there will surely be performance penalties due to bytecode
translation, at least at program startup.

That's one reason that Java is currently far more popular for long-running
server applications than it is for browser applets or desktop apps. Startup
time isn't such a big deal when the app is rarely killed and restarted.
Can Java be used for graphics-intensive applications, such as the
latest 3D game, such as Doom/Quake/whatever is the current hot game.
If not, what are the issues that prohibit Java from being suitable.

I've quite a bit of experience in cross-language development (see my .sig),
and in my experience the cost of crossing the language barrier tends to be
pretty high. That doesn't make Java unsuitable for high-performance 3D apps,
it just means you need to carefully think about and manage how your Java
code calls the low-level 3D rendering functions.
Finally, I have read that garbage collection is generally more
efficient than manual memory management. Is this true, and if so,
why?

It's easier than some manual schemes, and about on par with others. It's
definitely easier than old-school malloc()/free(). But, there are "semi-
manual" techniques such as those used in C++ (stack-based objects and STL
collections) or Objective-C (autorelease pools and design patterns that
support them) that are also much easier than the old-school approach.

Sun likes to pretend that the old-school approach is the only possible
alternative to Java, so as to make Java look better in comparison. The
truth isn't as black-and-white as that.

sherm--
 
?

=?ISO-8859-1?Q?Arne_Vajh=F8j?=

Christian said:
I once heard the term "hotspotless" code used for GUI parts written in
pure java..
meaning that java's guis have the problem that they are not hot spots
.. as a user won't klick each button that often resulting in gui code
not being compiled down to native code but just allways being
interpreted which might result in an unreactive GUI as an effect (or at
least a GUI that is less reactive than a native couterpart)

I find it hard to believe that the effect of like 20 statements
in an actionPerformed being JIT'ed or not should be noticeable.

A difference between 1 micro second and 20 microseconds is
relative big. But a GUI user needs damn sharp eyes to notice
the difference.

Arne
 
R

Roedy Green

The coming JRE is going to have greatly improved startup performance.

https://jdk6.dev.java.net/6uNea.html

"The Quick Starter feature will prefetch portions of the JRE into
memory, substantially decreasing the average JRE cold start-up time
(the time that it takes to launch a Java application for the first
time after a fresh reboot of a PC)."

Sounds like they are loading a pre-loaded RAM image to get the basic
classes going. Yea! I have been asking for this since day 1.
 
B

borophyll

I am just interested in the latest stats on Java performance. A lot
of the literature appears to be out of date in this respect. Is it
true that Java performance is close to that of native compiled code?
I suppose it could be said that Java *is* natively compiled (at run
time), but there will surely be performance penalties due to bytecode
translation, at least at program startup.

Can Java be used for graphics-intensive applications, such as the
latest 3D game, such as Doom/Quake/whatever is the current hot game.
If not, what are the issues that prohibit Java from being suitable.

Finally, I have read that garbage collection is generally more
efficient than manual memory management. Is this true, and if so,
why?

Please feel free to mention anything else that is relevant...

Regards,
B.

Thanks all for the responses. The feeling I am getting is that Java
is not very suitable for apps where it needs to interact quite closely
with the machine (such as graphics, device I/O) because of large
runtime overhead of JNI. Can this overhead be circumvented by
compiling Java to native code? Or is it unavoidable for some reason..

Does Java suffer from GC pauses anymore(on UP systems), or are they a
thing of the past?

<OT> I am looking for a language that is as close to the metal as C++,
yet has garbage collection, which I think is a better idea than manual
mm. Any ideas? </OT>
 
L

Lasse Reichstein Nielsen

Roedy Green said:
"The Quick Starter feature will prefetch portions of the JRE into
memory, substantially decreasing the average JRE cold start-up time
(the time that it takes to launch a Java application for the first
time after a fresh reboot of a PC)."

Sounds like they are loading a pre-loaded RAM image to get the basic
classes going. Yea! I have been asking for this since day 1.

That, or they are making yet another "QuickStart" that loads and takes
up memory at boot time, whether you use it or not.
It can sit next to Office QuickStart, Firefox Quickstart and
a gazillion other programs that think they are so important that
you have to start everything but the GUI every time you start
your machine.

/L
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,734
Messages
2,569,441
Members
44,832
Latest member
GlennSmall

Latest Threads

Top