Blogpost about Java for Game Programming

[nsigma]

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? 

[Roquen]

Shame on me for looking at the wrong column.

[gene9]

And that's what I said.  These benchmarks should java being between 2-37x slower than GCC, and GCC is a hunk of junk.

2-37x slower? You aren't even pretending to make a rational argument. This is pure trolling. My skepticism is quite justified.

Games published by our own members! Check 'em out!

[Roquen]

structures, arrays of structures, SIMD, cache preload hints, non-temporal stores, load fences, store fences.  Questions?

[Riven]

You aren't even pretending to make a rational argument. This is pure trolling. My skepticism is quite justified.

Personal attacks are not appreciated.

[Roquen]

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.

[Riven]

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).

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.

[Roquen]

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).