It's quite odd that he start "I am speaking to anyone but console/mobile/AAA developers here."Androis is biggest mobile platform now and it's still growing fast. So why rule all mobile developing with Java at start.

some tests suggest that Java can actually exceed the speed of C/C++ in certain cases

I have said that for years

We do reasonably have to concede though that 99% of the time C++ is considerably faster most of the time. Java 7 will narrow the gap a little more. Riven's sneaky Unsafe code could further narrow it where it counts for games developers.

You do realise that the JVM is written in C++, so its odd saying that Java is faster

It is not odd as I studied the way of implementing programming languages during my (unfinished) Master degree, I know a bit what I'm talking about. I have read several times some parts of the source code of Java, I noticed that there is some C source code some years ago, I have only noticed some C++ code recently when trying to recompile OpenJDK. Java uses both C, C++ and assembler, I don't understand why it is odd to say that it is faster than C++ as Java is not C++, Java uses these other languages cleverly which explains why several IBM researchers in high performance computations told that Java can be faster than C/C++, especially in terms of speed of allocation and method calls.

I believe Watson, The worlds best Jeopardy player (the super smart conversation AI) was written in mostly Java.

Clearly he is super intelligent and calculating millions of words, tones, emphasis, and other variables all the time at super high speed!

As stated before, honestly the difference in speed if less than 5% doesn't really matter that much in the grand scheme of things. You can look at a console for example and see mind blowingly different capabilities within the same system, and it comes down to how much time and effort programmers came to push the system.

And as stated before, even if we stated C++ had a 5% better performance boost naturally over Java. If you can write the same code in 30% less time(if you take into account the Java is supposed to make things easier for programmers), that 30% time saved can then be converted into making "better" code and thus end up being faster than C++ given the same time constraints.

And if you are triple AAA big business and a particular form of calculation or method is faster in a specific language, I thought most "BIG BIG Companies and applications/games" usually had programs that utilized several languages at once because sometimes a different languages perform certain task significantly better.

(I was going to say that this is a problem but really it's only a problem for the sort of games that need to use 100% of what's out there and that's basically AAA titles. And we all know how many AAA titles have been written in Java.)

Also, coding is a rather small part of the development budget these days. Saving 30% off of a mere 10% of the budget is barely worth it considering the huge tradeoffs a studio would have to make to switch to a Java toolchain. A bit of a catch-22 situation unfortunately. But largely brought about by senior Sun mismanagement. There should have been a shit hot JVM on PS3 and indeed 360 and iPhone but they f**ked every one of them up.

is it really a 50% performance increase? I didn't think it was nearly that high?

Lack of SIMD really hurts. On 'old' CPUs the performance difference was factor 2, now it's factor 4, as modern CPUs don't spread SSE2 operations over two cycles anymore.

When doing vector math, 90% of the CPU time is still spent in 0.5% of your code, and that 0.5% will not even be remotely as fast as hand-optimized assembler -- 50% doesn't even come close in *that* part of your engine.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

Overall yes I'd say Java is about half the speed of C++ for games in typical situations, and that doesn't even take into account the lightning fast startup time of native code (which believe me does have quite an effect on perceived performance). Some sorts of stuff as Riven points out are tragically slow in Java, unfortunately the kinds of stuff that are very common in games programming. Some serious effort in SSE optimisation for the Sun JVM wouldn't go amiss. The other big bottleneck is bounds checking.

The biggest difference between C++/Java and even C and Java is the *programmer*. The Langs are close enough for the most part that its the quality and experience of the coder that makes the most difference. At whcih point one just needs to ask which lang lets the coder work on the important part of coding rather than tedious details. IMO all 3 languages suffer from forcing to work too much on tedium. But java is better if only because it has a half decent standard library.

Seriously after 15+ years of internet and C++/C doesn't have sockets as as part of its standard library? What are they thinking?

Of course there are exceptions to all this and sometimes java is not the right tool. But may times neither is C/C++.

Yes i put C/C++ together because there are lot of coders who just won't code C++ and you are left with C looking C++. At least in commercial circles.

I have no special talents. I am only passionately curious.--Albert Einstein

The answer to the question "Is Java as fast as or faster than C++" is: it depends. On so many factors actually that there's no point trying to do any general comparisons, outside the context of a real-world application.

Memory access is so much more expensive than most calculations that happen in between. This is a fact that applies to 99% of the code in 99% of the programs ever written, it's true for both CPUs and GPUs and will be true until a radically different micro-processor architecture is invented. There's only one way to get around this bottleneck and that's by designing your data structures and memory access patterns in a way that gives compilers and, more importantly, CPUs themselves (x86 CPU pipelines do this independently of whatever language you've written your program in) an easy way to identify what you're trying to do. The first obvious benefit is that you properly utilize the memory caches and the second is the memory prefetching that can happen, when the access pattern is clear enough to be predictable. As a side note, console CPUs don't have the necessary circuitry to detect access patterns, that's why programmers need to use compiler hints to make it happen (another reason we haven't seen Java on consoles so far).

This basically boils down to linear data structures and simple loops. That's why JVM engineers keep asking people to write the simplest code possible. Simple == optimizable and this has nothing to do with Java. None of the above is any more special in Java than in C++. It just so happens that software people writing in C++ usually have the experience to design their code with all that in mind, whereas Java programmers tend to ignore it. Data-orientation is much more important than object-orientation and not only for performance. It's much easier to parallelize a simple loop on a simple data structure (e.g. with fork/join), than a calculation happening on a complex object graph.

