Well I’m sure you know why is that way.
Basically the name Java has forever been tainted, wrongly so, with poor performance
you shouldn’t associate your commercial products, especially games with java, because it can only hurt you - since there is this prejudice
Well most people are morons and approach everything in life based on prejudice.
Where Java is faster, you can of course implement Java in C and do it that way. Kinda like how you can build anything out of raw materials, assuming you like working with only raw materials. Actually, I rather stretched the truth saying that you can emit any instruction in C, but most modern compilers support “rawcall” conventions and of course embedded asm. Not that you’re really writing C at that point, of course.
Jikes is indeed in C++, but is merely a compiler (and an obsolete one at that). The javac compiler is pure java. Curiously though, the Jikes Research VM is itself in java (presumably with some native code to bootstrap itself).
I’m not disagreeing with that, and I understand it. I just hope we could try to move past that.
I know, I know. I’m pretty aware I’m a total idiot myself and will sometimes ramble about things just based on my feelings about it. But hey, being aware of a flaw is the first step to overcoming it.
Language benchmarks are mostly useful to language implementors. Let me quote the referenced benchmark: "A team at Google created a “simple and compact” benchmark that didn’t take advantage of language-specific features. An algorithm was implemented using each language’s “idiomatic container classes, looping constructs, and memory/object allocation schemes.”.
“Simple & compact” = can’t be testing much.
“memory/object allocation schemes” = using default malloc/free in C++ which is dumb if you want high performance.
“didn’t take advantage of language-specific features” = WTF? The not much tested is totally meaningless.
Every single time I’ve compared code that I’ve implemented in Java and C, the C version completely smokes the Java…no contest…not even close.
In other words: you suck at Java ;D
In other words: I’m realistic.
Switching to serious mode: I can’t agree or disagree with you, I’ve lost exactly what you are referring to. If I compare my C code to Java code that performs the same task, the Java code wins at all times. Because its far easier to read, often more compact and written and debugged in far less time. That’s my personal reality.
Taking a step back, most folks really shouldn’t care about the speed difference between C/C++ and Java. They’re smallish linear differences say between 4-20x. And most people will only see the bottom end of that range because they aren’t going to be taking advantage of SIMD and cache oblivious methods (to name a couple). And more to the point most people don’t need to push tons of computations. And since the speed difference is linear, algorithmic improvement is much more important than the choice of language. Likewise moving away from single threaded to multi-threaded should give a nice additional linear boost. Now of course the same changes could be applied to a C/C++ version as well, so it boils down to your point: which language (or some other choice) can you to get the job done in the least amount of engineering time (and to spec)? Choose that language and run with it.
What am I referring to is simple. I only benchmark very expensive computations and C/C++ exposes a closer to the metal feature set which allow for very significant performance gains. We’ve covered what Java’s (actually the JVM) missing to allow to help close the gap pretty much ad nauseam. Sometimes some programming trickery (a la Riven’s structure library) can help, but mostly we’re SOL until some features are added to the JVM.
Not serious mode: Java? compact? And you said that with a straight face?
If I may ask, what were you benchmarking, and where do you think the Java slowdown was? I am highly skeptical of these claims.
If you go http://benchmarksgame.alioth.debian.org/u64q/java.php, C does much better than Java.
Personally, I’ve ported some signal processing code between C, Java, C#, and Scala. C ran with 20% less time than Java. C# ran much slower than Java (Windows, Microsoft implementation). Scala actually ran ~5-10% faster than Java which surprised me because I thought they would compile to roughly the same bytecode and run on exactly the same runtime.
And that’s what I said. These benchmarks should java being between 2-37x slower than GCC, and GCC is a hunk of junk.
No they don’t! :
It’s 1x-2x processing time and 1x-37x memory usage. What did you say about compact earlier? 
Shame on me for looking at the wrong column.
2-37x slower? You aren’t even pretending to make a rational argument. This is pure trolling. My skepticism is quite justified.
structures, arrays of structures, SIMD, cache preload hints, non-temporal stores, load fences, store fences. Questions?
Personal attacks are not appreciated.
If some of this isn’t clear to some folks…look at this java vs. java comparison which peaks at over 43x (or again some number’s for Riven’s library). Avoiding cache misses is a very big deal in high performance…where each is hundreds to thousands of less operations being performed (and constantly growing since the CPU memory gap grows). The previous covers when you can half-assed work around (in a PITA way) a JVM missing feature…but what about when you can’t? An example is: I’m never going to attempt to write an edge based cache obv. quad-tree in java, unless I get struck with inspiration or get structures.
Cache misses are indeed expensive, but the articles clearly shows (at the end) that the bottleneck is not cache misses, but the GC that tries to clear 50M objects with each run, taking between 1s and 10s for a full GC and a few of them happening per run. If the GC is running >20s per run, while the compact data version is running in ~0.8s, it’s obvious that we can’t just blame cache misses.
IMHO the article doesn’t so much show the advantages of optimal memory usage, but shows the inability of the GC to efficiently handle a certain use case.
My skimming skills seem to need a little fine-tuning. Still the end result is that having structures supported by the JVM would make our lives easier. To convert this example into something that might happen in real-line, then it would also be nice to have arraylets (also mentioned in that array 2.0 talk).