4 ms·

From your link (which I remember reading at the time): > So by simply reducing GC frequency, we saw close to a ~99% drop in mark assist work, which translated

by titzer 5y ago

From your link (which I remember reading at the time): > So by simply reducing GC frequency, we saw close to a ~99% drop in mark assist work, which translated to a~45% improvement in 99th percentile API latency at peak traffic. Did you look at the actual article? (Because it doesn't support your point). They added a 10GB memory ballast to keep the GC pacer from collecting too much. That is just a bad heuristic in the GC, and should have a tuning knob. I'd argue a tuning knob isn't so bad, compared to rewriting your entire application to manually malloc/free everything, which would likely result in oodles of bugs. Also: > And it's bullshit. Please, we can keep the temperature on the conversation down a bit by just keeping to facts and leaving out a few of these words.

MaulingMonkey 5y ago
> Did you look at the actual article? (Because it doesn't support your point). I did and it does for the point I intended to derive from said article: >> However, the GC pause times before and after the change were not significantly different. Furthermore, our pause times were on the order of single digit milliseconds, not the 100s of milliseconds improvement we saw at peak load. They were able to improve times via tuning. Individual GC pause times were still in the milliseconds. Totally acceptable for twitch's API servers (and in fact drowned out by the several hundred millisecond response times), but those numbers mean you'd want to avoid doing anything at all in a gamedev render thread that could potentially trigger a GC pause, because said GC pause will trigger a vsync miss. > I'd argue a tuning knob isn't so bad, compared to rewriting your entire application to manually malloc/free everything, which would likely result in oodles of bugs. Memory debuggers and RAII tools have ways to tackle this. I've also spent my fair share of time tackling oodles of bugs from object pooling, meant to workaround performance pitfalls in GCed languages, made worse by the fact that said languages treated manual memory allocation as a second class citizen at best, providing inadequate tooling for tackling the problem vs languages that treat it as a first class option.
- titzer 5y ago
  > but those numbers mean you'd want to avoid doing anything at all in a gamedev render thread that could potentially trigger a GC pause, because said GC pause will trigger a vsync miss. You might want to take a look at this: https://queue.acm.org/detail.cfm?id=2977741 https://queue.acm.org/detail.cfm?id=2977741
  - MaulingMonkey 5y ago
    I have, it's a decent read - although somewhat incoherent. E.g. they tout the benefits of GCing when idle, then trash the idea of controlling GC: > Sin two: explicit garbage-collection invocation. JavaScript does not have a Java-style System.gc() API, but some developers would like to have that. Their motivation is proactively to invoke garbage collection during a non-time-critical phase in order to avoid it later when timing is critical. [...] So, no explicitly GCing when a game knows it's idle. Gah. The worst part is these are entirely fine points... and somewhat coherent in the context of webapps and webpages. But then when one attempts to embed v8 - as one does - and suddenly you the developer are the one that might be attempting to time GCs correctly. At least then you have access to the appropriate native APIs: * https://v8docs.nodesource.com/node-7.10/d5/dda/classv8_1_1_isolate.html#ad6a2a02657f5425ad460060652a5a118 https://v8docs.nodesource.com/node-7.10/d5/dda/classv8_1_1_i... * https://v8docs.nodesource.com/node-7.10/d5/dda/classv8_1_1_isolate.html#a24647f61d6b41f69668094bdcd6ea91f https://v8docs.nodesource.com/node-7.10/d5/dda/classv8_1_1_i... A project I worked on had a few points where it had to explicitly call GC multiple times back to back. Intertwined references from C++ -> Squirrel[1] -> C++ -> Squirrel meant the first GC would finalize some C++ objects, which would unroot some Squirrel objects, which would allow some more C++ objects fo be finalized - but only one layer at a time per GC pass. Without the multiple explicit GC calls between unrooting one level and loading the next, the game had a tendency to "randomly"[2] ~double it's typical memory budget (thanks to uncollected dead objects and the corresponding textures they were keeping alive), crashing OOM in the process - the kind of thing that would fail console certification processes and ruin marketing plans. [1]: http://squirrel-lang.org/ http://squirrel-lang.org/ [2]: quite sensitive to the timing of "natural" allocation-triggered GCs, and what objects might've created what reference cyles etc.
    - 5y ago
MaulingMonkey 5y ago
> Please, we can keep the temperature on the conversation down a bit by just keeping to facts and leaving out a few of these words. Sure. Let's avoid some of these words too: > unsupported, tribalist, firmly-held belief that is unsupported by hard data. Asking for examples is fine and great, but painting broad strokes of the dissenting camp before they have a chance to respond does nothing to help keep things cool.
- deleted 5y ago
  [deleted]

by titzer 5y ago

MaulingMonkey 5y ago

> Did you look at the actual article? (Because it doesn't support your point). I did and it does for the point I intended to derive from said article: >> However, the GC pause times before and after the change were not significantly different. Furthermore, our pause times were on the order of single digit milliseconds, not the 100s of milliseconds improvement we saw at peak load. They were able to improve times via tuning. Individual GC pause times were still in the milliseconds. Totally acceptable for twitch's API servers (and in fact drowned out by the several hundred millisecond response times), but those numbers mean you'd want to avoid doing anything at all in a gamedev render thread that could potentially trigger a GC pause, because said GC pause will trigger a vsync miss. > I'd argue a tuning knob isn't so bad, compared to rewriting your entire application to manually malloc/free everything, which would likely result in oodles of bugs. Memory debuggers and RAII tools have ways to tackle this. I've also spent my fair share of time tackling oodles of bugs from object pooling, meant to workaround performance pitfalls in GCed languages, made worse by the fact that said languages treated manual memory allocation as a second class citizen at best, providing inadequate tooling for tackling the problem vs languages that treat it as a first class option.

titzer 5y ago
> but those numbers mean you'd want to avoid doing anything at all in a gamedev render thread that could potentially trigger a GC pause, because said GC pause will trigger a vsync miss. You might want to take a look at this: https://queue.acm.org/detail.cfm?id=2977741 https://queue.acm.org/detail.cfm?id=2977741
- MaulingMonkey 5y ago
  I have, it's a decent read - although somewhat incoherent. E.g. they tout the benefits of GCing when idle, then trash the idea of controlling GC: > Sin two: explicit garbage-collection invocation. JavaScript does not have a Java-style System.gc() API, but some developers would like to have that. Their motivation is proactively to invoke garbage collection during a non-time-critical phase in order to avoid it later when timing is critical. [...] So, no explicitly GCing when a game knows it's idle. Gah. The worst part is these are entirely fine points... and somewhat coherent in the context of webapps and webpages. But then when one attempts to embed v8 - as one does - and suddenly you the developer are the one that might be attempting to time GCs correctly. At least then you have access to the appropriate native APIs: * https://v8docs.nodesource.com/node-7.10/d5/dda/classv8_1_1_isolate.html#ad6a2a02657f5425ad460060652a5a118 https://v8docs.nodesource.com/node-7.10/d5/dda/classv8_1_1_i... * https://v8docs.nodesource.com/node-7.10/d5/dda/classv8_1_1_isolate.html#a24647f61d6b41f69668094bdcd6ea91f https://v8docs.nodesource.com/node-7.10/d5/dda/classv8_1_1_i... A project I worked on had a few points where it had to explicitly call GC multiple times back to back. Intertwined references from C++ -> Squirrel[1] -> C++ -> Squirrel meant the first GC would finalize some C++ objects, which would unroot some Squirrel objects, which would allow some more C++ objects fo be finalized - but only one layer at a time per GC pass. Without the multiple explicit GC calls between unrooting one level and loading the next, the game had a tendency to "randomly"[2] ~double it's typical memory budget (thanks to uncollected dead objects and the corresponding textures they were keeping alive), crashing OOM in the process - the kind of thing that would fail console certification processes and ruin marketing plans. [1]: http://squirrel-lang.org/ http://squirrel-lang.org/ [2]: quite sensitive to the timing of "natural" allocation-triggered GCs, and what objects might've created what reference cyles etc.
  - 5y ago

MaulingMonkey 5y ago

> Please, we can keep the temperature on the conversation down a bit by just keeping to facts and leaving out a few of these words. Sure. Let's avoid some of these words too: > unsupported, tribalist, firmly-held belief that is unsupported by hard data. Asking for examples is fine and great, but painting broad strokes of the dissenting camp before they have a chance to respond does nothing to help keep things cool.

deleted 5y ago
[deleted]