5 ms·

https://nim-lang.org/docs/gc.html https://nim-lang.org/docs/gc.html > Tests show that a 2ms max pause time will be met in almost all cases on modern CPUs (with

https://nim-lang.org/docs/gc.html https://nim-lang.org/docs/gc.html > Tests show that a 2ms max pause time will be met in almost all cases on modern CPUs (with the cycle collector disabled). So in a reduced mode, pause times are only bounded by 2ms. Not sure how you could say that is zero pause

discoball 8y ago
Sorry, within 2ms not absolute 0, but to me it might as well be zero I've yet to notice it in practice.
- mkl 8y ago
  For a network driver, 2ms seems enormous. At 1Gbps that's 250 kilobytes, which is an awful lot of packets.
  - discoball 8y ago
    But GC doesn’t run continuously! Sure, device drivers and kernel modules should be built in C. Everything else is an approximation.
jononor 8y ago
Certainly not zero, but probably enough for hitting the frame deadline for 60fps graphics (16ms). Could even enough for real-time audio processing (at 4ms or 8ms). That will cover the vast majority of latency requirements that application developers using an OS deals with. Some embedded realtime cases might have more strict deadline requirements, or be complicated by the potential jitter that a GC might intoduce. Eg most discrete math used in motor control systems assumes a fixed sample period.
- chc 8y ago
  I haven't done game dev beyond hobbyist level, but 12.5% of your total budget for a frame seems pretty significant. Is that kind of percentage hit generally considered negligible?
  - Kaveren 8y ago
    60 FPS is not enough, many people have monitors with much higher refresh rates (120 hz, more). You have virtual reality which basically requires a higher refresh rate than 60 FPS to begin with. Using a runtime component for garbage collection is highly sub-optimal. Rust is possibly an ideal language for game development. Standard Rust has no runtime component, which is perfect. It's also a high-performance language. The ecosystem for Rust game development is immature, but there's progress being made.
    - majewsky 8y ago
      Standard Rust absolutely has runtime components. Otherwise a "Hello World" would not compile into several 100 KiB of binary. (Not saying that that's bad, just that this is how it is.)
      - bluejekyll 8y ago
        I haven't looked since, but jemalloc I believe was a significant cost in this. Recently there was a change merged in to use the system allocator by default: https://www.reddit.com/r/rust/comments/9twam5/jemalloc_was_just_removed_from_the_standard/ https://www.reddit.com/r/rust/comments/9twam5/jemalloc_was_j...
      - red75prime 8y ago
        It has runtime as in "C runtime", that is the code which runs before and after `main` and the code of standard library. It doesn't have runtime as in "Java runtime" (or "C# runtime") that includes the code that runs alongside your code (garbage collection thread).
        Kaveren 8y ago
        Yes, I was loose in my use of the term "runtime" and sacrificing correctness. Writing "runtime component" rather than "runtime" makes it more misleading. I probably should've worded my original comment more wisely.
monocasa 8y ago
The GC guys love doing that for some reason. Azul's "pauseless" GC only guaranteed 10ms pause times.

discoball 8y ago

Sorry, within 2ms not absolute 0, but to me it might as well be zero I've yet to notice it in practice.

mkl 8y ago
For a network driver, 2ms seems enormous. At 1Gbps that's 250 kilobytes, which is an awful lot of packets.
- discoball 8y ago
  But GC doesn’t run continuously! Sure, device drivers and kernel modules should be built in C. Everything else is an approximation.

jononor 8y ago

Certainly not zero, but probably enough for hitting the frame deadline for 60fps graphics (16ms). Could even enough for real-time audio processing (at 4ms or 8ms). That will cover the vast majority of latency requirements that application developers using an OS deals with. Some embedded realtime cases might have more strict deadline requirements, or be complicated by the potential jitter that a GC might intoduce. Eg most discrete math used in motor control systems assumes a fixed sample period.

chc 8y ago
I haven't done game dev beyond hobbyist level, but 12.5% of your total budget for a frame seems pretty significant. Is that kind of percentage hit generally considered negligible?
- Kaveren 8y ago
  60 FPS is not enough, many people have monitors with much higher refresh rates (120 hz, more). You have virtual reality which basically requires a higher refresh rate than 60 FPS to begin with. Using a runtime component for garbage collection is highly sub-optimal. Rust is possibly an ideal language for game development. Standard Rust has no runtime component, which is perfect. It's also a high-performance language. The ecosystem for Rust game development is immature, but there's progress being made.
  - majewsky 8y ago
    Standard Rust absolutely has runtime components. Otherwise a "Hello World" would not compile into several 100 KiB of binary. (Not saying that that's bad, just that this is how it is.)
    - bluejekyll 8y ago
      I haven't looked since, but jemalloc I believe was a significant cost in this. Recently there was a change merged in to use the system allocator by default: https://www.reddit.com/r/rust/comments/9twam5/jemalloc_was_just_removed_from_the_standard/ https://www.reddit.com/r/rust/comments/9twam5/jemalloc_was_j...
    - red75prime 8y ago
      It has runtime as in "C runtime", that is the code which runs before and after `main` and the code of standard library. It doesn't have runtime as in "Java runtime" (or "C# runtime") that includes the code that runs alongside your code (garbage collection thread).
      - Kaveren 8y ago
        Yes, I was loose in my use of the term "runtime" and sacrificing correctness. Writing "runtime component" rather than "runtime" makes it more misleading. I probably should've worded my original comment more wisely.

monocasa 8y ago

The GC guys love doing that for some reason. Azul's "pauseless" GC only guaranteed 10ms pause times.