Why I Write Games in C (yes, C) • Hacker News Board

Re: Why I Write Games in C (yes, C)

#121

Post by ArtWomb » Sat, Sep 21, 2019, 6:37 PM UTC

zemo wrote: post #46

> The stop-the-world garbage collection is a big pain for games, stopping the world is something you can't really afford to do. I love this opinion from games programmers because they never qualify it and talk about what their latency budgets are and what they do in lieu of a garbage collector. They just hand wave and say "GC can't work". The reality is you still have to free resources, so it's not like the garbage c…

You're right, this is a good discussion! Unity introduced an incremental GC that splits the work over several frames, essentially performing an entire sweep "for free"

https://blogs.unity3d.com/2018/11/26/feature-preview-increme...

I have mad respect for all using low level C / Assembly / Rust in gamedev. But I have a hard time recommending anything other than C# / Unity for secondary school 14-15 year olds just starting their journey. The wealth of resources, tutorials and community online is astounding. And as an entrypoint into VR / AR it's difficult to top ;)

Re: Why I Write Games in C (yes, C)

#122

Post by modeless » Sat, Sep 21, 2019, 6:38 PM UTC

zemo wrote: post #46

> The stop-the-world garbage collection is a big pain for games, stopping the world is something you can't really afford to do. I love this opinion from games programmers because they never qualify it and talk about what their latency budgets are and what they do in lieu of a garbage collector. They just hand wave and say "GC can't work". The reality is you still have to free resources, so it's not like the garbage c…

> If you have a garbage collector that runs in 200us

The problem is GCs for popular languages are nowhere near this good. People will claim their GC runs in 200us, but it's misleading.

For example, they'll say they have a 200us "stop the world" time, but then individual threads can still be blocked for 10ms+. Or they'll quote an average or median GC time, when what matters is the 99.9th percentile time. If you run GC at every 120 Hz frame then you hit the 99.9th percentile time every minute.

Finally, even if your GC runs in parallel and doesn't block your game threads it still takes an unpredictable amount of CPU time and memory bandwidth while it's running, and can have other costs like write barriers.

Re: Why I Write Games in C (yes, C)

#123

Post by gambiting » Sat, Sep 21, 2019, 6:39 PM UTC

>>Nobody does this.

I disagree - I work at a AAA games studio and we're currently building a little project made entirely in C. Not even a hint of C++. This is probably going to end up being just a little research thing in the end, but don't think that no one does this anymore.

Re: Why I Write Games in C (yes, C)

#124

Post by ChrisSD » Sat, Sep 21, 2019, 6:43 PM UTC

the_gipsy wrote: post #22

ChrisSD wrote: post #5

So... essentially "I know and like C". Which is great! But as you say, that's not particularly useful for anybody else.

The guy should try Rust and then explain why he prefers either, that would be interesting.

I'm not sure that rehashing Rust vs. C is particularly interesting at this point. At least not for those who regularly read HN. Maybe in another few years...

Re: Why I Write Games in C (yes, C)

#125

Post by metiscus » Sat, Sep 21, 2019, 6:43 PM UTC

pm90 wrote: post #113

majewsky wrote: post #107

Earlier quoted context omitted.

> It is also possible to allocate a large block of memory and then manage it yourself. At which point you're mostly just writing C in Go.

Actually you're not. I would very much prefer a stripped down version of Go used for these situations rather than throwing more C at it. The main benefits of using Go are not the garbage collection, its the tooling, the readability (and thus maintainability) of the code base, the large number of folks who are versatile in using it.

Are you saying that there are more go developers than c developers? Is there a user survey that shows such things? I'm curious what the ratio is.

Re: Why I Write Games in C (yes, C)

#126

Post by jmnicolas » Sat, Sep 21, 2019, 6:45 PM UTC

xamuel wrote: post #12

