Reference: Java Performance Report, http://www.javalobby.org/features/jpr/ The new section (Part III, Dated Sep 2, 2000), states in part: "IBM holds the best Java scores. Their performance is 60% as fast as Intel C/C++ in Integer code, and 72% as fast in FP code. Compared to Microsoft Visual C++ 6.0, IBM makes Java faster than C in the average, and this is a low-level benchmark that''s heavy on numerical and array code, so this is no mean feat." Amazing! The bottom line is: Java is almost as fast as C now for many things, and if you do game development in Java you will only need to break out into c++/JNI for mundane low level tasks such as talking to 3d cards and asynchronous i/o!

Java compilers one day will almost reach the speed of C++ compilers but never beat compiled C++ code because C++ dosn''t have slow down problem thanks to the garbage collection and data managment restrictions made, unfortunatly will never out perform games which are generally written in a C++/ASM combination.

Don''t get me wrong Java is a good language but it has its practicle uses as being the ideal platform for Application Service Providers thanks to platform independence and will take it place in the games world thanks to Set top box''s but don''t expect to see Java written Quake 3 for a while yet!

I program therefore can''t spell!

pcstiby,

I think there is some things you don''t understand about Java. One of them is that garbage collection is not slower than normal manual clean up. Actually it has been shown to be faster in a lot of cases.

I think you should read this (a link from the forum FAQ)
http://www.rolemaker.dk/articles/WhyJavaCanBeUsedForGames/index.htm
before saying the things you do.

Jacob Marner

Interesting benchmarks, but they have RTTI and Exception Handling turned on in the project settings... could affect performance.

However, it looks like they did their homework and showed that using the right VM, Java can seriously kick ass.


Give me one more medicated peaceful moment.
~ (V)^|) |<é!t|-| ~
ERROR: Your beta-version of Life1.0 has expired. Please upgrade to the full version. All important social functions will be disabled from now on.

This guy forgot to mention GCJ. That is the gnu gcc compiler front end for java. Using that you can natively compile or even cross-compile java byte code (and source) into asm for almost any platform. The only catch is that GCJ still needs libs to run the compiled code against and there isn''t any AWT/Swing/GUI support yet. But if you use another GFX lib (like Qt, or libsdl) you can cross compile those into almost any platform. Also, you can compile java into asm code for systems that do not have a JVM and probably never will, like console systems.

This brings me to a thought I had a while ago and i''m wondering if anyone wants to help. Using java and GCJ to make a dreamcast demo or gameboy advance demo. I say demo because I''m being realistic about the limitations of GCJ and my own experience with these other platforms. If you are intereseted contact me and I will give you the docket of preliminary activities to setting up such a dev environment.

Jim,

It could be way cool if somebody would do such a demo. Go for it.

But, as far as I know GCJ only support Java 1.0 which puts a limitations of what is possible. For instance if you need to access the Dreamcast hardware you need some kind of native interface and as far as I know GCJ doesn''t even support the old NMI interface (the one that existed before JNI). Correct me if I am wrong.

And with no user interface support or native support how would you go around doing anything useful on a console?

Jacob Marner

Going back to the original topic for a sec, i found this post last year, my brother emailed it to me

http://www.aceshardware.com/Spades/read.php?article_id=153

Now, back to gcj. Here is the faq
http://sources.redhat.com/java/faq.html
And here is a quote from it

quote: 2.8 What features of the Java language are/aren't supported.
GCJ supports all Java language constructs as per the Java language Specification v1.0. Recent GCJ snapshots have added support for most JDK1.1 language features, including inner classes.

The only thing it really has a problem with is inner classes. Most of what it cannot handle is restricted to source code, if you can precompile into javabyte code, I think there is very little it cannot handle. It does support JNI now, but it has always had a better alternative CNI. It is like JNI but since the java byte code is going to be natively compiled the CNI knows this and takes advantage of it, leading to less overhead.

I have done my homework on this subject and it does seem feasible.

Edited by - Jim_Ross on September 7, 2000 11:31:44 AM

Ok, sounds like some cool features has been added since I last looked at JGC.

What about portability to the Windows platform - or is it strictly UNIX? I know that Cygnus has made a gcc port for win32, but do you know if it likely that JGC will work with this?
I am concerned about this, as you know Jim, because I see the use of DirectX quite vital.
Using CNI might be a way to speed things up significantly.

Jacob Marner

In answer to my own question:

JGC is actually distributed in binary form with Cygwin (the win32 GCC port) so it is ready to use when you install Cygwin.
Neat. JGC is turning out great.

The only thing that is a bit annoying though is that by CNI I will not be to use standard Java tools such a debuggers and profilers and of course that you no longer is portable across Java compilers.

Jacob Marner

Wow i didn't notice that gcj came with gcc for win32, that's cool.

quote: The only thing that is a bit annoying though is that by CNI I will not be to use standard Java tools such a debuggers and profilers and of course that you no longer is portable across Java compilers.

There are gnu debuggers that will work with CNI enabled java programs. As for the breaking of java code amongst other compilers - who cares?

Seriously, there aren't any other compilers that I know of that will compile Java code into SH4 machine code, so the term "portable across java compilers" makes no sense in that situation. CNI is faster and easier to debug than JNI, you are tying yourself to one platform when you natively compile, so i don't see being tied to one compiler as such a big issue.

Edited by - Jim_Ross on September 7, 2000 2:22:02 PM