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

Issue #18760 has been updated by zverok (Victor Shepelev).


> 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 think that's the point (as it is for many microbenchmarks): demonstrate edge case performance for some technology. To my knowledge, `boost::fiber` of C++ and OpenJDK use this benchmark, so I was interested in what it will show.

To the best of my understanding, using `Fiber`s wouldn't be appropriate as they don't demonstrate true concurrency? (But I might be wrong, my understanding of concurrency/parallelism is flawed, to say the least.)

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

* 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>