Bug #21164
closedPerformance Regression using --jit
Description
Ruby 3.4.2 --jit runs slower than no JIT, while Ruby 3.3.7 --jit runs faster.
# frozen_string_literal: true
n = 200000
c = Array.new(n + 1, 0)
(1..n).each do |i|
a = []
m = 100
(1..m).each do
a << i
c[i] += 1
a << i / m
c[i % m] += 1
end
end
puts c.sum
results of /usr/bin/time
ruby 3.4.2
--jit : 1.98user 0.03system 0:02.02elapsed 99%CPU (0avgtext+0avgdata 19692maxresident)k
no JIT: 1.77user 0.02system 0:01.80elapsed 99%CPU (0avgtext+0avgdata 18916maxresident)k
ruby 3.3.7
--jit : 1.20user 0.05system 0:01.26elapsed 99%CPU (0avgtext+0avgdata 23220maxresident)k
no JIT: 1.81user 0.02system 0:01.83elapsed 99%CPU (0avgtext+0avgdata 22952maxresident)k
ruby -v --jit
ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +YJIT +PRISM [x86_64-linux]
Updated by k0kubun (Takashi Kokubun) 26 days ago
· Edited
- Status changed from Open to Feedback
To minimize the benchmarking noise, I suggest using Benchmark.realtime
on the benchmarked code, or at least using --disable-gems
on the Ruby command.
Anyway, in my environment, I couldn't see any slowdown with the script you provided.
No JIT:
$ chruby 3.3.7; /usr/bin/time ruby -v --disable-gems array.rb
ruby 3.3.7 (2025-01-15 revision be31f993d7) [x86_64-linux]
40000000
1.37user 0.00system 0:01.38elapsed 100%CPU (0avgtext+0avgdata 25600maxresident)k
0inputs+0outputs (0major+5746minor)pagefaults 0swaps
$ chruby 3.4.2; /usr/bin/time ruby -v --disable-gems array.rb
ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux]
40000000
1.33user 0.00system 0:01.33elapsed 99%CPU (0avgtext+0avgdata 17440maxresident)k
0inputs+0outputs (0major+3036minor)pagefaults 0swaps
With JIT:
$ chruby 3.3.7; /usr/bin/time ruby -v --jit --disable-gems array.rb
ruby 3.3.7 (2025-01-15 revision be31f993d7) +YJIT [x86_64-linux]
40000000
0.75user 0.00system 0:00.76elapsed 99%CPU (0avgtext+0avgdata 25600maxresident)k
0inputs+0outputs (0major+4787minor)pagefaults 0swaps
$ chruby 3.4.2; /usr/bin/time ruby -v --jit --disable-gems array.rb
ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +YJIT +PRISM [x86_64-linux]
40000000
0.74user 0.00system 0:00.74elapsed 99%CPU (0avgtext+0avgdata 18080maxresident)k
0inputs+0outputs (0major+2785minor)pagefaults 0swaps
Updated by purbug28 (puni ru) 26 days ago
# frozen_string_literal: true
require 'benchmark'
n = 200000
time = Benchmark.realtime do
c = Array.new(n + 1, 0)
(1..n).each do |i|
a = []
m = 100
(1..m).each do
a << i
c[i] += 1
a << i / m
c[i % m] += 1
end
end
end
puts time
I can see the same slowdown with --disable-gems
and Benchmark.realtime.
> ruby -v --disable-gems --jit array.rb
ruby 3.3.7 (2025-01-15 revision be31f993d7) +YJIT [x86_64-linux]
1.1835691558662802
> ruby -v --disable-gems --jit array.rb
ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +YJIT +PRISM [x86_64-linux]
1.9472596580162644
Updated by k0kubun (Takashi Kokubun) 26 days ago
· Edited
Thanks for updating the script. I still can't reproduce your issue.
$ chruby 3.3.7; ruby -v --disable-gems --jit array.rb
ruby 3.3.7 (2025-01-15 revision be31f993d7) +YJIT [x86_64-linux]
0.7517766600003597
$ chruby 3.4.2; ruby -v --disable-gems --jit array.rb
ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +YJIT +PRISM [x86_64-linux]
0.7428871890006121
You somehow need to make the issue reproducible on our end to make this ticket actionable. I think one problem with this script is that this does so many different things that some things may go faster while others may go slower.
Can you simplify the benchmark script further while still reproducing a significant slowdown in your environment? At the moment, you call a lot of different methods (Array.new
, Array#each
, <<
, []
, +
, /
, %
), but it'd be nice to use as fewer methods as possible in the benchmark script. Also, please consider allocating c = Array.new(n + 1, 0)
outside Benchmark.realtime
. And can you reproduce the slowdown with a single Array#each
instead of two?
Updated by purbug28 (puni ru) 26 days ago
Reinstalling Ruby resolved the issue.
Sorry for bothering you.
Updated by k0kubun (Takashi Kokubun) 25 days ago
Glad to hear that.
Just curious, were those two Rubies installed differently previously? For example, rbenv (ruby-build) is known to install Ruby with --enable-shared
, which usually degrades the performance by a few %, so installing one with rbenv and the other with something else could be a problem.