4 ms·

jcipar managed to get the max pause down to 22ms by tweaking parameters: https://www.reddit.com/r/programming/comments/5fyhjb/golangs_realtime_gc_in_theory_and_

jcipar managed to get the max pause down to 22ms by tweaking parameters: https://www.reddit.com/r/programming/comments/5fyhjb/golangs_realtime_gc_in_theory_and_practice_pusher/daof47v/ https://www.reddit.com/r/programming/comments/5fyhjb/golangs... He also mentioned that the JVM GC does a lot of online tuning, so the max pause times may drop over a longer run of the program. This is similar to the Racket GC, where the maximum pauses are >100ms at the start of the run, but converge to around 20ms as the program continues to run. It would be nice to run the benchmarks for a longer period of time, and only measure max pause times once this "ramp up" period is over.

ch4s3 10y ago
Yeah it takes a few thousand calls for the JVM to "warm up". It's surprisingly noticeable on speed and latency, but I'm less knowledgeable about the GC.
- willsewell 10y ago
  I think we need to modify the benchmark to give enough time for the RTS to "warmup" before timing max pause times. This will provide a fairer comparison, since the end goal is to evaluate languages for web servers with large heaps and low latency requirements.
  - dilap 10y ago
    I mean having a short period of time with long latency still sucks though too, right? That's real customers getting real low-quality service. Then maybe you're left doing complex things like running the server with fake traffic as a warming up period to get it to be fast enough. Sure, it'll work, but it's a lot of extra hassle.
    - ch4s3 10y ago
      You'd probably use load balancing to send some traffic to new images while they warm up. At lower volumes, you shouldn't be hitting GC pauses mid request. Then after a certain point you point everything to the new version. This is good for QA too.
      - deleted 10y ago
        [deleted]
      - dilap 10y ago
        depending on what you're doing, maybe you consider this complexity no big deal. but i don't think, for eaxmple, a standard setup using aws elb and autoscaling would support this.
iainmerrick 10y ago
The need to tweak parameters is a big weakness in Java's GC. If Go's GC now performs as good or better "out of the box" than Java's does after expert tweaking, that's fantastic.

ch4s3 10y ago

Yeah it takes a few thousand calls for the JVM to "warm up". It's surprisingly noticeable on speed and latency, but I'm less knowledgeable about the GC.

willsewell 10y ago
I think we need to modify the benchmark to give enough time for the RTS to "warmup" before timing max pause times. This will provide a fairer comparison, since the end goal is to evaluate languages for web servers with large heaps and low latency requirements.
- dilap 10y ago
  I mean having a short period of time with long latency still sucks though too, right? That's real customers getting real low-quality service. Then maybe you're left doing complex things like running the server with fake traffic as a warming up period to get it to be fast enough. Sure, it'll work, but it's a lot of extra hassle.
  - ch4s3 10y ago
    You'd probably use load balancing to send some traffic to new images while they warm up. At lower volumes, you shouldn't be hitting GC pauses mid request. Then after a certain point you point everything to the new version. This is good for QA too.
    - deleted 10y ago
      [deleted]
    - dilap 10y ago
      depending on what you're doing, maybe you consider this complexity no big deal. but i don't think, for eaxmple, a standard setup using aws elb and autoscaling would support this.

iainmerrick 10y ago

The need to tweak parameters is a big weakness in Java's GC. If Go's GC now performs as good or better "out of the box" than Java's does after expert tweaking, that's fantastic.