4 ms·

To play devil's advocate...and because I'm just not that educated in the space, is this really a huge deal? If we're talking couple ms at a time delays, isn't

To play devil's advocate...and because I'm just not that educated in the space, is this really a huge deal? If we're talking couple ms at a time delays, isn't that still vastly superior to what a human could achieve?

gameswithgo 5y ago
GC pauses can be hundreds of milliseconds. You could perhaps use a particular GC scheme that guarantees you never have more than a couple millisecond pause, but then you have lots of pauses. That might have unintended consequences as well. I'm also not sure that such GCs, like golangs, can really mathematically guarantee a minimum pause time.
- quotemstr 5y ago
  Hard real time garbage collectors have existed for decades. Of course you can mathematically guarantee a minimum pause time given a cap on allocation rate. What's stopping you?
  - xxs 5y ago
    You don't even need a cap on allocation rate, GC can have during allocation w/o fully blocking, it'd 'gracefully' degrade the allocation, itself. It'd be limited by CPU/memory latency and throughput.
- xxs 5y ago
  Fully concurrent GCs exist with read-barriers and no stop-the-world phase. The issues with "hard" real-time are not gc-related.
AlotOfReading 5y ago
If you can set a guaranteed maximum on the delays (regardless of what those limits are), you're hard real-time by definition. The horror is that they weren't building a system that could support those guarantees.
- silisili 5y ago
  I see, thanks. What if say, a system is written against an indeterminate timed GC like say, Azul or Go's, but code is written in a way that proves GC times never exceed X, whether by theory or stress testing. Is this still seen as 'unguaranteed'?
  - AlotOfReading 5y ago
    It depends on your system model (e.g. do you consider memory corruption to be a valid threat), but it could be. In practice, actually establishing that proof purely in code is almost always impractical or doesn't address the full problem space. You use hardware to help out and limit the amount of code you actually have to validate.
  - kaba0 5y ago
    I think that would at most be soft-real time.
sam0x17 5y ago
If ernie the intern decides to use a hashmap to store a class of interesting objects as we drive, you could end up with seconds of GC collection + resizing if it grows big enough.

gameswithgo 5y ago

GC pauses can be hundreds of milliseconds. You could perhaps use a particular GC scheme that guarantees you never have more than a couple millisecond pause, but then you have lots of pauses. That might have unintended consequences as well. I'm also not sure that such GCs, like golangs, can really mathematically guarantee a minimum pause time.

quotemstr 5y ago
Hard real time garbage collectors have existed for decades. Of course you can mathematically guarantee a minimum pause time given a cap on allocation rate. What's stopping you?
- xxs 5y ago
  You don't even need a cap on allocation rate, GC can have during allocation w/o fully blocking, it'd 'gracefully' degrade the allocation, itself. It'd be limited by CPU/memory latency and throughput.
xxs 5y ago
Fully concurrent GCs exist with read-barriers and no stop-the-world phase. The issues with "hard" real-time are not gc-related.

AlotOfReading 5y ago

If you can set a guaranteed maximum on the delays (regardless of what those limits are), you're hard real-time by definition. The horror is that they weren't building a system that could support those guarantees.

silisili 5y ago
I see, thanks. What if say, a system is written against an indeterminate timed GC like say, Azul or Go's, but code is written in a way that proves GC times never exceed X, whether by theory or stress testing. Is this still seen as 'unguaranteed'?
- AlotOfReading 5y ago
  It depends on your system model (e.g. do you consider memory corruption to be a valid threat), but it could be. In practice, actually establishing that proof purely in code is almost always impractical or doesn't address the full problem space. You use hardware to help out and limit the amount of code you actually have to validate.
- kaba0 5y ago
  I think that would at most be soft-real time.

sam0x17 5y ago

If ernie the intern decides to use a hashmap to store a class of interesting objects as we drive, you could end up with seconds of GC collection + resizing if it grows big enough.