Jump to content
  • Advertisement


This topic is now archived and is closed to further replies.


Java Speed tests

This topic is 6938 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

One of the major issues java is not ready for serious commercial game development is not being able get direct access to the display, sound and input hardware.

Although, I have read a few articles on how some big game companies are using java for their current games, but they are only using it as a scripting language. What I mean is they write all of the game engine code in asm/c/c++ but all of the game logic is written in java. There is a custom JNI interface that allows java to hook into the engine. I believe John Carmack considered this approach for Q3. Of course using a JNI interface defeats the cross platform benefit of Java.


Share this post

Link to post
Share on other sites
Accessing the screen directly is just asking for trouble. Just draw to an offscreen bitmap and copy that to the active window. You''re less likely to run into OS or hardware problems that way.

And guess what, that''s how Java does it! Well, I guess they might know what they''re doing.

It probably won''t be long before they add a good 3D package to standard Java. That''d be better then using VB with a 3D package.

E:cb woof!

Share this post

Link to post
Share on other sites
I do not see the problem : Java is a nice clean OO language and C++ is an extremely powerful, much more difficult OO language. (I personnally do not count C in C++)

Java is getting faster each day, right now you can find native compilers which make it as fast as C++ (I mean C++ with virtual methods).

But I do not think that you will ever achieve optimized C++ speed for several reasons :
- almost everything is dynamical, including core libraries
- there is no annotation in Java comparable to C++''s const
- there are no real templates, which means many typecasts / typechecks
...and I am just mentionning compiled Java so far.

As for dynamically-compiled Java (JIT), I will just point out that compiling simple C++ programs with compiler-optimizations can take minutes at 80+% CPU. This is a delay you cannot afford with JITs. And if you do it as a background task, you just slow down your program.

But all this does not matter. A speed factor of 2 does not even matter. They just mean that you have to wait for the next generation of computers. What is important is, as always, the algorithms you use.

Be reading you,

Share this post

Link to post
Share on other sites
Original post by Jerry Lynn

The lack of multiple inheritance is not a language limitation. Almost all modern languages and underlying object systems do not allow multiple inheritance. Most OO analyst caution against using it as it has been shown to be a flawed concept.

I have to disagree and say that multiple inheritance solves certain problems far more elegantly than a single inheritance solution could. Interfaces can provide some of this functionality but not all.


Your first statement about optimized code development is fundamentally incorrect. It is possible to have the same code optimized for platform specific execution by a run-time complier.

No, there is a big difference here. The runtime optimizer, no matter how well it is done, is not going to have all the information that a developer has. As such, I could take advantage of specific ASM code that takes into account certain assumptions made by me, the developer, about the progression of my code. This will perhaps become even more of an issue when the new instruction sets become available, that place more of the burden of optimization on the developer and compiler. (This includes things such as choosing what data to precache, for example. I know what I want caching. An optimiser generally will not, unless it knows my game as well as I do.)


In fact, back end optimization systems have advantages over developers optimizing code because run-time optimization systems can take into account local variables such as memory availability on particular systems.

This is an advantage, but not necessarily as big as the disadvantage shown above. I can perform run-time optimization within my C/C++ code, to a degree, without losing the really low-level benefits.


Further, if you can have 95% optimized code or 100% optimized code that cost FIVE times as much which option do you think most business are going to choose?

5 times as much? That''s an arbitrary figure plucked from nowhere. C++ is almost as quick a language for developing in as Java if you use the provided string class and some socket library (which many developers will already have). The difference is that many developers, in the end, will -choose- to invest a lot of time in low-level optimisation, because that 5% extra performance is the difference between being "The fastest 3D game around today" and just another FPS.

When it comes down to it, languages don’t become the dominant standard because they are fast. They become the standard because they increase developer productivity. With almost every language generation we have LOST performance. We lost performance when we went to C++ from Assembly. VB is MUCH slower than C++, and yet there are now 3 million VB developers building every thing from mission-critical business management software to games.

This is largely because (a) Visual C++ is crap for app development, and (b) MS have integrated Visual Basic code into Office etc. Not because the language is any good. The language is, quite frankly, awful

But, the point is that there are different tools for different needs. Visual Basic will never overtake C++ as the language of choice because of its disadvantages. Instead, it will faithfully serve its little niche, just like Cobol or Prolog.


Java has been documented to provide in some cases a five-fold increase in developer productivity over C++. As technology advances the performance issues will disappear and there will be no reason left to use C++ for the bulk of all development (this might come as a surprise but device drivers represent a small part of all development).

Ah, so that''s where the ''5x'' figure came from. It''s still utterly arbitrary. Performance issues will never disappear, as in the multimedia field there will always be a need to be 5% faster than the competition. When we''re all running in 3200x2800x32 bit colour at 100fps, someone else will want to do the same resolution at 120fps. If developers find Java to be 5% slower than C++, then they''re not going to bother moving over until all their competitors have. And their competitors will think the same thing, so it''ll most likely never happen.

Many games these days use their own byte-code language as opposed to straight C/C++. This provides them with many of the rapid-development issues of which you speak, except directly applicable to their problem domain, rather than the general purpose solution that is Java. Proprietary languages on top of low-level code is the way the industry will go, I think.

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!