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: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>