Hacker News Reader

Comment by adgjlsfhk1 | Hacker News Reader

IMO java for gamedev is pretty much un-viable due to the lack of control over memory layout. You clearly can make it work (see Minecraft), but it just sounds painful, and there isn't a clear benefit.

View on HN

Minecraft wouldn't be anywhere near where it is today if it was not written in Java (which made modding much easier compared to native code, and made heavy modding possible). So there is a strong benefit, it's just not very obvious.

Minecraft performance is a joke in 2021, when you see how much CPU you need to get 10 players in a world.

It is written in Java because the original devs probably did not know anything better.

It uses that much CPU because the original devs did not know how to program well and it allocates a shitton of objects. It is not a good example of a well-written java game.

There are many types of games. For 2D games Java is more than performant enough, without question.

Java can be ridiculously fast when only primitives are used so I wouldn’t put a quite performant game engine past it, but yeah, it would perhaps not be my first choice for a new AAA game engine.

C# has a similar memory model and it's the primary language used by Unity games... would you say that's un-viable?

For memory layout C# actually has an important difference in that it supports value types (so you can have an array of vertices without individually allocating each one, which has a lot of overhead and drastically reduces cache efficiency). They’ve been working on adding support for that to Java for some time but it’s not in yet.

The game engine is different from the game logic. This may mean Java is more viable for game logic, but still not viable for the engine itself

That said, C# has value types and has for years now. Which is hugely important for arrays, and a major, major missing piece to the Java performance puzzle. C#'s FFI is also way better than the disaster that is JNI, which also plays a role here.

You are right, but I would like to add that both of these concerns will be solved in the near-far future. Java’s project Panama tries to tackle the less than ideal FFI case with a tool that can create java classes from a C header and an API for manually managing memory regions.

While Valhalla is in the works, but it is, I quote, at least 3 PhD’s worth of knowledge combined to figure it out in a backwards compatible way with all the interactions of generics, etc.

There is no control over it in pure standard APIs, but if you are shipping a game you could do it with JVM specific ways or even ship a custom / customized GC.

But most games don't actually need this. I'd be more concerned about whether there's a JVM language you like over other non JVM options for a game.

What kind of games do you need to worry about memory layout for? From the outside, I'd expect that it's as diverse as most software, where sometimes you need control like C and other times python will do.

> From the outside, I'd expect that it's as diverse as most software, where sometimes you need control like C and other times python will do.

I develop games as a hobby, and my understanding is that this is literally true, but a little misleading. Games are as diverse as other areas of software, but they're skewed toward the more complex and demanding end. I don't think it's that atypical for a moderately complex game by an indie studio to get to the point where memory layout is a concern, which I don't think is as true for web apps, desktop apps, or other areas of development. That being said, I think worrying about memory layout is more than a lot of games need.

Why is controls over memmory layout important for Games?

If you work on Android games for example would you get any kind of control over mem layout, irrespective of the stack you will be using?

For a simple example if you make a simple type to store the color of a pixel

class RGB { float r float g float b ... }

and then make an `ArrayList<RGB>` the list will end up using over 2x the memory (128 bytes for object headers, 64 bytes for pointers in the list) compared to a language with value types. What makes this even worse is that since you are using a list of pointers, you can't use SIMD for any of your computations, and accessing elements will be slow since the values won't be in cache.

Just to add, the really performance oriented hot loops can be rewritten with Class-of-Arrays with three int arrays for r, g and b values, or even a single one with flattened ints, with a user-friendly wrapper RGB class provided for outside use. With good OOP-usage it would not even be ugly. Performant java code has been written like that for decades, and these will get really close to C-programs.

Also, there is now a Vector API that let’s you use SIMD operations with configurable lane width (and a safe fallback to for loops for processors without the necessary instructions)

To add to adgjlsfhk1’s answer, if you are writing Android games you are probably using a cross-platform game engine that doesn’t use Java (like Unity) which solves the issue but more importantly also allows you to sell your game on iOS without a re-write.

Look up "data oriented design" GDC talks or "AoS and SoA" for more in depth information to your question. The very brief tldr is that if you want to go fast, you have to design for cache locality and memory access patterns.

In particular for Java there's regularly dependent pointer loads, which are dreadfully slow on modern CPUs and also waste a significant amount of L1/L2 cache.

While not the most ergonomic, one can definitely create SoAs in Java and those will be just as fast as they are in low level languages.

Reply on news.ycombinator.com