[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=FCrst) 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 su=
ch 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 d=
oesn't prevent most Ruby-level threading issues, so in that matter it's alm=
ost 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 da=
ta structures, but using them OTOH doesn't require much.

I would think for most programmers, using threads is much easier and more i=
ntuitive than having the big limitations of Ractor which prevent sharing an=
y 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 s=
afer either. And it's a lot less efficient for any communication between ra=
ctors 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 =3D 5

RACTORS =3D true

ELEMENTS =3D 100_000



data =3D CONCURRENT.times.map do

  ELEMENTS.times.map do

    {

      rand =3D> rand,

      rand =3D> rand,

      rand =3D> rand,

      rand =3D> rand

    }.to_json

  end

end



ractors =3D CONCURRENT.times.map do

  Ractor.new do

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

  end

end



result =3D 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.











--=20

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

 ______________________________________________
 ruby-core mailing list -- [e-mail]
 To unsubscribe send an email to [e-mail]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-c=
ore.ml.ruby-lang.org/