From: "Eregon (Benoit Daloze) via ruby-core" <ruby-core@...>
Date: 2023-03-21T12:42:00+00:00
Subject: [ruby-core:112970] [Ruby master Bug#19288] Ractor JSON parsing significantly slower than linear parsing

Issue #19288 has been updated by Eregon (Benoit Daloze).





duerst (Martin D�rst) wrote in #note-12:

> But don't other Rubies rely on the programmer to know how to program with threads? That's only usable if you're used to programming with threads and avoid the related issues. The idea (where the implementation and many gems may still have to catch up) behind Ractor is that thread-related issues such as data races can be avoided at the level of the programming model.



We're getting a bit off-topic, but I believe not necessarily. And the GIL doesn't prevent most Ruby-level threading issues, so in that matter it's almost the same on CRuby.

For example I would think many Ruby on Rails devs don't know well threading, and they don't need to, even though webservers like Puma use threads.

Deep knowledge of multithreading is needed e.g. when creating concurrent data structures, but using them OTOH doesn't require much.

I would think for most programmers, using threads is much easier and more intuitive than having the big limitations of Ractor which prevent sharing any state, especially in an imperative and stateful language like Ruby where almost everything is mutable.

IMO Ractors are way more difficult to use than threads. They can also have some sorts of race conditions due to message order, so it's not that much safer either. And it's a lot less efficient for any communication between ractors vs threads (Ractor copy or move both need a object graph walk).



----------------------------------------

Bug #19288: Ractor JSON parsing significantly slower than linear parsing

https://bugs.ruby-lang.org/issues/19288#change-102498



* Author: maciej.mensfeld (Maciej Mensfeld)

* Status: Open

* Priority: Normal

* ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-linux]

* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN

----------------------------------------

a simple benchmark:



```ruby

require 'json'

require 'benchmark'



CONCURRENT = 5

RACTORS = true

ELEMENTS = 100_000



data = CONCURRENT.times.map do

  ELEMENTS.times.map do

    {

      rand => rand,

      rand => rand,

      rand => rand,

      rand => rand

    }.to_json

  end

end



ractors = CONCURRENT.times.map do

  Ractor.new do

    Ractor.receive.each { JSON.parse(_1) }

  end

end



result = Benchmark.measure do

  if RACTORS

    CONCURRENT.times do |i|

      ractors[i].send(data[i], move: false)

    end



    ractors.each(&:take)

  else

    # Linear without any threads

    data.each do |piece|

      piece.each { JSON.parse(_1) }

    end

  end

end



puts result

```



Gives following results on my 8 core machine:



```shell

# without ractors:

  2.731748   0.003993   2.735741 (  2.736349)



# with ractors

12.580452   5.089802  17.670254 (  5.209755)

```

I would expect Ractors not to be two times slower on the CPU intense work.











-- 

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

 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/