3 ms·

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.

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.

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.