5 ms·

This is true, but it mainly just mitigates the problem. It can never solve the problem, because the whole concept of this kind of scheme is that the memory mana

by jblow 8y ago

This is true, but it mainly just mitigates the problem. It can never solve the problem, because the whole concept of this kind of scheme is that the memory manager has some volition of its own ... thus it can choose to do things when you don't want or expect (actually this is unavoidable). Also note that this category of answer is basically saying, "look, if you mostly manage your own memory, then GC takes less time!" That's true, but a large part of the value proposition of GC in the first place was to remove the burden of memory management. Once you are saying actually, GC won't do that for this class of application, then really what you are getting out of GC is memory safety (provided the rest of the language is memory-safe). On the one hand, hey, memory-safety is a benefit. On the other hand, I don't think very many people in game development would trade that much performance just for memory safety. (And in fact in game development we very often have to do unsafe memory things. So really what ends up being said is "much of the system has memory safety" which, really, does not sound very alluring.)

jshap70 8y ago
you've talked about that before, "we very often have to do unsafe memory things", and that a lot of things done in game dev end up violating a lot of principles that are taught in college, but to be honest I'm not sure. granted, I haven't worked directly in game dev before, but i've worked on some projects where runtime perf was the _only_ requirement... and I'm just not convinced that these issues couldn't be worked around using constructs like smart pointers, weak pointers, and just general design principles... that said, the witness is one of my favorite games of all time, so I think its safe to say you know what you're doing
- jblow 8y ago
  The graphics APIs we use are often just about managing raw buffers of memory -- often different areas of memory that have different performance characteristics (Onion Bus vs Garlic Bus, yo). You simply can't do that under constraints of memory safety. But beyond that ... "smart pointers" and the like make your program slow, because they postulate that your data is a lot of small things allocated far away from each other on the heap. I spoke about this in more depth at my Barcelona talk earlier this year.
danShumway 8y ago
> That's true, but a large part of the value proposition of GC in the first place was to remove the burden of memory management. This is a good point. I've spent a fair amount of time trying to build performant stuff on the web, and my conclusion has been that if you really care about memory management, garbage collection is not your friend. You spend more time than is necessary trying to convince the engine not to allocate anything you don't want, trying to lay out objects ahead of time, etc... I have spent more time learning about how Chrome's garbage collection works than I would have ever spent manually tracking references myself. And the end result is that I still have to manually track references and be careful about where things are allocated - the garbage collector for me is objectively a net negative, not just for performance but for dev time and program complexity. And I'm not even really doing anything all that complicated in any of the software I build -- it is not hard to run into these kinds of issues. This is something that I didn't understand until I saw it in my own software, but I strongly suspect that if I could get rid of browser garbage collection I would spend less time thinking about memory than I do now.
- hencoappel 8y ago
  Since you're talking about the Chrome GC I'm going to assume that you're writing code in JS. If that is the case and you have to need such performance that you're having to worry about GC and tacking references then you are probably using the wrong language. Admittedly Web Assembly is pretty new but it sounds like that is your solution, or even asm.js would be worth considering.
- lylecubed 8y ago
  > I have spent more time learning about how Chrome's garbage collection works than I would have ever spent manually tracking references myself. Do you have any good references you can share regarding Chrome's garbage collection? This is a topic I would like to learn more about.
  - danShumway 8y ago
    Unfortunately not - there are probably good resources out there, but most of what I know has come out of manual profiling in Chrome, different experiments, and the occasional StackOverflow post that explains a weird behavior or two. At some point in the future I will probably write a blog post about good techniques for taking back control of JS memory management from the browser, but it probably won't be for a while. The short answer though is that browsers try to defer garbage collection until it looks like the page isn't doing much; and the problem is that games don't ever really stop doing stuff. This encourages the browser to put off garbage collection and handle it in chunks, which in turn leads to dropped frames because you're doing a lot of deallocation at once. This is why if you profile a Chrome app that's doing a lot of allocations very quickly, your memory usage will kind of sawtooth all over the place. And you get around that by getting rid of as many allocations as possible. IMO the lack of garbage collection in WASM is the most exciting thing about it, but different languages have different tradeoffs and WASM isn't appropriate for every application.
pjmlp 8y ago
Although I would argue that in games, memory safety is the door to game cheats, bots and piracy.

by jblow 8y ago

jshap70 8y ago

you've talked about that before, "we very often have to do unsafe memory things", and that a lot of things done in game dev end up violating a lot of principles that are taught in college, but to be honest I'm not sure. granted, I haven't worked directly in game dev before, but i've worked on some projects where runtime perf was the _only_ requirement... and I'm just not convinced that these issues couldn't be worked around using constructs like smart pointers, weak pointers, and just general design principles... that said, the witness is one of my favorite games of all time, so I think its safe to say you know what you're doing

jblow 8y ago
The graphics APIs we use are often just about managing raw buffers of memory -- often different areas of memory that have different performance characteristics (Onion Bus vs Garlic Bus, yo). You simply can't do that under constraints of memory safety. But beyond that ... "smart pointers" and the like make your program slow, because they postulate that your data is a lot of small things allocated far away from each other on the heap. I spoke about this in more depth at my Barcelona talk earlier this year.

danShumway 8y ago

> That's true, but a large part of the value proposition of GC in the first place was to remove the burden of memory management. This is a good point. I've spent a fair amount of time trying to build performant stuff on the web, and my conclusion has been that if you really care about memory management, garbage collection is not your friend. You spend more time than is necessary trying to convince the engine not to allocate anything you don't want, trying to lay out objects ahead of time, etc... I have spent more time learning about how Chrome's garbage collection works than I would have ever spent manually tracking references myself. And the end result is that I still have to manually track references and be careful about where things are allocated - the garbage collector for me is objectively a net negative, not just for performance but for dev time and program complexity. And I'm not even really doing anything all that complicated in any of the software I build -- it is not hard to run into these kinds of issues. This is something that I didn't understand until I saw it in my own software, but I strongly suspect that if I could get rid of browser garbage collection I would spend less time thinking about memory than I do now.

hencoappel 8y ago
Since you're talking about the Chrome GC I'm going to assume that you're writing code in JS. If that is the case and you have to need such performance that you're having to worry about GC and tacking references then you are probably using the wrong language. Admittedly Web Assembly is pretty new but it sounds like that is your solution, or even asm.js would be worth considering.
lylecubed 8y ago
> I have spent more time learning about how Chrome's garbage collection works than I would have ever spent manually tracking references myself. Do you have any good references you can share regarding Chrome's garbage collection? This is a topic I would like to learn more about.
- danShumway 8y ago
  Unfortunately not - there are probably good resources out there, but most of what I know has come out of manual profiling in Chrome, different experiments, and the occasional StackOverflow post that explains a weird behavior or two. At some point in the future I will probably write a blog post about good techniques for taking back control of JS memory management from the browser, but it probably won't be for a while. The short answer though is that browsers try to defer garbage collection until it looks like the page isn't doing much; and the problem is that games don't ever really stop doing stuff. This encourages the browser to put off garbage collection and handle it in chunks, which in turn leads to dropped frames because you're doing a lot of deallocation at once. This is why if you profile a Chrome app that's doing a lot of allocations very quickly, your memory usage will kind of sawtooth all over the place. And you get around that by getting rid of as many allocations as possible. IMO the lack of garbage collection in WASM is the most exciting thing about it, but different languages have different tradeoffs and WASM isn't appropriate for every application.

pjmlp 8y ago

Although I would argue that in games, memory safety is the door to game cheats, bots and piracy.