Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Game Development in Go

j15r.com

Post reply on HN
Print view View original

41–50 of 60 posts

Re: Game Development in Go

#41

Post by pcwalton »

hedgehog wrote: post #40
joelgwebber wrote: post #33

Earlier quoted context omitted.

Yes, sort of. Not generating a large amount of garbage can still give the runtime an opportunity to reduce the amount of work done per collection pass. A naïve heuristic for determining when to run GC will give you the typical "sawtooth" pattern, because you generate garbage until hitting a fixed ceiling threshold, collect it all, then wash, rinse, repeat. But a game that's not completely pegging the CPU will have so…

Right now Go uses the naive heuristic you describe, there's no concurrent or incremental collection so no matter how long it takes to get to the GC it'll be a stop-the-world collection and potentially take a long time. I forgot to mention that besides reducing the amount of on-heap data you can also speed up collections in the current GC by lowering the GC threshold (SetGCPercent). This does come at the cost of colle…

> Go might eventually get a generational GC but my understanding is that that pretty much requires a copying GC and there are concerns with C interop (right now you can point to Go memory from C).

It does. Also note that incremental GC in Go is going to have different performance characteristics than incremental GC in JavaScript, because of the fact that Go's GC has to be thread-safe.

Re: Game Development in Go

#43

Post by joelgwebber »

hedgehog wrote: post #40
joelgwebber wrote: post #33

Earlier quoted context omitted.

Yes, sort of. Not generating a large amount of garbage can still give the runtime an opportunity to reduce the amount of work done per collection pass. A naïve heuristic for determining when to run GC will give you the typical "sawtooth" pattern, because you generate garbage until hitting a fixed ceiling threshold, collect it all, then wash, rinse, repeat. But a game that's not completely pegging the CPU will have so…

Right now Go uses the naive heuristic you describe, there's no concurrent or incremental collection so no matter how long it takes to get to the GC it'll be a stop-the-world collection and potentially take a long time. I forgot to mention that besides reducing the amount of on-heap data you can also speed up collections in the current GC by lowering the GC threshold (SetGCPercent). This does come at the cost of colle…

Indeed. I'm hopeful that the concurrent GC will get it to the point where it can do a lot better than that "10ms out of every 50" promise in 1.4. If not, then well, I guess we will have learned that Go isn't great for games after all.

/me crosses fingers.

Re: Game Development in Go

#44

Post by joelgwebber »

agmcleod wrote: post #39
joelgwebber wrote: post #33

Earlier quoted context omitted.

Yes, sort of. Not generating a large amount of garbage can still give the runtime an opportunity to reduce the amount of work done per collection pass. A naïve heuristic for determining when to run GC will give you the typical "sawtooth" pattern, because you generate garbage until hitting a fixed ceiling threshold, collect it all, then wash, rinse, repeat. But a game that's not completely pegging the CPU will have so…

> but the second was when V8 committed an incremental collector Did the chrome developers have to fix v8 for that one?

This was a fairly obscure bug lurking in the DOM/API bindings. They have to do a bunch of wacky stuff to deal with the interactions between the V8 GC and the ref-counted native API objects. In this case, the TypedArray wrapper objects were implemented in such a way that allocating them would often trigger a full mark/sweep (which also, IIUC, contained the logic necessary to free up reference cycles in native objects pinned by V8). My understanding is that all that stuff is much better now, and much less likely to lead to such pathological behavior.

Re: Game Development in Go

#45

Post by jblow »

FreezerburnV wrote: post #22
eropple wrote: post #15

Earlier quoted context omitted.

Minecraft's also had a ton of time invested into racing the beam with regards to the JVM GC. Not disagreeing with the viability of it, I personally use the CLR because I'm comfortable with that tradeoff and doing my work there too, but it is worth noting that a sufficiently complicated game will spend a lot of time dealing with memory issues. I'd use either the JVM or the CLR long before Go, though.

I think it's worth it to note that "a sufficiently complicated game will spend a lot of time dealing with memory issues" applies to all games. The memory issues might just be different. Or they could be simpler. Most games (especially large ones) tend to end up with multiple ways of garbage collecting eventually, even if written in pure C++. And that isn't even taking into account cache coherency, NULL pointers, doub…

It's bad.

The reason is because you don't control the GC and don't even necessarily know what exactly drives the decisions it makes. So once you want to go beyond a certain level of performance, there is no right answer. You are just randomly trying stuff and kind of flailing.

In C++ (or another direct-memory language), there is a right answer. You can always make the memory do exactly what you want it to, and there's always a clear path to get there from wherever you are.

Re: Game Development in Go

#46

Post by eropple »

zamalek wrote: post #24
eropple wrote: post #15

Earlier quoted context omitted.

Minecraft's also had a ton of time invested into racing the beam with regards to the JVM GC. Not disagreeing with the viability of it, I personally use the CLR because I'm comfortable with that tradeoff and doing my work there too, but it is worth noting that a sufficiently complicated game will spend a lot of time dealing with memory issues. I'd use either the JVM or the CLR long before Go, though.

