4 ms·

But look at 95% and 99% latency numbers - Rust is on top. And surprisingly (to me) Go totally tanks in 99% latency.

by mark-probst 5y ago

lawn 5y ago
Why is it surprising that Go tanks in 99% latency? That's what I would've expected.
- kaoD 5y ago
  Because Golang was touted as a systems programming language (a better C).
  - The_rationalist 5y ago
    Go is generally slower than Java and C#, many languages pretend C performance but this is just false advertising
- jhgb 5y ago
  You would? I wouldn't. It definitely looks like somewhat pathological case to me, at least in 2021. Maybe five years earlier the number would be appropriate, but there seems to be something wrong with Go slowing down this much at that small a heap. I'm wondering if it was tuned at all.
andrewaylett 5y ago
It's not that surprising -- Go is designed for speed by simplicity, and a low-pause-latency GC is anything but simple.
- jhgb 5y ago
  In 2021, Go is supposed to have GC pauses on the order of several ms at worst. Not 40 ms. So it kind of is surprising, something seems to be broken there. I'm wondering whether this isn't a limitation caused by forcing a single core operation, the runtime might not be designed for that. EDIT: Someone else noted (https://news.ycombinator.com/item?id=27085507 https://news.ycombinator.com/item?id=27085507) a discussion on Reddit where a <5ms latency was achieved in 99.9% cases, so perhaps this is indeed a subpar result.
  - dilyevsky 5y ago
    When you allocate against a running GC it will penalize you for this (literally sleep your thread) - hence garbage tail latency. The solution is to not do allocation which is what gogo library strives for
    - kaba0 5y ago
      Most of the phases of GC can be done parallel, so allocation should stop only for a really small amount of time. For comparison, Java's low-latency GC (which optimize for latency but may reduce throughput), ZGC can do worst-case <1ms pause times, that is the OS scheduler will cost more than GC.
      - dilyevsky 5y ago
        I’m talking about Go garbage collector specifically which does mark and sweep and will slow down functions doing frequent allocations on purpose in order to catch up. This is different from stw kind of scenario e.g shenandoah
iamgopal 5y ago
I was about to say because of GC, but doesn’t java also GC ?
- josefx 5y ago
  Java also has a JIT compiler which might eliminate object allocations at runtime.
  - vips7L 5y ago
    It also has better GCs
ainar-g 5y ago
Iirc, the official protobuf module for Go still uses reflection in the generated code as opposed to fully generating the encoding and decoding code, so maybe that creates additional garbage or performance issues or lock contention. I think I remember there being an alternative module that fully generates the code, and it would be interesting to see that in the table as well.

But look at 95% and 99% latency numbers - Rust is on top. And surprisingly (to me) Go totally tanks in 99% latency.

lawn 5y ago

Why is it surprising that Go tanks in 99% latency? That's what I would've expected.

kaoD 5y ago
Because Golang was touted as a systems programming language (a better C).
- The_rationalist 5y ago
  Go is generally slower than Java and C#, many languages pretend C performance but this is just false advertising
jhgb 5y ago
You would? I wouldn't. It definitely looks like somewhat pathological case to me, at least in 2021. Maybe five years earlier the number would be appropriate, but there seems to be something wrong with Go slowing down this much at that small a heap. I'm wondering if it was tuned at all.

andrewaylett 5y ago

It's not that surprising -- Go is designed for speed by simplicity, and a low-pause-latency GC is anything but simple.

jhgb 5y ago
In 2021, Go is supposed to have GC pauses on the order of several ms at worst. Not 40 ms. So it kind of is surprising, something seems to be broken there. I'm wondering whether this isn't a limitation caused by forcing a single core operation, the runtime might not be designed for that. EDIT: Someone else noted (https://news.ycombinator.com/item?id=27085507 https://news.ycombinator.com/item?id=27085507) a discussion on Reddit where a <5ms latency was achieved in 99.9% cases, so perhaps this is indeed a subpar result.
- dilyevsky 5y ago
  When you allocate against a running GC it will penalize you for this (literally sleep your thread) - hence garbage tail latency. The solution is to not do allocation which is what gogo library strives for
  - kaba0 5y ago
    Most of the phases of GC can be done parallel, so allocation should stop only for a really small amount of time. For comparison, Java's low-latency GC (which optimize for latency but may reduce throughput), ZGC can do worst-case <1ms pause times, that is the OS scheduler will cost more than GC.
    - dilyevsky 5y ago
      I’m talking about Go garbage collector specifically which does mark and sweep and will slow down functions doing frequent allocations on purpose in order to catch up. This is different from stw kind of scenario e.g shenandoah

iamgopal 5y ago

I was about to say because of GC, but doesn’t java also GC ?

josefx 5y ago
Java also has a JIT compiler which might eliminate object allocations at runtime.
- vips7L 5y ago
  It also has better GCs

ainar-g 5y ago

Iirc, the official protobuf module for Go still uses reflection in the generated code as opposed to fully generating the encoding and decoding code, so maybe that creates additional garbage or performance issues or lock contention. I think I remember there being an alternative module that fully generates the code, and it would be interesting to see that in the table as well.