4 ms·

Isn’t garbage collection going to introduce jitter?

pjmlp 8y ago
Not necessarily, there are several OSes written in GC enabled systems programming languages. Just because a language has a GC it doesn't mean it is the only means to allocate memory. Go also allows for global statics, stack and plain old C style manual allocations. It is a matter to learn how to use them. And make use of profilers as well. For example, on performance critical paths always use a standard for loop, never a for range one.
- kazen44 8y ago
  > For example, on performance critical paths always use a standard for loop, never a for range one. i am curious, why would one use a normal for loop, instead of a range one?
  - pjmlp 8y ago
    A range one might introduce boxing depending on the types being iterated.
    - GenericsMotors 8y ago
      Or use a language with reified generics :)
      - dullgiulio 8y ago
        Go maps are reified generics, and very efficient ones at that.
        candiodari 8y ago
        What you mean is it's a set of C macros, except built-in to the compiler. Great if it's exactly what you need. And you're prepared for severe WTF moments (e.g. equality on map values is ... not the same as equality on variables of the same type containing the same thing). Also, expect the whole thing to be useless if you need slight complexity (e.g. you can use strings as keys, but not bytes (either Bytes, or []byte, but you can use [5]byte for example). Oh ... you actually need it to be a red-black tree, or a custom hash function ? Tough.
- TickleSteve 8y ago
  GC will always introduce jitter. You can choose not to use it and allocate statically etc, but that does not mean that use of a GC does not introduce jitter. Also don't confuse high performance with latency-sensitive. Highly performance-optimised code will still have issues with GC jitter if you or someone else is causing it. There is a reason why the GC-enabled OSs aren't used for anything in reality. BTW: There should be no difference between for and for-range loops given an optimiser thats working.
  - pjmlp 8y ago
    > GC will always introduce jitter. > You can choose not to use it and allocate statically etc, but that does not mean that use of a GC does not introduce jitter. It only introduces jitter if it runs at all. If one really wants to be drastic in performance critical code, in most GC runtimes it is possible to just turn it off. On Go's case a runtime.SetGCPercent(-1) will take care of that. > There is a reason why the GC-enabled OSs aren't used for anything in reality. And me thinking I had two running on my phones, go figure.
    - dullgiulio 8y ago
      And the default is 100, which means a double in newly allocated memory space. I have written several servers that after starting up (and running uselessly the GC once), never need to run it again.
    - TickleSteve 8y ago
      Care to say which GC-enabled OS you have on your phone? I'm not talking about GC-enabled runtimes such as a JVM or ObjC/Swift runtime, they're application-level. Both Mach(IOS) and Linux(Android) are non-GC-enabled OSs.
  - tonyg 8y ago
    > GC will always introduce jitter. Hard real-time garbage collectors (including real-time reference counting approaches) can be used in such a way as to eliminate memory-management jitter. Region allocation - a form of GC - can be used in such a way as to avoid memory-management jitter. > GC-enabled OSs aren't used for anything in reality. You might have a narrow definition of what you consider to be an OS. I would argue that things like the JVM, the Erlang BEAM, and even the browser are OS-like enough to qualify.
tonyg 8y ago
Not in general, though of course lots of production language runtimes do involve a certain amount of GC-related jitter. But even where such jitter is introduced, it might not be a very big deal for something like TCP/IP.

Not necessarily, there are several OSes written in GC enabled systems programming languages. Just because a language has a GC it doesn't mean it is the only means to allocate memory. Go also allows for global statics, stack and plain old C style manual allocations. It is a matter to learn how to use them. And make use of profilers as well. For example, on performance critical paths always use a standard for loop, never a for range one.

kazen44 8y ago
> For example, on performance critical paths always use a standard for loop, never a for range one. i am curious, why would one use a normal for loop, instead of a range one?
- pjmlp 8y ago
  A range one might introduce boxing depending on the types being iterated.
  - GenericsMotors 8y ago
    Or use a language with reified generics :)
    - dullgiulio 8y ago
      Go maps are reified generics, and very efficient ones at that.
      - candiodari 8y ago
        What you mean is it's a set of C macros, except built-in to the compiler. Great if it's exactly what you need. And you're prepared for severe WTF moments (e.g. equality on map values is ... not the same as equality on variables of the same type containing the same thing). Also, expect the whole thing to be useless if you need slight complexity (e.g. you can use strings as keys, but not bytes (either Bytes, or []byte, but you can use [5]byte for example). Oh ... you actually need it to be a red-black tree, or a custom hash function ? Tough.
TickleSteve 8y ago
GC will always introduce jitter. You can choose not to use it and allocate statically etc, but that does not mean that use of a GC does not introduce jitter. Also don't confuse high performance with latency-sensitive. Highly performance-optimised code will still have issues with GC jitter if you or someone else is causing it. There is a reason why the GC-enabled OSs aren't used for anything in reality. BTW: There should be no difference between for and for-range loops given an optimiser thats working.
- pjmlp 8y ago
  > GC will always introduce jitter. > You can choose not to use it and allocate statically etc, but that does not mean that use of a GC does not introduce jitter. It only introduces jitter if it runs at all. If one really wants to be drastic in performance critical code, in most GC runtimes it is possible to just turn it off. On Go's case a runtime.SetGCPercent(-1) will take care of that. > There is a reason why the GC-enabled OSs aren't used for anything in reality. And me thinking I had two running on my phones, go figure.
  - dullgiulio 8y ago
    And the default is 100, which means a double in newly allocated memory space. I have written several servers that after starting up (and running uselessly the GC once), never need to run it again.
  - TickleSteve 8y ago
    Care to say which GC-enabled OS you have on your phone? I'm not talking about GC-enabled runtimes such as a JVM or ObjC/Swift runtime, they're application-level. Both Mach(IOS) and Linux(Android) are non-GC-enabled OSs.
- tonyg 8y ago
  > GC will always introduce jitter. Hard real-time garbage collectors (including real-time reference counting approaches) can be used in such a way as to eliminate memory-management jitter. Region allocation - a form of GC - can be used in such a way as to avoid memory-management jitter. > GC-enabled OSs aren't used for anything in reality. You might have a narrow definition of what you consider to be an OS. I would argue that things like the JVM, the Erlang BEAM, and even the browser are OS-like enough to qualify.

tonyg 8y ago

Not in general, though of course lots of production language runtimes do involve a certain amount of GC-related jitter. But even where such jitter is introduced, it might not be a very big deal for something like TCP/IP.