From: Eric Wong Date: 2018-05-06T03:23:49+00:00 Subject: [ruby-core:86916] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC the.codefolio.guy@gmail.com wrote: > For Rails Ruby Bench (large concurrent Rails benchmark based > on Discourse), So multithreaded? Do you have any info on the amount of CPU time was being used without these changes? If the CPU usage was already 100% or close before the patch, then I'd expect no benefit. So yeah, for benchmarking, I would mainly expect it to show up more in single-threaded benchmarks. But for practical use outside of benchmarks, I think there'll be a benefit in all <100% CPU usage scenarios (which is typical of real-world traffic, but not benchmarks). > measuring sleepy-gc-v3 branch versus the > previous commit, the difference isn't measurable. No > detectable speedup. The sleepy-gc batch of runs has a higher > variance in runtime, but that may just be an outlier or two - > I'd need a lot more samples to see if it consistently gives > higher variance. The variance is often randomly a bit > different batch-to-batch. The variance might have something to do with the malloc and settings used (arena count), especially when multithreaded. (see what I wrote previously about cross-thread malloc/free). I experimented with some GC-start-on-sleep the other day, but didn't get very far as far as having a small reproducible benchmark case. If anybody wants to give me SSH access to a machine they run 100% Free Software benchmarks on, my public key has always been here: https://yhbt.net/id_rsa.pub I will only use a terminal for Ruby development, no GUIs. Thanks (also won't be around computers much for another day or two) Unsubscribe: