Hacker News Reader

Comment by RayDonnelly | Hacker News Reader

And the notion that a garbage collector should ever be part of a game engine (or anywhere near it) is frankly baffling to me.

.. unless you're making some turn based thing.

View on HN

My games development experience is quite irrelevant, however Tim Sweeney and John Carmack might know a thing or two about game engines.

"The Next Mainstream Programming Languages: A Game Developer's Perspective" by Tim Sweeney

http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt

https://wiki.unrealengine.com/Garbage_Collection_Overview

"Considering that 8 bit BASICs of the 70s had range checked and garbage collected strings, it is amazing how much damage C has done."

John Carmack - https://twitter.com/id_aa_carmack/status/329210881898606593

Quakecon 2013 keynote section about GC

https://www.youtube.com/watch?v=1PhArSujR_A&feature=youtu.be...

Honestly, this is a poor argument. While both Tim Sweeney and John Carmack are legends of the gaming industry, their opinions are still should be taken with a pinch of salt.

Here's why: both Unreal Engine 3 and Unreal Engine 4 are giant OOP behemoths that powers sluggish games and sluggish editors. They consume a rediculous amount of memory, especially in large projects. Even in the slides you linked, they admitted that there is no obvious way to optimize the engine or scale it over multiple cores, because its performance suffers from death by a thousand cuts. Recently Epic spent a huge amount of time trying to optimize their garbage collector, which, arguably, without it they could have better spent the man hours elsewhere. And then there's the new network replication blueprint which is designed to overcome OOP performance issue. And Tim Sweeney swears by OOP. All of these while the industry is moving more and more towards Data Oriented design. Regarding John's tweet, an interesting question was that could he have built the successful Doom games with BASIC? Most likely no.

Well, I would gladly like to know which other game engines, using beautiful Data Oriented design, free of OOP cruft and GC as you put it are able to beat Unreal at this.

"A Star Wars UE4 Real-Time Ray Tracing Cinematic Demo"

https://www.youtube.com/watch?v=lMSuGoYcT3s

"Siren Real-Time Performance"

https://www.youtube.com/watch?v=9owTAISsvwk

After all, it should be relatively easy to challenge such giant bloated sluggish behemoth OOP engine.

As for BASIC, probably. If John made use of a proper BASIC compiler for MS-DOS like PowerBasic, nee TurboBasic, with the right set of compiler flags.

Naturally it would also have its share of inline Assembly, just like Doom, as every owner of "Zen of Assembly Language" first edition knows that C and C++ compilers for MS-DOS weren't the speed daemons developers nowadays taken them for.

You should spend some time learning how AMOS used to be loved on the Amiga Demoscene back in the day.

Not surprised to see such things created with Unreal because they have loads of money and man power to throw at problems. But then again the 2 examples you show does not really fairly represent anything, because the raytracing demo uses super expensive Nvidia hardware that not many people can touch, the second demo also requires specific mocap hardware and there's only one character active in the whole scene. Data oriented is still relatively new, give it some time. But I would say if Unreal 4 was written with data oriented design in the first place, it would have been much better, at least performance wise. Even if it is a mixture of OOP and DOD, no one says you cannot do that. It was a lost opportunity. Working with it right now is a pain, really. After all, if the engine's performance is already so great, why did they need to spend so much time fixing performance problems in their latest releases?

If you want to see what data oriented design can do, with regards to games, you can check out Unity's lastest show of their beta ECS and Job systems. And their custom C# compiler called Burst. Essentially sidestepping the Garbage collector, compile away many of C# safety features, like bounds check, under specific conditions. While processing entities in straight array iteration fashion. All in the name of performance, undoing the damages caused in the past. I guess you know that newer generations of CPUs require effective use of the cache as well as multithreading to extract the full power out. At least Unity technologies should be applauded for trying to do that, and for trying to bring it to the mass.

I'm pretty sure that many game engines do use data oriented design to some capacity, especially those that used to run on PS3. But just because they are not available off-the-shelf, no source code to look at, doesn't mean they don't exist. Off the top of my head is Insomniac Games, arguably successful studio which is also a strong advocate of DOD.

