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

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

#341

Post by theresistor » Sun, Sep 22, 2019, 1:05 AM UTC

PrototypeNM1 wrote: post #322

mntmoss wrote: post #254

Earlier quoted context omitted.

The semantics matter. A lot of game engines use a mark-and-release per-frame allocation buffer. It is temporary throwaway data for that frame's computation. It does not get tracked or freed piecemeal - it gets blown away. Garbage collection emulates the intent of this method with generational collection strategies, but it has to use a heuristic to do so. And you can optimize your code to behave very similarly within…

> A lot of game engines use a mark-and-release per-frame allocation buffer. I've heard of this concept but a search for "mark-and-release per-frame allocation buffer" returned this thread. Is there something else I could search?

It’s just a variation of arena allocation. You allocate everything for the current frame in an arena. When the frame is complete. You free the entire arena, without needing any heap walking.

A generational GC achieves a similar end result, but has to heuristically discover the generations, whereas an arena allocator achieves the same result deterministically And without extra heap walking.

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

#342

Post by takeda » Sun, Sep 22, 2019, 1:08 AM UTC

xyproto wrote: post #271

littlestymaar wrote: post #220

Earlier quoted context omitted.

You're not using the GC at all then. Why use Go (and praise its GC) in that case?

Go has many advantages over C that are not related to GC.

Go was pushed as a C replacement, but very few C programmers switched to it, it seems like it took hearts of some of Python, Ruby, Java etc programmers.

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

#343

Post by squeaky-clean » Sun, Sep 22, 2019, 1:10 AM UTC

viraptor wrote: post #329

drudru11 wrote: post #261

Earlier quoted context omitted.

Wow - disabling the caches is an extreme measure. I get it though. After doing that, you can (probably) do cycle counting on routines again. Just like the 80s or earlier.

I don't. Maybe we're thinking about different kind of caches, but if these are transparent, no-performance-impact caches, then why wouldn't you prove the system works well with caches off (guarantee deadlines are met), then enable caches for opportunistic power gains?

You'd have to very solidly prove that in the wors-case a cache only ever make execution time equal to or faster than a processor not using cache and never causes anything to be slower.

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

#344

Post by gameswithgo » Sun, Sep 22, 2019, 1:12 AM 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 can choose when and how and if to free resources rather than having it be rather opaque with the GC, that is the key.

Though people who make games sometimes overstate the importance of this. Minecraft is arguably the most successful game of all time despite GC pauses. A competitive shooter like CS:Go, however, can't have that.

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

#345

Post by kenoath » Sun, Sep 22, 2019, 1:15 AM UTC

billjings wrote: post #281

axaxs wrote: post #267

Earlier quoted context omitted.

You can do the same thing in GC'd languages, though.

Here's the easy question: can you do manual GC in a GC'd environment? Yes, of course you can. Here's the harder question: how hard is it to do manual GC in a GC'd environment vs. a non-GC'd environment? "Environment" is the key word here. Because if you're writing in a GC'd environment, there's a good chance that existing code - third party, first party, wherever it comes from - assumes that it can heap allocate obje…

This was almost exactly my experience when I wrote a network simulator in Go and tried to improve the performance. The gc pauses reached tens of seconds haha, I made a lot of garbage.

I'm not completely sure if this is true but I think that doing things in an "OO" style where for example, every different event was it's own type which satisfies the Event interface basically means that different events can't occupy an array together and that I think that each one may hold a pointer to some heap allocated memory, so you really can't optimise this away without ripping up the entire program.

Rather than do so, I ended up running my Sim on a server with >100 cores, it was single threaded but they would all spin up and chomp the GC, a beautiful sight.

Another factor is just the general lack of transparency or knowability of where and how objects occupy memory in these languages.

If memory management is likely to be a concern it is absolutely much easier in an environment where it is prioritized than one where it is ignored.

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

#346

Post by Baeocystin » Sun, Sep 22, 2019, 1:16 AM UTC

viraptor wrote: post #329

drudru11 wrote: post #261

Earlier quoted context omitted.

Wow - disabling the caches is an extreme measure. I get it though. After doing that, you can (probably) do cycle counting on routines again. Just like the 80s or earlier.

