good intentions for supporting Java
Though I feel like it was written poorly, quickly, and with little actual research or knowledge.
Its unfortunate
[quote]some tests suggest that Java can actually exceed the speed of C/C++ in certain cases
[/quote]
I have said that for years ;D
I have said that for years ;D
[/quote]
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.
Cas 
I have said that for years ;D
[/quote]
You do realise that the JVM is written in C++, so its odd saying that Java is faster
Java’s main advantage is that you have to work less for better or equivalent results.
[quote=“kappa,post:11,topic:36933”]
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.
Yeah, @kappa’s argument isn’t a good one really Though there are other factors such as the GC which are written in C, etc. but indeed, the bytecode compiler produces machine code, it’s not C++.
It just doesn’t produce machine code that’s anywhere near as fast as natively written C++ code does… yet.
Cas
iiii knew that, just testing :persecutioncomplex:
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.
@namrog84 - it’s more like about 50% not 5% for games, typically.
(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 fucked every one of them up.
Cas
is it really a 50% performance increase? I didn’t think it was nearly that high? (Java isn’t that bad? is it )
What about non games?
Yeah I know a lot goes into content development, from level design, balancing, art, media, etc…
I was always quite discouraged that they didnt manage to get a JVM on the 360 or ps3
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.
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.
Cas
I can get 60 fps on 30 dollar hardware new for 2d action games and next year it will be 25 dollars and 12 months from now it will be 20 dollars.
So Java is plenty fast.
Well, it’s fast enough for the piddly things we want to do, but I can’t see myself writing anything utterly mind blowing any time soon
Cas
I went to the Java 7 release meeting yesterday. (Did they show the audience in the live stream? I was the fellow with the plate of food on my lap in the first side row. :D)
The new File system is touted to be an order of magnitude faster, if I read the charts correctly.
There are some cool things like fork/join (to send/split a task into two or more threads presumably on their own cpus) that also could lead to significant pickups in performance.
So we could be seeing some improvements, not that what we have is at all bad.
The estimation that Java is 50% slower than C++ seems overly pessimistic to me.
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 disagree with most of the above. First an interesting link:
The Ubiquitous SSE vector class: Debunking a common myth
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++.
Brilliantly worded, Spasi. That’s the article should have said.
Some resources for people that want to know more about data-oriented programming:
Pitfalls of Object Oriented Programming (pdf)
Data-Oriented Design (Or Why You Might Be Shooting Yourself in The Foot With OOP)
Data-Oriented Design Now And In The Future
Data-Oriented Behavior Tree (heavy read, especially the 3rd part, but really useful insight on the process of going from OO to DO)
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.
This is really, really interesting - thank you for posting it.
A question - suppose you’re writing a particle system in a data-oriented way. So among other things, you’re storing lots of x,y coordinates that you then plan to iterate over.
There are quite a few ways to represent that data:
float [] coords; // x, y -> coords[i], coords[i+1]
float [][]coords;
Vector2f [] coords;
LinkedList<Vector2f> coords;
ArrayList<Vector2f> coords;
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?