3 ms·

It's not really suitable for latency-critical applications. EDIT: Fixed unfortunate typo

somethingwitty1 5y ago
was the double-negative intentional? I've used Go for sub-millisecond needs. So 20ms seems like it would be a reasonable choice from where I'm sitting.
- mcronce 5y ago
  It was not intentional, thanks for asking...very unfortunate typo ;) Go doesn't give you control over inline vs indirect allocation, instead relying on escape analysis, which is notoriously finicky. Seemingly unrelated changes, along with compiler upgrades, can ruin your carefully optimized code. This is especially heinous because it uses a GC; unnecessary allocations have a disproportionately large impact on your application performance. One or the other wouldn't be nearly as bad. Time and time again we see reports from organizations/projects with perfectly fine average latency, but horrendous p95+ times, when written in Go - some going as far as to do straight-up insane optimizations (see Dragph) or rewrite in other languages.
  - ctvo 5y ago
    But you think this impacts a 20ms budget? It’s mostly trivia to get sub 20ms p99 in Go.
  - Thaxll 5y ago
    I don't know, I'm able to get 150k grpc q/sec with p99 sub 1ms. It's def better than G1 and CMS.
  - pjmlp 5y ago
    While escape analysis in Go is finky, you can make it part of the CI/CD to keep it under control. https://medium.com/a-journey-with-go/go-introduction-to-the-escape-analysis-f7610174e890 https://medium.com/a-journey-with-go/go-introduction-to-the-... No different than running other kinds of static analysis for well known languages, unsafe by default.
fcantournet 5y ago
You can 100% write services with P999 < 20ms in go. Not even trying that hard. Go is entirely suitable for this kind of constraints, I dare say that's go's main target. P99 < 1ms, that's when you're going to want to switch it up.
- sagichmal 5y ago
  Depending on workload, Go also does sub-1ms p99 pretty easily. I'm getting sub-1ms p99.9.
  - torbital 5y ago
    What are the proposed solutions to get better than that? C/Rust code? Assembly?
    - 35fbe7d3d5b9 5y ago
      Going fast is one thing. Making a program that responds consistently is different, and there's a continuum of choices. The last time I read about Go's GC they targeted 500us and for tons of applications that's more than sufficient; for some, it's not. You could start with twiddling some of the GC knobs Go gives you, but you're still working against an SLO. If you need stronger guarantees you'll look at languages that completely eschew GC, because Go's GC still has STW bits. Climb the ladder further and you're reducing allocations, eventually avoiding any malloc() beyond what it takes to get an arena and doing your own bookkeeping. I've never been near the top of the ladder when you have hard real-time constraints, but I've heard it involves paying Wind River for VxWorks licenses ;)

was the double-negative intentional? I've used Go for sub-millisecond needs. So 20ms seems like it would be a reasonable choice from where I'm sitting.

mcronce 5y ago
It was not intentional, thanks for asking...very unfortunate typo ;) Go doesn't give you control over inline vs indirect allocation, instead relying on escape analysis, which is notoriously finicky. Seemingly unrelated changes, along with compiler upgrades, can ruin your carefully optimized code. This is especially heinous because it uses a GC; unnecessary allocations have a disproportionately large impact on your application performance. One or the other wouldn't be nearly as bad. Time and time again we see reports from organizations/projects with perfectly fine average latency, but horrendous p95+ times, when written in Go - some going as far as to do straight-up insane optimizations (see Dragph) or rewrite in other languages.
- ctvo 5y ago
  But you think this impacts a 20ms budget? It’s mostly trivia to get sub 20ms p99 in Go.
- Thaxll 5y ago
  I don't know, I'm able to get 150k grpc q/sec with p99 sub 1ms. It's def better than G1 and CMS.
- pjmlp 5y ago
  While escape analysis in Go is finky, you can make it part of the CI/CD to keep it under control. https://medium.com/a-journey-with-go/go-introduction-to-the-escape-analysis-f7610174e890 https://medium.com/a-journey-with-go/go-introduction-to-the-... No different than running other kinds of static analysis for well known languages, unsafe by default.

fcantournet 5y ago

You can 100% write services with P999 < 20ms in go. Not even trying that hard. Go is entirely suitable for this kind of constraints, I dare say that's go's main target. P99 < 1ms, that's when you're going to want to switch it up.

sagichmal 5y ago
Depending on workload, Go also does sub-1ms p99 pretty easily. I'm getting sub-1ms p99.9.
- torbital 5y ago
  What are the proposed solutions to get better than that? C/Rust code? Assembly?
  - 35fbe7d3d5b9 5y ago
    Going fast is one thing. Making a program that responds consistently is different, and there's a continuum of choices. The last time I read about Go's GC they targeted 500us and for tons of applications that's more than sufficient; for some, it's not. You could start with twiddling some of the GC knobs Go gives you, but you're still working against an SLO. If you need stronger guarantees you'll look at languages that completely eschew GC, because Go's GC still has STW bits. Climb the ladder further and you're reducing allocations, eventually avoiding any malloc() beyond what it takes to get an arena and doing your own bookkeeping. I've never been near the top of the ladder when you have hard real-time constraints, but I've heard it involves paying Wind River for VxWorks licenses ;)