[ruby-core:108462] [Ruby master Bug#18760] Ractors vs "skynet" microbenchmark

Issue #18760 has been updated by shan (Shannon Skipper).


@zverok here's a Ruby example with Fibers that I ported from `skynet.cr`.

``` ruby
require 'async'
require 'async/queue'

def skynet(c, num, size, div)
  if size == 1
    c << num
  else
    rc = Async::LimitedQueue.new(div)
    sum = 0
    div.times do |i|
      sub_num = num + (i * (size / div))
      Async { skynet(rc, sub_num, size / div, div) }
    end
    div.times do
      sum += rc.dequeue
    end
    c << sum
  end
end

c = Async::LimitedQueue.new(1)
start_time = Time.now
Sync { skynet(c, 0, 1_000_000, 10) }
result = Sync { c.dequeue }
end_time = Time.now
puts "Result: #{result} in #{end_time - start_time}s."
```


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

* 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:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>