The author despises OOP, and I agree with him there. I would add that OOP can be particularly bad for games , because often times the OOP vocabulary clashes with the game's own vocabulary: the game itself has objects (as in, things the player can pick up and put in their inventory), the game itself has classes (as in RPG classes). It might even have factories, depending on the game. All support for OOP would vanish o…

GameObject, GameClass, GameFactory

Re: Why I Write Games in C (yes, C)

#127

Post by mrec » Sat, Sep 21, 2019, 6:46 PM UTC

kristoff_it wrote: post #78

the_gipsy wrote: post #22

Earlier quoted context omitted.

The guy should try Rust and then explain why he prefers either, that would be interesting.

He clarified in the post that he doesn't like the complexity that C++ brings, he probably won't appreciate Rust's either.

He very definitely won't like Rust's compile/link times.

Re: Why I Write Games in C (yes, C)

#128

Post by fluffything » Sat, Sep 21, 2019, 6:46 PM UTC

stephc_int13 wrote: post #74

zemo wrote: post #46

> The stop-the-world garbage collection is a big pain for games, stopping the world is something you can't really afford to do. I love this opinion from games programmers because they never qualify it and talk about what their latency budgets are and what they do in lieu of a garbage collector. They just hand wave and say "GC can't work". The reality is you still have to free resources, so it's not like the garbage c…

I know this subject quite well and I will later publish a detailed article. The real run-time cost of memory management done well in a modern game engine written without OOP features is extremely low. We usually use a few very simple specialized memory allocators, you'd probably be surprised by how simple memory management can be. The trick is to not use the same allocator when the lifetime is different. Some resourc…

+1. We have a large Rust code base, and we forbid Vec and the other collections.

Instead, we have different types of global arenas, bump allocators, etc. that you can use. These all pre-allocate memory once at start up, and... that's it.

When you have well defined allocation patterns, allocating a new "object" is just a "last += 1;` and once you are done you deallocate thousands of objects by just doing `last -= size();`.

That's ~0.3 nanoseconds per allocation, and 0.x nano-seconds to "free" a lot of memory.

For comparison, using jemalloc instead puts you at 15-25 ns per allocation and per deallocation, with "spikes" that go up to 200ns depending on size and alignment requirements. So we are talking here a 100-1000x improvement, and very often the improvement is larger because these custom allocators are more predictable, smaller, etc. than a general purpose malloc, so you get better branch prediction, less I-cache misses, etc.

Re: Why I Write Games in C (yes, C)

#129

Post by kccqzy » Sat, Sep 21, 2019, 6:47 PM UTC

krapp wrote: post #32

htk wrote: post #11

Very interesting point of view. I wish I had projects (like games) that could benefit to craft meticulously with C. The feel of coding closer to the hardware is great.

I'm not sure C is that much closer to the hardware, nowadays.

C is closer to the hardware in the sense that with any given C code, I can pretty much predict what the generated assembly will look like. You cannot say the same for, say, Python.

Re: Why I Write Games in C (yes, C)

#130

Post by kllrnohj » Sat, Sep 21, 2019, 6:47 PM UTC

zemo wrote: post #46

> The stop-the-world garbage collection is a big pain for games, stopping the world is something you can't really afford to do. I love this opinion from games programmers because they never qualify it and talk about what their latency budgets are and what they do in lieu of a garbage collector. They just hand wave and say "GC can't work". The reality is you still have to free resources, so it's not like the garbage c…

One of the key other things that surprisingly hasn't been mentioned is it's super important to control memory layout.

GC pause times are relevant but not critical. What's critical is that I can lay out my objects to maximize locality, prefetching, and SIMD compatibility. Look up Array of Structs vs Struct of Arrays for discussions on aspects of this.

This is not strictly incompatible with a GC in theory, however it's common that in GC'd languages this is either very difficult or borderline impossible. The JVM's lack of value types, for example, makes it pretty much game over. Combining a GC with good cache locality and SoA layout is possible, but it doesn't really exist, either. Unity's HPC# is probably the closest, but they banned GC allocations to do it.