4 ms·

This test also doesn't take into account if this was a long runing process continually churning whats the effect on GC/RC pauses etc.

_ph_ 6y ago
The nice thing about the Go GC is, it runs completely in parallel to your program, so that there are no significant GC pauses any more (typically far below the millisecond range, rather microseconds).
- easytiger 6y ago
  I'm aware, but alas in my domain anything above 50us is "noticeable" if it happens regularly
  - analognoise 6y ago
    HFT?
    - easytiger 6y ago
      Something like that yes
  - _ph_ 6y ago
    It might be a noticeable delay if you require quick response by the program, but won't have a significant impact on the total run time of the program.
    - easytiger 6y ago
      It depends on your requirements. Some domains might state a worst case for a single transaction or percentage of transactions that definitely exceeds what can be achieved here
      - jonathanstrange 6y ago
        Ada with the Ravenscar profile enabled is a good choice for such scenarios. Together with a real-time operating system it allows you to satisfy hard real-time guarantees. As you certainly know, though, hard real-time constraints require hardware validation.
        easytiger 6y ago
        Yea, for a lot of requirements hard realtime isn't necessary and at least some older linux systems can be tuned to remove almost all jitter giving very good 99.9th percentile figures. I've even seen it done with zero alloc java
- Groxx 6y ago
  Broadly, yes, Go's GC is quite fast and unobtrusive. They've done a good job tuning it for many purposes. On the post's programs though it's quite possible it doesn't come into play at all, as the compiler keeps things on the stack when possible. But like all GCs, there are cases where it has issues. Anecdotally, I've seen multiple cases where "ballast"[1] reduced RPC response times by around 25%. A bit of GC tuning on some tests sped them up by over 10x (due to pathological thrashing - each test would go from just-below the GC threshold to just-over). Etc. Granted, it's usually on not-great code, but the point still stands - if you care about performance, GC cannot be ignored, regardless of how good its marketing is. [1] https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i-learnt-to-stop-worrying-and-love-the-heap-26c2462549a2/ https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i...

_ph_ 6y ago

The nice thing about the Go GC is, it runs completely in parallel to your program, so that there are no significant GC pauses any more (typically far below the millisecond range, rather microseconds).

easytiger 6y ago
I'm aware, but alas in my domain anything above 50us is "noticeable" if it happens regularly
- analognoise 6y ago
  HFT?
  - easytiger 6y ago
    Something like that yes
- _ph_ 6y ago
  It might be a noticeable delay if you require quick response by the program, but won't have a significant impact on the total run time of the program.
  - easytiger 6y ago
    It depends on your requirements. Some domains might state a worst case for a single transaction or percentage of transactions that definitely exceeds what can be achieved here
    - jonathanstrange 6y ago
      Ada with the Ravenscar profile enabled is a good choice for such scenarios. Together with a real-time operating system it allows you to satisfy hard real-time guarantees. As you certainly know, though, hard real-time constraints require hardware validation.
      - easytiger 6y ago
        Yea, for a lot of requirements hard realtime isn't necessary and at least some older linux systems can be tuned to remove almost all jitter giving very good 99.9th percentile figures. I've even seen it done with zero alloc java
Groxx 6y ago
Broadly, yes, Go's GC is quite fast and unobtrusive. They've done a good job tuning it for many purposes. On the post's programs though it's quite possible it doesn't come into play at all, as the compiler keeps things on the stack when possible. But like all GCs, there are cases where it has issues. Anecdotally, I've seen multiple cases where "ballast"[1] reduced RPC response times by around 25%. A bit of GC tuning on some tests sped them up by over 10x (due to pathological thrashing - each test would go from just-below the GC threshold to just-over). Etc. Granted, it's usually on not-great code, but the point still stands - if you care about performance, GC cannot be ignored, regardless of how good its marketing is. [1] https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i-learnt-to-stop-worrying-and-love-the-heap-26c2462549a2/ https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i...