> JVM or the CLR long before Go, though. Possibly only because they have been around for longer. The CLR 1.0 GC was a terrible beast. I'm sure that the earlier Java GCs were horrible things, too. > sufficiently complicated game will spend a lot of time dealing with memory issues. This is precisely why gamedevs are going for data oriented design, it all does come down to this at the end of the day. In theory a GC does…

Sorry, I didn't mean to imply that I'd use them because of Go's garbage collector, which is vastly improved and arguably the best part of the entire ecosystem these days. I'd use the JVM or the CLR mostly because I am more convinced than I am about almost any technical topic that Go is a creeping, faddish horror that resists decent design practices for applications over a trivial scope, made by a team that took all the wrong lessons from Java and C++ and made a language worse than one or the other at almost every task that I can think of.

Re: Game Development in Go

#47

Post by eropple »

jblow wrote: post #45
FreezerburnV wrote: post #22

Earlier quoted context omitted.

I think it's worth it to note that "a sufficiently complicated game will spend a lot of time dealing with memory issues" applies to all games. The memory issues might just be different. Or they could be simpler. Most games (especially large ones) tend to end up with multiple ways of garbage collecting eventually, even if written in pure C++. And that isn't even taking into account cache coherency, NULL pointers, doub…

It's bad. The reason is because you don't control the GC and don't even necessarily know what exactly drives the decisions it makes. So once you want to go beyond a certain level of performance, there is no right answer. You are just randomly trying stuff and kind of flailing. In C++ (or another direct-memory language), there is a right answer. You can always make the memory do exactly what you want it to, and there'…

> The reason is because you don't control the GC and don't even necessarily know what exactly drives the decisions it makes.

I appreciate the flexibility and choice that a direct-memory language provides, but I think "randomly trying stuff and kind of flailing" is over-the-top. On the JVM you can control the GC quite effectively, with an understanding of the JMM and some experience its behaviors become largely predictable, and profile-directed memory optimization can be tedious, but certainly isn't random. Most Java developers I know are sometimes surprised by the JVM's behaviors...but then, most Java developers I know aren't terribly interested in how the JVM works.

(My professional, non-game work is historically mainly on the JVM. I use the CLR for my game projects because even mobile platforms have an embarrassing surplus of performance relative to my needs and it's a lot more cross-platform than the JVM. I'm comfortable enough in C++, but I'm much slower at working with it--and I'm slow enough that I need all the help I can get!)

Re: Game Development in Go

#48

Post by pjmlp »

jblow wrote: post #45
FreezerburnV wrote: post #22

Earlier quoted context omitted.

I think it's worth it to note that "a sufficiently complicated game will spend a lot of time dealing with memory issues" applies to all games. The memory issues might just be different. Or they could be simpler. Most games (especially large ones) tend to end up with multiple ways of garbage collecting eventually, even if written in pure C++. And that isn't even taking into account cache coherency, NULL pointers, doub…

It's bad. The reason is because you don't control the GC and don't even necessarily know what exactly drives the decisions it makes. So once you want to go beyond a certain level of performance, there is no right answer. You are just randomly trying stuff and kind of flailing. In C++ (or another direct-memory language), there is a right answer. You can always make the memory do exactly what you want it to, and there'…

> You can always make the memory do exactly what you want it to, and there's always a clear path to get there from wherever you are.

Only if you write your own memory allocator, otherwise relying on the compiler provided allocator is no different.

Re: Game Development in Go

#49

Post by pjmlp »

joelgwebber wrote: post #25
Thaxll wrote: post #5

I already asked here before but what is the status of the GC regarding real-time games? ( for a gameserver )

Here's my take on GC in games, FWIW. I'd be very leery of using a VM with a garbage collector for the entirety of a game. They can be fine (and are extremely common) in embedded scripting languages, but it can be far too difficult to control the size of outlier pauses when everything on the heap is subject to GC. As mentioned elsewhere in this thread, the JVM GC has had an enormous amount of effort put into it, and i…

There are a few German studios using Erlang and JVM languages for their MMOs on the server side.

Re: Game Development in Go

#50

Post by jblow »

pjmlp wrote: post #48
jblow wrote: post #45

Earlier quoted context omitted.

It's bad. The reason is because you don't control the GC and don't even necessarily know what exactly drives the decisions it makes. So once you want to go beyond a certain level of performance, there is no right answer. You are just randomly trying stuff and kind of flailing. In C++ (or another direct-memory language), there is a right answer. You can always make the memory do exactly what you want it to, and there'…

> You can always make the memory do exactly what you want it to, and there's always a clear path to get there from wherever you are. Only if you write your own memory allocator, otherwise relying on the compiler provided allocator is no different.

Which is why people who are serious about memory write their own allocators (or link preferred allocators with known behavior). It is an extremely common thing.
Post reply on HN