4 ms·

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.

by pron 8y ago

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
        There is always a tradeoff in throughput (and a commercial low-latency GC has been available for Java for years, as well as realtime GCs). All I'm saying is that the reason Go is able to achieve low latency with a relatively simple design is because the language is designed to generate less garbage, so the challenge is smaller. My point is that Go's GC is not some extraordinary breakthrough in GC design (not that Hudson hadn't made some in the past) that unlocks the secret to low-pause GCs, but more of an indirect exploitation of the fact that the allocation rate is relatively low. The same design with much higher allocation rates would likely suffer an unacceptable hit to throughput. A recent presentation on ZGC is here: https://www.youtube.com/watch?v=tShc0dyFtgw https://www.youtube.com/watch?v=tShc0dyFtgw
        ngrilly 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.

by 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
        There is always a tradeoff in throughput (and a commercial low-latency GC has been available for Java for years, as well as realtime GCs). All I'm saying is that the reason Go is able to achieve low latency with a relatively simple design is because the language is designed to generate less garbage, so the challenge is smaller. My point is that Go's GC is not some extraordinary breakthrough in GC design (not that Hudson hadn't made some in the past) that unlocks the secret to low-pause GCs, but more of an indirect exploitation of the fact that the allocation rate is relatively low. The same design with much higher allocation rates would likely suffer an unacceptable hit to throughput. A recent presentation on ZGC is here: https://www.youtube.com/watch?v=tShc0dyFtgw https://www.youtube.com/watch?v=tShc0dyFtgw
        ngrilly 8y ago