I don't. Maybe we're thinking about different kind of caches, but if these are transparent, no-performance-impact caches, then why wouldn't you prove the system works well with caches off (guarantee deadlines are met), then enable caches for opportunistic power gains?

Because you lose deterministic behavior, and there are cases where that is non-negotiable, regardless of performance cost.

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

#347

Post by detaro » Sun, Sep 22, 2019, 1:20 AM UTC

coldtea wrote: post #331

detaro wrote: post #319

Earlier quoted context omitted.

What percentage of the market is A/V build to actual hard real-time standards, and not expected to run on devices that can't provide it (so no PCs with normal OSes, no smartphones)? For the vast majority, soft real-time is fine, since an occasional deadline-miss results in minor inconvenience, not property damage, injury or death. I assume some dedicated devices are more or less hard real time, due to running way sim…

> For the vast majority, soft real-time is fine, since an occasional deadline-miss results in minor inconvenience, not property damage, injury or death. A "minor inconvenience" like a recording session going wrong, a live show with stuttering audio, skipped frames in a live TV show, and so on?

As long as the individual event happens seldom enough few of these actually are a big problem. Soft real-time being allowed to blow deadlines doesn't mean it can't be expected to have a very high rate of success (at least that's the definitions I've learned), and clearly a sufficiently low rate of failure is tolerated. There's a vast difference between "there's an audio stutter every day/week/month/..." and "noticeably stuttering audio". The production side is obviously a lot more sensitive about this than playback, but will still run parts e.g. on relatively normal desktop systems because the failure rate is low enough.

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

#348

Post by gameswithgo » Sun, Sep 22, 2019, 1:26 AM UTC

zemo wrote: post #98

stephc_int13 wrote: post #74

Earlier quoted context omitted.

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…

as an example point, the Go garbage collector clears heaps of 18gb in sub-millisecond latencies. If I'm understanding the problem at hand (maybe I'm not!), given an engine running at a target framerate of 144 frames per second, you're working with a latency budget of about 7ms per frame. Do you always use all 7ms, or do you sometimes sleep or spin until the next frame to await user input? We can also look at it from…

Go's GC has latencies that would be good enough for a great many games, but its throughput might become problematic, and in general, as a language it is problematic for the kinds of games that would worry about GC pauses, since FFI with c libraries is very expensive. If that could be solved Go might be very appealing for many many games.

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

#349

Post by nicoburns » Sun, Sep 22, 2019, 1:27 AM UTC

cozzyd wrote: post #270

weberc2 wrote: post #188

Earlier quoted context omitted.

In my experience it takes a few days for a moderate programmer to come up to speed on Go, whereas it takes several months for C. You need to hire C programmers for a C position, you can hire any programmers for a Go position.

If they don't already know C though, how well will they cope with manual memory management?

How do people learn C without knowing about manual memory management? They learn about it as they learn the language. This can be done in any language that allows for manual memory management (and most have much better safeguards and documentation than C, which has a million ways to shoot yourself in the foot)

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

#350

Post by gameswithgo » Sun, Sep 22, 2019, 1:28 AM UTC

weberc2 wrote: post #335

stephc_int13 wrote: post #299

Earlier quoted context omitted.

This is an example. I never worked with Unity myself but I worked with people using Unity as their game engine, they all had problems with stuttering caused by the GC at some point. You can try to search Unity forums about this subject, you'll find hundreds or thousands of topics. What really bothers me with GC is that it solves a pain I never felt, and creates a lot of problems that are usually more difficult to sol…

What is Unity’s STW time? Is it optimized for latency? If not, you’re using the wrong collector. The pain point it solves is time spent debugging memory issues and generally a slower pace of development, but of course if you’re using a collector optimized for throughout, you’ll have a bad time. Further, a low-latency GC will pay off more for people who haven’t been using C or C++ for 10 years than those who have.

It is very nice to say that, in theory, a GC could work very well for performance demanding games. But until someone builds that GC, in an environment where everything else is suitable for games also, it is academic. We can't actually build a game with a theoretical ecosystem.