Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Java performance

Reply
Thread Tools

Java performance

 
 
borophyll@gmail.com
Guest
Posts: n/a
 
      11-04-2007
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.

 
Reply With Quote
 
 
 
 
Hunter Gratzner
Guest
Posts: n/a
 
      11-04-2007
On Nov 4, 12:41 pm, (E-Mail Removed) wrote:
> 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.

 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      11-04-2007
(E-Mail Removed) wrote:
>> 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?


Hunter Gratzner wrote:
> Yes.


Or faster, sometimes.

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


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
 
Reply With Quote
 
Christian
Guest
Posts: n/a
 
      11-04-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) schrieb:
> 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.

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

 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      11-04-2007
Christian wrote:
> 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.

--
Lew
 
Reply With Quote
 
Knute Johnson
Guest
Posts: n/a
 
      11-04-2007
Hunter Gratzner wrote:
> On Nov 4, 12:41 pm, (E-Mail Removed) wrote:
>> 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.
>


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.

--

Knute Johnson
email s/nospam/knute/
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      11-04-2007
On Sun, 04 Nov 2007 11:41:46 -0000, (E-Mail Removed) wrote, quoted
or indirectly quoted someone who said :

>Is it
>true that Java performance is close to that of native compiled code?


You have the option of native compiled code with Jet. See
http://mindprod.com/jgloss/benchmark.html

Jet produces BETTER code than hand assembly.

--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      11-04-2007
On Sun, 04 Nov 2007 11:41:46 -0000, (E-Mail Removed) wrote, quoted
or indirectly quoted someone who said :

>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.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
Reply With Quote
 
Joshua Cranmer
Guest
Posts: n/a
 
      11-04-2007
(E-Mail Removed) wrote:
> 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.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      11-04-2007
Knute Johnson wrote:
> 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.


If you really are talking about Java 6, it's been out already for almost a year.

--
Lew
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Performance Tutorials Services - Boosting Performance by DisablingUnnecessary Services on Windows XP Home Edition Software Engineer Javascript 0 06-10-2011 02:18 AM
Web Form Performance Versus Single File Performance jm ASP .Net 1 12-12-2003 11:14 PM
Java performance hints and tips? Ahmed Moustafa Java 9 07-16-2003 03:16 AM
Weak Java performance with Sony Ericsson T610? totojepast Java 0 07-10-2003 03:52 PM



Advertisments