Bounds checking is also dirty cheap on x86. For the same reason actually, the array memory access is orders more expensive than the conditional jump before it, which the CPU has already predicted will not happen for the next X iterations (that is, it's almost free, simple noise compared to the rest of the code). Some Java programmers think "crap, it's bounds checking again, I need to fix this" and they go ahead and redesign their code. Which is good! Bounds checks occur on every iteration when the JVM cannot understand your code.. which is basically when you've written cache unfriendly code. "Fixing" the bounds checks doesn't yield a performance increase because you've removed the conditional jump, it's because you've started utilizing the precious cache properly.

Finally, because always "it depends", when you've tried everything and you're sure you have a bottleneck than can't be fixed any other way, there's a thing called OpenCL available. It's here and it works (heck, it's already in browsers too). There's no reason to go down to JNI and assembly hacks to get top of the line performance, when it's so easy to use OpenCL through Java. All you need is LWJGL and Riven's magic mapped objects.

Btw, AAA titles means amazing graphics (= GPU, the expensive engines do their best to minimize CPU usage - few draw calls etc) + physics (= GPU, else you get the simple version of it) + absolutely brilliant pre-baking of game data (= offline work, performance doesn't matter). Most games use scripting for their game code too. Again, nothing to do with language or performance, but it has to do with the platform. Java isn't an option because it cannot run on consoles, not because of the few disadvantages it has compared to C++.

These should get you started, google is your friend after that. It's kind of a hot topic for game devs (and, not only) lately and there's plenty of info available. I've recently implemented a benchmark to test the theory behind the first article, mainly to see the effects it would have to the way code is written. The result was much much better code clarity; in the OOP case in order to have a complete understanding of what's happening you need to navigate the object graph, jump from method to method etc, it's really taxing on your short-term memory even with good IDE support. In the DOP case, the code is right in front of you, as a series of simple steps. As for performance, close to 3x faster for the Java implementation, 40x (!) for the OpenCL implementation (including the GPU readback).

Note that neither me nor the people that wrote these articles suggest that OOP is inherently bad. It's just that data should always come first. Design for data, not code. Have the code go to the data, not the other way around. It's simple and applies equally well to both OOP and procedural programming.

It seems pretty clear that the 1-dimensional array is the best way to go, but are the other choices still beneficial in terms of utilizing the cache well and allowing prefetching to happen (incidentally, what is trying to figure out the memory access pattern to prefetch - the jvm when it's compiling into native code, or something much lower-level?)

It seems like having an array or even list of objects would still be ok as long as they are allocated at about the same time, and thus probably contiguous in memory (can you count on the JVM to do that?). I guess that would break down when particles expire, and new ones get allocated elsewhere, while in the array case it'll stay contiguous. But, you could use pooling for the objects.

Am I thinking of this the right way? Is it mostly about keeping data in a contiguous chunk of memory, so that when a page is loaded into the cache, you get as much useful data from it as possible?

I wonder what they did in JDK 7 that made my sprite engine so much faster - word has it they removed rather a lot of bounds checking though. So the noise argument may be true to some extent with the very latest chips and JDKs but everywhere else ... when you do something 100,000 times a frame and it's twice as fast in C++ ... there we go.

The DOP way of doing things is so right though (if I recall correctly the PS3 absolutely forces you to think in terms of shoving data through it in this way). Java doesn't really make it particularly easy though I hope that Riven's hackery will make it somewhat more viable.

It seems pretty clear that the 1-dimensional array is the best way to go, but are the other choices still beneficial in terms of utilizing the cache well and allowing prefetching to happen (incidentally, what is trying to figure out the memory access pattern to prefetch - the jvm when it's compiling into native code, or something much lower-level?)

For such a simple example, float[] would be best, followed by float[][]. Note that the 2D array should be float[2][count] and not float[count][2]. For anything more complex, I'd use Riven's mapped objects for good performance and nice code. Without it you'd have naked data in arrays and even though performance would still be great, code would be a mess (and very hard to refactor). Especially if you want to interact with GL/CL and you're using NIO buffers instead of arrays.

There are x86 instructions for prefetching in different instruction sets (e.g. SSE has some), but I don't know if the JVM uses them. In any case, x86 CPUs can detect patterns in the instruction stream and do prefetching automatically. I guess this has lots of limitations and prerequisites, which supports the argument for simple loops even more.

It seems like having an array or even list of objects would still be ok as long as they are allocated at about the same time, and thus probably contiguous in memory (can you count on the JVM to do that?). I guess that would break down when particles expire, and new ones get allocated elsewhere, while in the array case it'll stay contiguous. But, you could use pooling for the objects.

Using objects won't work because of what I'm describing here, 3rd paragraph. With the way GC works, there's no guarantee your objects will remain contiguous in memory, even when you're not de-allocating or re-allocating anything. I can't find the source now, but I read recently that JVM engineers have acknowledged this and they're investigating ways to improve it. But honestly, I don't think you'll ever be able to get the exact behavior required, whereas with explicit allocations your data will be contiguous by definition.

An option for more OO code could be to use handles. Instead of references to objects you use references to handles. A handle contains the index where you can find the object data, meaning you have an extra indirection in exchange for potentially cleaner code. This is a good description, a bit C++ specific though.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org