5 ms·

> This is not due to GC design but to language semantics (value types, which aren't yet available in Java). The fact that Go has value types helps a lot, but t

> This is not due to GC design but to language semantics (value types, which aren't yet available in Java). The fact that Go has value types helps a lot, but the latency inferior to 0.5 ms is mainly the result of GC design, as explained in the discussed article (especially the work on removing as much as possible stop the world pauses). > Note that at some point, worst-case latency becomes far less meaningful than throughput, because unless running on a realtime OS, the OS introduces bigger pauses, and it makes no sense for the GC to try and beat them. This is already said in the article.

pron 8y ago
Because you usually pay for latency with throughput, you can afford the low latency achieved with a simpler design only if you have less concurrent work.
- masklinn 8y ago
  Go is not magic, and does in fact pay for latency with throughput: https://www.reddit.com/r/golang/comments/5j7phw/modern_garbage_collection/dbe958e/ https://www.reddit.com/r/golang/comments/5j7phw/modern_garba... > Go: 67 ms max, 1062 pauses, 23.6 s total pause, 22 ms mean pause, 91 s total runtime > Java, G1 GC, no tuning: 86 ms max, 65 pauses, 2.7 s total pause, 41 ms mean pause, 20 s total runtime
  - nvarsj 8y ago
    I couldn't find the benchmarks for that comment. But the Java numbers seem way off. It must have been a simple toy application, probably with allocations optimized away somewhere - I'd want to see memory allocation rates to see if they are comparable. G1 is usually higher latency than CMS in my experience, too. Try running Cassandra with G1, and see how good your pauses are. Min viable pause time target for G1 is ~200ms (the hotspot default).
  - BuckRogers 8y ago
    I don't really understand the argument that Go is "almost" soft-realtime.. if you need that, you probably need or should just go to realtime. Use say, Rust or C++. Otherwise it seems to me that the Java/C# model is the best design for most tasks. Which is why they're so popular, it's not a mistake.
    - ngrilly 8y ago
      > Otherwise it seems to me that the Java/C# model is the best design for most tasks. This is discussed in the article (basically, Google needed low latency servers): « If you want 10 answers ask for several more and take the first 10 and those are the answers you put on your search page. If the request exceeds 50%ile reissue or forward the request to another server. If GC is about to run, refuse new requests or forward the requests to another server until GC is done. And so forth and so on. All these are workarounds come from very clever people with very real problems but they didn't tackle the root problem of GC latency. At Google scale we had to tackle the root problem. Why? Redundancy wasn't going to scale, redundancy costs a lot. It costs new server farms. »
      - pron 8y ago
        > but they didn't tackle the root problem of GC latency But they did. The new low-latency Java GCs are more sophisticated than Go's, and deliver pauses that are on the order of OS-caused pauses. The reason Go was able to achieve low latency with a relatively simple design is because 1. it suffers a hit to throughput and 2. that throughput hit, while significant, is not catastrophic because Go relies heavily on value types.
        ngrilly 8y ago
        > The new low-latency Java GCs As you wrote, they are new, and weren't available when the decision was made for the Go GC. > The reason Go was able to achieve low latency with a relatively simple design is because 1. it suffers a hit to throughput and 2. that throughput hit, while significant, is not catastrophic because Go relies heavily on value types. And are you saying these "new low-latency Java GCs" have no tradeoffs either? I'm sorry, but we are discussing the keynote of the International Symposium on Memory Management, which is a recognized event in the field, and you are claiming things without any substantial material to offer. Maybe you're right, but I need more than vague assertions to be convinced :-)

pron 8y ago

Because you usually pay for latency with throughput, you can afford the low latency achieved with a simpler design only if you have less concurrent work.

masklinn 8y ago
Go is not magic, and does in fact pay for latency with throughput: https://www.reddit.com/r/golang/comments/5j7phw/modern_garbage_collection/dbe958e/ https://www.reddit.com/r/golang/comments/5j7phw/modern_garba... > Go: 67 ms max, 1062 pauses, 23.6 s total pause, 22 ms mean pause, 91 s total runtime > Java, G1 GC, no tuning: 86 ms max, 65 pauses, 2.7 s total pause, 41 ms mean pause, 20 s total runtime
- nvarsj 8y ago
  I couldn't find the benchmarks for that comment. But the Java numbers seem way off. It must have been a simple toy application, probably with allocations optimized away somewhere - I'd want to see memory allocation rates to see if they are comparable. G1 is usually higher latency than CMS in my experience, too. Try running Cassandra with G1, and see how good your pauses are. Min viable pause time target for G1 is ~200ms (the hotspot default).
- BuckRogers 8y ago
  I don't really understand the argument that Go is "almost" soft-realtime.. if you need that, you probably need or should just go to realtime. Use say, Rust or C++. Otherwise it seems to me that the Java/C# model is the best design for most tasks. Which is why they're so popular, it's not a mistake.
  - ngrilly 8y ago
    > Otherwise it seems to me that the Java/C# model is the best design for most tasks. This is discussed in the article (basically, Google needed low latency servers): « If you want 10 answers ask for several more and take the first 10 and those are the answers you put on your search page. If the request exceeds 50%ile reissue or forward the request to another server. If GC is about to run, refuse new requests or forward the requests to another server until GC is done. And so forth and so on. All these are workarounds come from very clever people with very real problems but they didn't tackle the root problem of GC latency. At Google scale we had to tackle the root problem. Why? Redundancy wasn't going to scale, redundancy costs a lot. It costs new server farms. »
    - pron 8y ago
      > but they didn't tackle the root problem of GC latency But they did. The new low-latency Java GCs are more sophisticated than Go's, and deliver pauses that are on the order of OS-caused pauses. The reason Go was able to achieve low latency with a relatively simple design is because 1. it suffers a hit to throughput and 2. that throughput hit, while significant, is not catastrophic because Go relies heavily on value types.
      - ngrilly 8y ago
        > The new low-latency Java GCs As you wrote, they are new, and weren't available when the decision was made for the Go GC. > The reason Go was able to achieve low latency with a relatively simple design is because 1. it suffers a hit to throughput and 2. that throughput hit, while significant, is not catastrophic because Go relies heavily on value types. And are you saying these "new low-latency Java GCs" have no tradeoffs either? I'm sorry, but we are discussing the keynote of the International Symposium on Memory Management, which is a recognized event in the field, and you are claiming things without any substantial material to offer. Maybe you're right, but I need more than vague assertions to be convinced :-)