Hacker News Reader

Comment by webkike | Hacker News Reader

GC is the killer of hard real time constraints

GC doesn't kill constraints for games. Unity3D games have been dealing with the GC for ages now, it's not that bad. Cautious use of memory allocations and calling the GC at convenient times go a long way. But on the other hand Java doesn't have value types, which is pretty terrible.

Yes it kills it, there is no big AAA game running on Unity, try to do a Battlefield like game with a GC language where every ms count.

That's actually exactly my point, "kills real time constraints" is very strong language, you end up having to look at AAA games the size of Battlefield to see where it falls short. Minecraft-like games with similar voxel rendering can, and have been, done in Unity. In fact on the internal Nintendo Wii U dev forums I recall a Minecraft-clone was deep in development in Unity, but I think a lack of demand on the platform killed it

A "demo" (with all the limitations and corner-cutting that demos usually employ) is one thing, a complete product is a different beast.

> Cautious use of memory allocations...

I believe you're arguing against a GC there.

I can only speak for Kerbal Space Program, but Unity 5's GC causes stutters on many people's systems, regardless how much RAM is available. There is a wonderful plugin called MemGraph[0] which lets you view GC events and more importantly, to change the time and frequency of GC activation, which has almost completely alleviated stuttering on many systems (my own included).

[0]http://forum.kerbalspaceprogram.com/index.php?/topic/139128-...

Working with the GC is definitely tricky, but I think it's a feature that works well for the majority of the games made with Unity and really only rears it's head in specific types of games of a specific size. Saying it kills realtime constraints for gaming is definitely a stretch. Open world games with no transitions for example, leave little room for natural GC calls, where as level based games can do things like call the GC at the start of each level and carefully budget allocations through out the level.

The "majority" of games made in Unity are very constrained mechanically and developers have control over the complete experience.

"not that bad" is still something that "I don't want to deal with" when I'm making a game. Get rid of GC pauses and let me allocate memory.

It's great that works for you, and there's plenty of ways to take that approach outside of Unity. Like anything technology there are trade offs, having a GC while minimizing allocations can save a lot of time and effort upfront. I see it as Python vs Java, or NoSQL vs SQL, or a host of other similar comparisons that rage on in programming.

What memory management paradigm would you recommend, for an application like this? Let's say, a 1 hour game session generates ~100 GB of transient data, but only 100 MB is needed for what is currently within the camera's view at any one time. How do you keep track of which data is still important, and when do you release memory?

Probably spatial partitioning, although who knows. These things are suitable for theoretics. One must find the best solution.

That's true, but no game is hard real time.

Why then Minecraft works perfectly on PC (even worked perfectly in 2009)?

I personally never checked the fps when playing Minecraft but Minecraft was not extremely computationally intensive. Despite that they still needed to port it to a non GC language to get it running on phones

Beyond just getting it running on phones, C++ is the industry standard for cross-platform games.

On my Mac back when I used to play a couple years ago, I saw random slowdowns. I tried various voodoo Java VM parameter tweaking and it didn't entirely fix it. Based on my searches I'm not alone.

Maybe it worked perfectly on your boxes, but there's something rather fragile and machine-dependent about Minecraft performance.

It certainly didn't work perfectly in 2009. I had to turn off transparent blocks and greatly reduce the draw distance to get decent framerates on my laptop at the time. Maybe you had a better PC then I did. Java Minecraft still requires at least 10x more processing power than it would in a more suitable language.

Java Minecraft definitely used to have lots of issues with large worlds on my 2009 laptop. Low framerates with freezes every time a new region was loaded, even with draw distance on the lowest setting.

Did you ever look at the framerate graph and see the stutter caused by GC? Every time the "allocated memory" counter jumps down, you've got a few frames worth of pause in the graphics, and a big red latency line in the graph.

Reply on news.ycombinator.com