From: duerst <noreply@...>
Date: 2022-04-29T05:02:11+00:00
Subject: [ruby-core:108439] [Ruby master Bug#18760] Ractors vs "skynet" microbenchmark

Issue #18760 has been updated by duerst (Martin D��rst).


Eregon (Benoit Daloze) wrote in #note-1:

> However I heard @ko1 is working on pooling multiple Ractors per native thread, which would help for this microbenchmark (which is rather silly if you ask me, because it's like the worst case overhead for concurrency primitives, not representative of anything real world).

I guess that with silly, you mean the benchmark, not pooling of multiple Ractors.

----------------------------------------
Bug #18760: Ractors vs "skynet" microbenchmark
https://bugs.ruby-lang.org/issues/18760#change-97477

* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN
----------------------------------------
I recently stumbled upon [skynet](https://github.com/atemerev/skynet) concurrency microbenchmark and tried to adapt it to Ruby ractors.
The microbenchmarks of this kind are obviously limited, but at least they allow to do super-rough estimations of "how we are doing". It just spawns an actor (or coroutine, or channel, etc., depending on the language), which spawns 10 more, each spawning 10 more... till there are a million of them; then each just returns its ordinal number, and parents sum them up.

Ruby code:
```ruby
N = 1_000_000

def skynet(num, size, div)
  if size == 1
    Ractor.yield num
  else
    children = div.times.map { |i|
      sub_num = num + i*(size/div)
      Ractor.new(sub_num, size/div, div) { |n, sz, d| skynet(n, sz, d) }
    }
    sum = children.sum(&:take)
    Ractor.yield sum
  end
end

start_time = Time.now
main = Ractor.new { skynet(0, N, 10) }
result = main.take
end_time = Time.now
puts "Result: #{result} in #{(end_time - start_time)}s."
```
(of course, it is better to use `Process.getclocktime` probably, but that's not the point at the moment)

The point is, what I found out seems to indicate we still have some room for improvement for Ractors, to say the least.
```
$ ruby -v
ruby 3.2.0dev (2022-04-28T06:44:02Z master 5250210aa9) [x86_64-linux]
```
Results on my machine (Thinkpad E300, 8Gb mem):
* N=1000: `Result: 499500 in 1.614297829s.` (BTW, on `ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-linux]` I also checked, it was much faster: 0.3-0.4s typically)
* N=10_000: `Result: 49995000 in 46.89935975s.` (really long?)
* N=100_000: `Aborted (core dumped)`

Not sure this is telling something useful (and not sure I ported benchmark properly, TBH)

* 



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>