All this is to say that there are times when even the legends hold questionable beliefs, which we should take with a grain of salt.

Yes, I have seen all GDC and Unite 2018 presentations about HPC# and what is currently available.

You should find some submissions done by myself.

HPC# job is only to replace those parts currently written in C++, everything else is written in plain C#, with GC, as Unity always was. In fact they have migrated to .NET 4.6 with 4.7 on the roadmap.

Just like Unreal uses C++ with GC, but naturally in performance critical paths they resort to other techniques.

Which isn't much different than on the old days, avoid malloc() and new on the performance critical paths.

Just because there is a GC available doesn't mean one has to use it for every single allocation.

Unity's ECS is implemented in a OOP language, C#, and anyone that has spent some time in the CS literature about component systems, knows that they are just another variation how to do OOP.

One of the best sources uses Component Pascal, Java and C++ (COM) to described them (1997), with the 2nd edition (2002) updated to include C# as well.

"Component Software: Beyond Object-Oriented Programming"

https://www.amazon.com/Component-Software-Object-Oriented-Pr...

Indeed, you can always say that avoid GC, avoid allocations on the hot path, but then in practice people write sloppy code all the time, then trip over by the GC, I'm guilty of it myself on numerous occasions in the past. Maybe, just maybe, without the GC in the first place, people are forced to write better code? The same thing goes for OOP. In particular, inheritance is severly abused in too many code bases, that then causes all sort of problems. IDK, maybe because I hold an extreme view about those things, that they are better off being left out completely? ¯\_(ツ)_/¯

Early versions of the Build engine were actually written in QBASIC, I think. But I might be mixing my history up.

It was Visual Basic for Windows already.

https://www.gamasutra.com/blogs/DavidLightbown/20180109/3094...

No, I'm talking about the Build engine.

Ah sorry, I had my head on Unreal.

It was a mixture of C and QuickBasic.

http://advsys.net/ken/build.htm

It's not a poor argument at all. The claim was: "And the notion that a garbage collector should ever be part of a game engine (or anywhere near it) is frankly baffling to me. .. unless you're making some turn based thing." But UE4 uses GC. One of the premium games engines uses the very thing that the post claims should never be used in a game engine. I have some sympathy for the idea that GC should at least be tightly controlled and that no-GC has its place. But to claim that GC should never be part of a game engine is simply contradicted by reality.

Well I wasn't arguing with that claim, but rather pjmpl's references to what Tim and John said, that I believe should be taken with a grain of salt.

With regards to GC, do check out Unity3D new ECS/Job system/burst compiler. Essentially sidestepping the garbage collector, C# safety checks, while trying to work with the how the new generation of CPUs are designed to perform.

They aren't sidestepping the garbage collector nor the C# safety checks for the whole engine, because HPC# is only used in a very focused area, everything else is plain old C# as always.

I can also state that in the old days C wasn't worthwhile to be useful as a programming language to write game engines, because proper game engines were written mostly in Assembly with C, Pascal or Basic as their scripting layer if at all.

For example,

https://www.atariarchives.org/

https://www.amazon.com/PC-Intern-Programming-Encyclopedia-De...

I'm a Unity developer. I'm well aware of what the ECS/Jobs/Burst architecture brings. I still disagree with your assertion. Note the fact that this data oriented pivot occurs NOW with Unity. It's managed to do pretty well up to this point despite NOT having that feature. Using GC didn't stop it becoming wildly successful.

No where did I say that the GC hindered Unity's boom in anyway. In fact I do agree that the GC, together with C#, allowed Unity to be wildly successful. But it did so by allow too many people to write sloppy code that has performance problems. And that code would leak memory all over the place without the GC. It is sort of eroding the art of programming.

I'm not sure if you were making a point about Java... but: you can effectively run Java without GC. If collection pauses are an issue you can preallocate everything and ensure no significant GC at runtime.

https://youtu.be/NF6kcNS6U80?t=1000

Reply on news.ycombinator.com