path: root/benchmark
AgeCommit message (Collapse)Author
5 daysst.c: skip all deleted entries [Bug #17779]tompng (tomoya ishida)
Update the start entry skipping all already deleted entries. Fixes performance issue of `Hash#first` in a certain case.
2021-03-16Improve Enumerable#tally performanceNobuyoshi Nakada
Iteration per second (i/s) | |compare-ruby|built-ruby| |:------|-----------:|---------:| |tally | 52.814| 114.936| | | -| 2.18x| Notes: Merged:
2021-03-10Add a benchmark for RubyVM::InstructionSequence.load_from_binaryJean Boussier
Notes: Merged:
2021-03-10proc.c: make bind_call use existing callable method entry when possibleJean Boussier
The most common use case for `bind_call` is to protect from core methods being redefined, for instance a typical use: ```ruby UNBOUND_METHOD_MODULE_NAME = Module.instance_method(:name) def real_mod_name(mod) UNBOUND_METHOD_MODULE_NAME.bind_call(mod) end ``` But it's extremely common that the method wasn't actually redefined. In such case we can avoid creating a new callable method entry, and simply delegate to the receiver. This result in a 1.5-2X speed-up for the fast path, and little to no impact on the slowpath: ``` compare-ruby: ruby 3.1.0dev (2021-02-05T06:33:00Z master b2674c1fd7) [x86_64-darwin19] built-ruby: ruby 3.1.0dev (2021-02-15T10:35:17Z bind-call-fastpath d687e06615) [x86_64-darwin19] | |compare-ruby|built-ruby| |:---------|-----------:|---------:| |fastpath | 11.325M| 16.393M| | | -| 1.45x| |slowpath | 10.488M| 10.242M| | | 1.02x| -| ``` Notes: Merged:
2021-02-19Improve performance some Numeric methods [Feature #17632] (#4190)S.H
Notes: Merged-By: k0kubun <>
2021-02-11Do not run File.write while Ractors are runningTakashi Kokubun
also make sure all local variables have the __bmdv_ prefix.
2021-02-10Add a benchmark-driver runner for Ractor (#4172)Takashi Kokubun
* Add a benchmark-driver runner for Ractor * Process.clock_gettime(Process:CLOCK_MONOTONIC) could be slow in Ruby 3.0 Ractor * Fetching Time could also be slow * Fix a comment * Assert overriding a private method Notes: Merged-By: k0kubun <>
2021-02-10Simple benchmark of Float#to_sNobuyoshi Nakada
2021-02-08Improve performance Float#positive? and Float#negative? [Feature #17614] (#4160)S.H
Notes: Merged-By: k0kubun <>
2021-01-13Rename RubyVM::MJIT to RubyVM::JITTakashi Kokubun
because the name "MJIT" is an internal code name, it's inconsistent with --jit while they are related to each other, and I want to discourage future JIT implementation-specific (e.g. MJIT-specific) APIs by this rename. [Feature #17490]
2021-01-01Improve performance some Float methods [Feature #17498] (#4018)S.H
Notes: Merged-By: k0kubun <>
2020-12-22Allow inlining Integer#-@ and #~Takashi Kokubun
``` $ benchmark-driver -v --rbenv 'before --jit;after --jit' benchmark/mjit_integer.yml --filter '(comp|uminus)' before --jit: ruby 3.0.0dev (2020-12-23T05:41:44Z master 0dd4896175) +JIT [x86_64-linux] after --jit: ruby 3.0.0dev (2020-12-23T06:25:41Z master 8887d78992) +JIT [x86_64-linux] last_commit=Allow inlining Integer#-@ and #~ Calculating ------------------------------------- before --jit after --jit mjit_comp(1) 44.006M 70.417M i/s - 40.000M times in 0.908967s 0.568042s mjit_uminus(1) 44.333M 68.422M i/s - 40.000M times in 0.902255s 0.584603s Comparison: mjit_comp(1) after --jit: 70417331.4 i/s before --jit: 44005980.4 i/s - 1.60x slower mjit_uminus(1) after --jit: 68422468.8 i/s before --jit: 44333371.0 i/s - 1.54x slower ```
2020-12-16fix duplicated nameKoichi Sasada
2020-12-04Guard all accesses to RubyVM::MJIT with defined?(RubyVM::MJIT) &&Benoit Daloze
* Otherwise those tests, etc cannot run on alternative Ruby implementations.
2020-11-16Set allocator on class creationAlan Wu
Allocating an instance of a class uses the allocator for the class. When the class has no allocator set, Ruby looks for it in the super class (see rb_get_alloc_func()). It's uncommon for classes created from Ruby code to ever have an allocator set, so it's common during the allocation process to search all the way to BasicObject from the class with which the allocation is being performed. This makes creating instances of classes that have long ancestry chains more expensive than creating instances of classes have that shorter ancestry chains. Setting the allocator at class creation time removes the need to perform a search for the alloctor during allocation. This is a breaking change for C-extensions that assume that classes created from Ruby code have no allocator set. Libraries that setup a class hierarchy in Ruby code and then set the allocator on some parent class, for example, can experience breakage. This seems like an unusual use case and hopefully it is rare or non-existent in practice. Rails has many classes that have upwards of 60 elements in the ancestry chain and benchmark shows a significant improvement for allocating with a class that includes 64 modules. ``` pre: ruby 3.0.0dev (2020-11-12T14:39:27Z master 6325866421) post: ruby 3.0.0dev (2020-11-12T20:15:30Z cut-allocator-lookup) Comparison: allocate_8_deep post: 10336985.6 i/s pre: 8691873.1 i/s - 1.19x slower allocate_32_deep post: 10423181.2 i/s pre: 6264879.1 i/s - 1.66x slower allocate_64_deep post: 10541851.2 i/s pre: 4936321.5 i/s - 2.14x slower allocate_128_deep post: 10451505.0 i/s pre: 3031313.5 i/s - 3.45x slower ``` Notes: Merged:
2020-11-09Add a benchmark for polymorphic ivar settingAaron Patterson
This benchmark demonstrates the performance of setting an instance variable when the type of object is constantly changing. This benchmark should give us an idea of the performance of ivar setting in a polymorphic environment Notes: Merged:
2020-11-09eagerly initialize ivar table when index is small enoughAaron Patterson
When the inline cache is written, the iv table will contain an entry for the instance variable. If we get an inline cache hit, then we know the iv table must contain a value for the index written to the inline cache. If the index in the inline cache is larger than the list on the object, but *smaller* than the iv index table on the class, then we can just eagerly allocate the iv list to be the same size as the iv index table. This avoids duplicate work of checking frozen as well as looking up the index for the particular instance variable name. Notes: Merged:
2020-10-28Added benchmark of vm_send by variable [ci skip]Nobuyoshi Nakada
2020-09-23Improve the performance of supereileencodes
This PR improves the performance of `super` calls. While working on some Rails optimizations jhawthorn discovered that `super` calls were slower than expected. The changes here do the following: 1) Adds a check for whether the call frame is not equal to the method entry iseq. This avoids the `rb_obj_is_kind_of` check on the next line which is quite slow. If the current call frame is equal to the method entry we know we can't have an instance eval, etc. 2) Changes `FL_TEST` to `FL_TEST_RAW`. This is safe because we've already done the check for `T_ICLASS` above. 3) Adds a benchmark for `T_ICLASS` super calls. 4) Note: makes a chage for `method_entry_cref` to use `const`. On master the benchmarks showed that `super` is 1.76x slower. Our changes improved the performance so that it is now only 1.36x slower. Benchmark IPS: ``` Warming up -------------------------------------- super 244.918k i/100ms method call 383.007k i/100ms Calculating ------------------------------------- super 2.280M (± 6.7%) i/s - 11.511M in 5.071758s method call 3.834M (± 4.9%) i/s - 19.150M in 5.008444s Comparison: method call: 3833648.3 i/s super: 2279837.9 i/s - 1.68x (± 0.00) slower ``` With changes: ``` Warming up -------------------------------------- super 308.777k i/100ms method call 375.051k i/100ms Calculating ------------------------------------- super 2.951M (± 5.4%) i/s - 14.821M in 5.039592s method call 3.551M (± 4.9%) i/s - 18.002M in 5.081695s Comparison: method call: 3551372.7 i/s super: 2950557.9 i/s - 1.20x (± 0.00) slower ``` Ruby VM benchmarks also showed an improvement: Existing `vm_super` benchmark`. ``` $ make benchmark ITEM=vm_super | |compare-ruby|built-ruby| |:---------|-----------:|---------:| |vm_super | 21.555M| 37.819M| | | -| 1.75x| ``` New `vm_iclass_super` benchmark: ``` $ make benchmark ITEM=vm_iclass_super | |compare-ruby|built-ruby| |:----------------|-----------:|---------:| |vm_iclass_super | 1.669M| 3.683M| | | -| 2.21x| ``` This is the benchmark script used for the benchmark-ips benchmarks: ```ruby require "benchmark/ips" class Foo def zuper; end def top; end last_method = "top" ("A".."M").each do |module_name| eval <<-EOM module #{module_name} def zuper; super; end def #{module_name.downcase} #{last_method} end end prepend #{module_name} EOM last_method = module_name.downcase end end foo = Benchmark.ips do |x| "super" do foo.zuper end "method call" do foo.m end! end ``` Co-authored-by: Aaron Patterson <> Co-authored-by: John Hawthorn <> Notes: Merged:
2020-09-09Optimize ObjectSpace.dump_allJean Boussier
The two main optimization are: - buffer writes for improved performance - avoid formatting functions when possible ``` | |compare-ruby|built-ruby| |:------------------|-----------:|---------:| |dump_all_string | 1.038| 195.925| | | -| 188.77x| |dump_all_file | 33.453| 139.645| | | -| 4.17x| |dump_all_dev_null | 44.030| 278.552| | | -| 6.33x| ``` Notes: Merged:
2020-07-23Improved Enumerable::Lazy#zipNobuyoshi Nakada
| |compare-ruby|built-ruby| |:-------------------|-----------:|---------:| |first_ary | 290.514k| 296.331k| | | -| 1.02x| |first_nonary | 166.954k| 169.178k| | | -| 1.01x| |first_noarg | 299.547k| 305.358k| | | -| 1.02x| |take3_ary | 129.388k| 188.360k| | | -| 1.46x| |take3_nonary | 90.684k| 112.688k| | | -| 1.24x| |take3_noarg | 131.940k| 189.471k| | | -| 1.44x| |chain-first_ary | 195.913k| 286.194k| | | -| 1.46x| |chain-first_nonary | 127.483k| 168.716k| | | -| 1.32x| |chain-first_noarg | 201.252k| 298.562k| | | -| 1.48x| |chain-take3_ary | 101.189k| 183.188k| | | -| 1.81x| |chain-take3_nonary | 75.381k| 112.301k| | | -| 1.49x| |chain-take3_noarg | 101.483k| 192.148k| | | -| 1.89x| |block | 296.696k| 292.877k| | | 1.01x| -| Notes: Merged:
2020-07-23Improved Enumerable::Lazy#flat_mapNobuyoshi Nakada
| |compare-ruby|built-ruby| |:-------|-----------:|---------:| |num3 | 96.333k| 160.732k| | | -| 1.67x| |num10 | 96.615k| 159.150k| | | -| 1.65x| |ary2 | 103.836k| 172.787k| | | -| 1.66x| |ary10 | 109.249k| 177.252k| | | -| 1.62x| |ary20 | 106.628k| 177.371k| | | -| 1.66x| |ary50 | 107.135k| 162.282k| | | -| 1.51x| |ary100 | 106.513k| 177.626k| | | -| 1.67x| Notes: Merged:
2020-07-18Optimize Array#min (#3324)Kenta Murata
The benchmark result is below: | |compare-ruby|built-ruby| |:---------------|-----------:|---------:| |ary2.min | 39.105M| 39.442M| | | -| 1.01x| |ary10.min | 23.995M| 30.762M| | | -| 1.28x| |ary100.min | 6.249M| 10.783M| | | -| 1.73x| |ary500.min | 1.408M| 2.714M| | | -| 1.93x| |ary1000.min | 828.397k| 1.465M| | | -| 1.77x| |ary2000.min | 332.256k| 570.504k| | | -| 1.72x| |ary3000.min | 338.079k| 573.868k| | | -| 1.70x| |ary5000.min | 168.217k| 286.114k| | | -| 1.70x| |ary10000.min | 85.512k| 143.551k| | | -| 1.68x| |ary20000.min | 43.264k| 71.935k| | | -| 1.66x| |ary50000.min | 17.317k| 29.107k| | | -| 1.68x| |ary100000.min | 9.072k| 14.540k| | | -| 1.60x| |ary1000000.min | 872.930| 1.436k| | | -| 1.64x| compare-ruby is 9f4b7fc82e. Notes: Merged-By: mrkn <>
2020-07-18Optimize Array#max (#3325)Kenta Murata
The benchmark result is below: | |compare-ruby|built-ruby| |:---------------|-----------:|---------:| |ary2.max | 38.837M| 40.830M| | | -| 1.05x| |ary10.max | 23.035M| 32.626M| | | -| 1.42x| |ary100.max | 5.490M| 11.020M| | | -| 2.01x| |ary500.max | 1.324M| 2.679M| | | -| 2.02x| |ary1000.max | 699.167k| 1.403M| | | -| 2.01x| |ary2000.max | 284.321k| 570.446k| | | -| 2.01x| |ary3000.max | 282.613k| 571.683k| | | -| 2.02x| |ary5000.max | 145.120k| 285.546k| | | -| 1.97x| |ary10000.max | 72.102k| 142.831k| | | -| 1.98x| |ary20000.max | 36.065k| 72.077k| | | -| 2.00x| |ary50000.max | 14.343k| 29.139k| | | -| 2.03x| |ary100000.max | 7.586k| 14.472k| | | -| 1.91x| |ary1000000.max | 726.915| 1.495k| | | -| 2.06x| Notes: Merged-By: mrkn <>
2020-07-06Inline builtin struct arefTakashi Kokubun
We don't do this for aset because it might raise a FrozenError. ``` $ benchmark-driver -v --rbenv 'before;after;before --jit;after --jit' benchmark/mjit_struct_aref.yml --repeat-count=4 before: ruby 2.8.0dev (2020-07-06T01:47:11Z master d94ef7c6b6) [x86_64-linux] after: ruby 2.8.0dev (2020-07-06T07:11:51Z master 85425168f4) [x86_64-linux] last_commit=Inline builtin struct aref before --jit: ruby 2.8.0dev (2020-07-06T01:47:11Z master d94ef7c6b6) +JIT [x86_64-linux] after --jit: ruby 2.8.0dev (2020-07-06T07:11:51Z master 85425168f4) +JIT [x86_64-linux] last_commit=Inline builtin struct aref Calculating ------------------------------------- before after before --jit after --jit mjit_struct_aref(struct) 34.783M 34.810M 48.321M 58.378M i/s - 40.000M times in 1.149996s 1.149097s 0.827794s 0.685192s Comparison: mjit_struct_aref(struct) after --jit: 58377836.7 i/s before --jit: 48321205.7 i/s - 1.21x slower after: 34809935.5 i/s - 1.68x slower before: 34782736.5 i/s - 1.68x slower ```
2020-07-03Make Kernel#then, #yield_self, #frozen? builtin (#3283)Takashi Kokubun
* Make Kernel#then, #yield_self, #frozen? builtin * Fix test_jit Notes: Merged-By: k0kubun <>
2020-07-03Rewrite Kernel#tap with Ruby (#3281)Takashi Kokubun
* Rewrite Kernel#tap with Ruby This was good for VM too, but of course my intention is to unblock JIT's inlining of a block over yield (inlining invokeyield has not been committed though). * Fix test_settracefunc About the :tap deletions, the :tap events are actually traced (we already have a TracePoint test for builtin methods), but it's filtered out by tp.path == "xyzzy" (it became "<internal:kernel>"). We could trace tp.path == "<internal:kernel>" cases too, but the lineno is impacted by kernel.rb changes and I didn't want to make it fragile for kernel.rb lineno changes. Notes: Merged-By: k0kubun <>
2020-06-27Mark some Integer methods as inline (#3264)Takashi Kokubun
Notes: Merged-By: k0kubun <>
2020-06-27Add pattern matching with arrays benchmarkVladimir Dementyev
Notes: Merged:
2020-06-25Decide JIT-ed insn based on cached cfuncTakashi Kokubun
for opt_* insns. opt_eq handles rb_obj_equal inside opt_eq, and all other cfunc is handled by opt_send_without_block. Therefore we can't decide which insn should be generated by checking whether it's cfunc cc or not. ``` $ benchmark-driver -v --rbenv 'before --jit;after --jit' benchmark/mjit_opt_cc_insns.yml --repeat-count=4 before --jit: ruby 2.8.0dev (2020-06-26T05:21:43Z master 9dbc2294a6) +JIT [x86_64-linux] after --jit: ruby 2.8.0dev (2020-06-26T06:30:18Z master 75cece1b0b) +JIT [x86_64-linux] last_commit=Decide JIT-ed insn based on cached cfunc Calculating ------------------------------------- before --jit after --jit mjit_nil?(1) 73.878M 74.021M i/s - 40.000M times in 0.541432s 0.540391s mjit_not(1) 72.635M 74.601M i/s - 40.000M times in 0.550702s 0.536187s mjit_eq(1, nil) 7.331M 7.445M i/s - 8.000M times in 1.091211s 1.074596s mjit_eq(nil, 1) 49.450M 64.711M i/s - 8.000M times in 0.161781s 0.123627s Comparison: mjit_nil?(1) after --jit: 74020528.4 i/s before --jit: 73878185.9 i/s - 1.00x slower mjit_not(1) after --jit: 74600882.0 i/s before --jit: 72634507.6 i/s - 1.03x slower mjit_eq(1, nil) after --jit: 7444657.4 i/s before --jit: 7331304.3 i/s - 1.02x slower mjit_eq(nil, 1) after --jit: 64710790.6 i/s before --jit: 49449507.4 i/s - 1.31x slower ```
2020-06-23Annotate Kernel#class as inline (#3250)Takashi Kokubun
``` $ benchmark-driver -v --rbenv 'before;after;before --jit;after --jit' benchmark/mjit_class.yml --repeat-count=4 before: ruby 2.8.0dev (2020-06-23T07:09:54Z master 37a2e48d76) [x86_64-linux] after: ruby 2.8.0dev (2020-06-23T17:29:56Z inline-class 0ff147c007) [x86_64-linux] before --jit: ruby 2.8.0dev (2020-06-23T07:09:54Z master 37a2e48d76) +JIT [x86_64-linux] after --jit: ruby 2.8.0dev (2020-06-23T17:29:56Z inline-class 0ff147c007) +JIT [x86_64-linux] Calculating ------------------------------------- before after before --jit after --jit mjit_class(self) 39.219M 40.060M 53.502M 69.202M i/s - 40.000M times in 1.019915s 0.998495s 0.747631s 0.578021s mjit_class(1) 39.567M 41.242M 52.100M 68.895M i/s - 40.000M times in 1.010935s 0.969885s 0.767749s 0.580591s Comparison: mjit_class(self) after --jit: 69201690.7 i/s before --jit: 53502336.4 i/s - 1.29x slower after: 40060289.1 i/s - 1.73x slower before: 39218939.2 i/s - 1.76x slower mjit_class(1) after --jit: 68895358.6 i/s before --jit: 52100353.0 i/s - 1.32x slower after: 41241993.6 i/s - 1.67x slower before: 39567314.0 i/s - 1.74x slower ``` Notes: Merged-By: k0kubun <>
2020-06-22Compile opt_send for opt_* only when cc has ISeqTakashi Kokubun
because opt_nil/opt_not/opt_eq populates cc even when it doesn't fallback to opt_send_without_block because of vm_method_cfunc_is. ``` $ benchmark-driver -v --rbenv 'before --jit;after --jit' benchmark/mjit_opt_cc_insns.yml --repeat-count=4 before --jit: ruby 2.8.0dev (2020-06-22T08:11:24Z master d231b8f95b) +JIT [x86_64-linux] after --jit: ruby 2.8.0dev (2020-06-22T08:53:27Z master e1125879ed) +JIT [x86_64-linux] last_commit=Compile opt_send for opt_* only when cc has ISeq Calculating ------------------------------------- before --jit after --jit mjit_nil?(1) 54.106M 73.693M i/s - 40.000M times in 0.739288s 0.542795s mjit_not(1) 53.398M 74.477M i/s - 40.000M times in 0.749090s 0.537075s mjit_eq(1, nil) 7.427M 6.497M i/s - 8.000M times in 1.077136s 1.231326s Comparison: mjit_nil?(1) after --jit: 73692594.3 i/s before --jit: 54106108.4 i/s - 1.36x slower mjit_not(1) after --jit: 74477487.9 i/s before --jit: 53398125.0 i/s - 1.39x slower mjit_eq(1, nil) before --jit: 7427105.9 i/s after --jit: 6497063.0 i/s - 1.14x slower ``` Actually opt_eq becomes slower by this. Maybe it's indeed using opt_send_without_block, but I'll approach that one in another commit.
2020-06-22Share warmup logic across MJIT benchmarksTakashi Kokubun
2020-06-22The RUBYOPT= comment is no longer neededTakashi Kokubun
2020-06-22Stop relying on `make benchmark`'s `-I$(srcdir)/benchmark/lib`Takashi Kokubun
These days I don't use `make benchmark`. The YAML files should be executable with bare `benchmark-driver` CLI without passing `RUBYOPT=-Ibenchmark/lib`.
2020-06-20Introduce Primitive.attr! to annotate 'inline' (#3242)Takashi Kokubun
[Feature #15589] Notes: Merged-By: k0kubun <>
2020-06-20Make Integer#zero? a separated method and builtin (#3226)Takashi Kokubun
A prerequisite to fix with JIT. This commit alone doesn't make a significant difference yet, but I thought this commit should be committed independently. This method override was discussed in [Misc #16961]. Notes: Merged-By: k0kubun <>
2020-06-07Fix `make benchmark` exampleRyuta Kamizono
`make benchmark ARGS=../benchmark/erb_render.yml` does not work. ``` % make benchmark ARGS=../benchmark/erb_render.yml /Users/kamipo/.rbenv/shims/ruby --disable=gems -rrubygems -I./benchmark/lib ./benchmark/benchmark-driver/exe/benchmark-driver \ --executables="compare-ruby::/Users/kamipo/.rbenv/shims/ruby --disable=gems -I.ext/common --disable-gem" \ --executables="built-ruby::./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems --disable-gem" \ ../benchmark/erb_render.yml Traceback (most recent call last): 6: from ./benchmark/benchmark-driver/exe/benchmark-driver:112:in `<main>' 5: from ./benchmark/benchmark-driver/exe/benchmark-driver:112:in `flat_map' 4: from ./benchmark/benchmark-driver/exe/benchmark-driver:112:in `each' 3: from ./benchmark/benchmark-driver/exe/benchmark-driver:122:in `block in <main>' 2: from /Users/kamipo/.rbenv/versions/2.6.6/lib/ruby/2.6.0/psych.rb:577:in `load_file' 1: from /Users/kamipo/.rbenv/versions/2.6.6/lib/ruby/2.6.0/psych.rb:577:in `open' /Users/kamipo/.rbenv/versions/2.6.6/lib/ruby/2.6.0/psych.rb:577:in `initialize': No such file or directory @ rb_sysopen - ../benchmark/erb_render.yml (Errno::ENOENT) make: *** [benchmark] Error 1 % make benchmark ARGS=benchmark/erb_render.yml /Users/kamipo/.rbenv/shims/ruby --disable=gems -rrubygems -I./benchmark/lib ./benchmark/benchmark-driver/exe/benchmark-driver \ --executables="compare-ruby::/Users/kamipo/.rbenv/shims/ruby --disable=gems -I.ext/common --disable-gem" \ --executables="built-ruby::./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems --disable-gem" \ benchmark/erb_render.yml Calculating ------------------------------------- compare-ruby built-ruby erb_render 825.454k 783.664k i/s - 1.500M times in 1.817181s 1.914086s Comparison: erb_render compare-ruby: 825454.4 i/s built-ruby: 783663.8 i/s - 1.05x slower ``` Notes: Merged:
2020-06-03add benchmark for different block handlers卜部昌平
Notes: Merged:
2020-05-12Added String#split benchmark for empty regexpNobuyoshi Nakada
| |compare-ruby|built-ruby| |:--------------|-----------:|---------:| |re_chars-1 | 169.230k| 973.855k| | | -| 5.75x| |re_chars-10 | 25.536k| 107.598k| | | -| 4.21x| |re_chars-100 | 2.621k| 11.207k| | | -| 4.28x| |re_chars-1000 | 259.098| 1.133k| | | -| 4.37x|
2020-05-12Optimize String#splitNobuyoshi Nakada
Optimized `String#split` with `/ /` (single space regexp) as simple string splitting. [ruby-core:98272] | |compare-ruby|built-ruby| |:--------------|-----------:|---------:| |re_space-1 | 432.786k| 1.539M| | | -| 3.56x| |re_space-10 | 76.231k| 191.547k| | | -| 2.51x| |re_space-100 | 8.152k| 19.557k| | | -| 2.40x| |re_space-1000 | 837.405| 2.022k| | | -| 2.41x| ruby-core:98272: Notes: Merged:
2020-04-22support builtin for Kernel#FloatS.H
# Iteration per second (i/s) | |compare-ruby|built-ruby| |:------------|-----------:|---------:| |float | 30.395M| 38.314M| | | -| 1.26x| |float_true | 3.833M| 27.322M| | | -| 7.13x| |float_false | 4.182M| 24.938M| | | -| 5.96x| Notes: Merged: Merged-By: nobu <>
2020-04-13Unify vm benchmark prefixes to vm_ (#3028)Takashi Kokubun
The vm1_ prefix and vm2_ had had special meaning until 820ad9cb1d72d0897b73dae282df3793814b27e8 and 12068aa4e980ab32a0438408a519030e65dabf5e. AFAIK there's no special meaning in vm3_ prefix. As they have confused people (like "In `benchmark` what is difference between `vm1_`, `vm2_` and `vm3_`"), I'd like to remove the obsoleted prefix as we obviated that two years ago. Notes: Merged-By: k0kubun <>
2020-04-13Make vm_call_cfunc_with_frame a fastpath (#3027)Takashi Kokubun
when there's no need to call CALLER_SETUP_ARG and CALLER_REMOVE_EMPTY_KW_SPLAT (i.e. !rb_splat_or_kwargs_p(ci) && !calling->kw_splat). Micro benchmark: ``` $ benchmark-driver -v --rbenv 'before;after' benchmark/vm_send_cfunc.yml --repeat-count=4 before: ruby 2.8.0dev (2020-04-13T23:45:05Z master b9d3ceee8f) [x86_64-linux] after: ruby 2.8.0dev (2020-04-14T00:48:52Z no-splat-fastpath 418d363722) [x86_64-linux] Calculating ------------------------------------- before after vm_send_cfunc 69.585M 88.724M i/s - 100.000M times in 1.437097s 1.127096s Comparison: vm_send_cfunc after: 88723605.2 i/s before: 69584737.1 i/s - 1.28x slower ``` Optcarrot: ``` $ benchmark-driver -v --rbenv 'before;after' benchmark.yml --repeat-count=12 --output=all before: ruby 2.8.0dev (2020-04-13T23:45:05Z master b9d3ceee8f) [x86_64-linux] after: ruby 2.8.0dev (2020-04-14T00:48:52Z no-splat-fastpath 418d363722) [x86_64-linux] Calculating ------------------------------------- before after Optcarrot Lan_Master.nes 50.76119601545175 42.73858236484051 fps 50.76388649761503 51.04211379912850 50.80930672252514 51.39455790755538 50.90236000778749 51.75656936556145 51.01744746340430 51.86875277356489 51.06495279015112 51.88692482485558 51.07785337168974 51.93429603190578 51.20163525187862 51.95768145071314 51.34671771913112 52.45577266040274 51.35918340835583 52.53163888762858 51.46641337418146 52.62172484121034 51.50835463462257 52.85064021113239 ``` Notes: Merged-By: k0kubun <>
2020-04-13Unwrap vm_call_cfunc indirection on JITTakashi Kokubun
for VM_METHOD_TYPE_CFUNC. This has been known to decrease optcarrot fps: ``` $ benchmark-driver -v --rbenv 'before --jit;after --jit' benchmark.yml --repeat-count=24 --output=all before --jit: ruby 2.8.0dev (2020-04-13T16:25:13Z master fb40495cd9) +JIT [x86_64-linux] after --jit: ruby 2.8.0dev (2020-04-13T23:23:11Z mjit-inline-c bdcd06d159) +JIT [x86_64-linux] Calculating ------------------------------------- before --jit after --jit Optcarrot Lan_Master.nes 66.38132676191719 67.41369177299630 fps 69.42728743772243 68.90327567263054 72.16028300263211 69.62605130880686 72.46631319102777 70.48818243767207 73.37078877002490 70.79522887347566 73.69422431217367 70.99021920193194 74.01471487018695 74.69931965402584 75.48685183295630 74.86714575949016 75.54445264507932 75.97864419721677 77.28089738169756 76.48908637569581 78.04183397891302 76.54320932488021 78.36807984096562 76.59407262898067 78.92898762543574 77.31316743361343 78.93576483233765 77.97153484180480 79.13754917503078 77.98478782102325 79.62648945850653 78.02263322726446 79.86334213878064 78.26333724045934 80.05100635898518 78.60056756355614 80.26186843769584 78.91082645644468 80.34205717020330 79.01226659142263 80.62286066044338 79.32733939423721 80.95883033058557 79.63793060542024 80.97376819251613 79.73108936622778 81.23050939202896 80.18280109433088 ``` and I deleted this capability in an early stage of YARV-MJIT development: I suspect either of the following things could be the cause: * Directly calling vm_call_cfunc requires more optimization effort in GCC, resulting in 30ms-ish compilation time increase for such methods and decreasing the number of methods compiled in a benchmarked period. * Code size increase => icache miss hit These hypotheses could be verified by some methodologies. However, I'd like to introduce this regardless of the result because this blocks inlining C method's definition. I may revert this commit when I give up to implement inlining C method definition, which requires this change. Microbenchmark-wise, this gives slight performance improvement: ``` $ benchmark-driver -v --rbenv 'before --jit;after --jit' benchmark/mjit_send_cfunc.yml --repeat-count=4 before --jit: ruby 2.8.0dev (2020-04-13T16:25:13Z master fb40495cd9) +JIT [x86_64-linux] after --jit: ruby 2.8.0dev (2020-04-13T23:23:11Z mjit-inline-c bdcd06d159) +JIT [x86_64-linux] Calculating ------------------------------------- before --jit after --jit mjit_send_cfunc 41.961M 56.489M i/s - 100.000M times in 2.383143s 1.770244s Comparison: mjit_send_cfunc after --jit: 56489372.5 i/s before --jit: 41961388.1 i/s - 1.35x slower ```
2020-03-31Make JIT-ed leave insn leafTakashi Kokubun
to eliminate sp / pc moves by cancelling JIT execution on interrupts. $ benchmark-driver benchmark.yml -v --rbenv 'before --jit;after --jit' --repeat-count=12 --output=all before --jit: ruby 2.8.0dev (2020-04-01T03:48:56Z master 5a81562dfe) +JIT [x86_64-linux] after --jit: ruby 2.8.0dev (2020-04-01T04:58:01Z master 39beb26a27) +JIT [x86_64-linux] Calculating ------------------------------------- before --jit after --jit Optcarrot Lan_Master.nes 75.06409603894944 76.06422026555558 fps 75.12025067279242 78.48161731616810 77.42020273492177 79.78958240950033 79.07253675128945 79.88645902325614 79.99179109732327 80.33743931749331 80.07633091008627 80.53790081529166 80.15450942667547 80.99048270668010 80.48372803283709 81.70497146081003 80.57410149187352 82.79494539467382 81.80449157081202 82.85797792223954 82.24629397834902 83.00603891515506 82.63708148686703 83.23221006969828 $ benchmark-driver -v --rbenv 'before;before --jit;after --jit' benchmark/mjit_leave.yml --repeat-count=4 before: ruby 2.8.0dev (2020-04-01T03:48:56Z master 5a81562dfe) [x86_64-linux] before --jit: ruby 2.8.0dev (2020-04-01T03:48:56Z master 5a81562dfe) +JIT [x86_64-linux] after --jit: ruby 2.8.0dev (2020-04-01T04:58:01Z master 39beb26a27) +JIT [x86_64-linux] Calculating ------------------------------------- before before --jit after --jit mjit_leave 106.656M 82.786M 91.635M i/s - 200.000M times in 1.875183s 2.415881s 2.182569s Comparison: mjit_leave before: 106656239.9 i/s after --jit: 91635143.7 i/s - 1.16x slower before --jit: 82785537.2 i/s - 1.29x slower
2020-03-30Remove an unused pragmaTakashi Kokubun
It originally had a string literal, but it no longer has one.
2020-03-30Optimize exivar access on JIT-ed getivarTakashi Kokubun
JIT support of dd723771c11. $ benchmark-driver -v --rbenv 'before;before --jit;after --jit' benchmark/mjit_exivar.yml --repeat-count=4 before: ruby 2.8.0dev (2020-03-30T12:32:26Z master e5db3da9d3) [x86_64-linux] before --jit: ruby 2.8.0dev (2020-03-30T12:32:26Z master e5db3da9d3) +JIT [x86_64-linux] after --jit: ruby 2.8.0dev (2020-03-31T05:57:24Z mjit-exivar 128625baec) +JIT [x86_64-linux] Calculating ------------------------------------- before before --jit after --jit mjit_exivar 57.944M 53.579M 54.471M i/s - 200.000M times in 3.451588s 3.732772s 3.671687s Comparison: mjit_exivar before: 57944345.1 i/s after --jit: 54470876.7 i/s - 1.06x slower before --jit: 53579483.4 i/s - 1.08x slower
2020-03-17Reduce allocations for keyword argument hashesJeremy Evans
Previously, passing a keyword splat to a method always allocated a hash on the caller side, and accepting arbitrary keywords in a method allocated a separate hash on the callee side. Passing explicit keywords to a method that accepted a keyword splat did not allocate a hash on the caller side, but resulted in two hashes allocated on the callee side. This commit makes passing a single keyword splat to a method not allocate a hash on the caller side. Passing multiple keyword splats or a mix of explicit keywords and a keyword splat still generates a hash on the caller side. On the callee side, if arbitrary keywords are not accepted, it does not allocate a hash. If arbitrary keywords are accepted, it will allocate a hash, but this commit uses a callinfo flag to indicate whether the caller already allocated a hash, and if so, the callee can use the passed hash without duplicating it. So this commit should make it so that a maximum of a single hash is allocated during method calls. To set the callinfo flag appropriately, method call argument compilation checks if only a single keyword splat is given. If only one keyword splat is given, the VM_CALL_KW_SPLAT_MUT callinfo flag is not set, since in that case the keyword splat is passed directly and not mutable. If more than one splat is used, a new hash needs to be generated on the caller side, and in that case the callinfo flag is set, indicating the keyword splat is mutable by the callee. In compile_hash, used for both hash and keyword argument compilation, if compiling keyword arguments and only a single keyword splat is used, pass the argument directly. On the caller side, in vm_args.c, the callinfo flag needs to be recognized and handled. Because the keyword splat argument may not be a hash, it needs to be converted to a hash first if not. Then, unless the callinfo flag is set, the hash needs to be duplicated. The temporary copy of the callinfo flag, kw_flag, is updated if a hash was duplicated, to prevent the need to duplicate it again. If we are converting to a hash or duplicating a hash, we need to update the argument array, which can including duplicating the positional splat array if one was passed. CALLER_SETUP_ARG and a couple other places needs to be modified to handle similar issues for other types of calls. This includes fairly comprehensive tests for different ways keywords are handled internally, checking that you get equal results but that keyword splats on the caller side result in distinct objects for keyword rest parameters. Included are benchmarks for keyword argument calls. Brief results when compiled without optimization: def kw(a: 1) a end def kws(**kw) kw end h = {a: 1} kw(a: 1) # about same kw(**h) # 2.37x faster kws(a: 1) # 1.30x faster kws(**h) # 2.19x faster kw(a: 1, **h) # 1.03x slower kw(**h, **h) # about same kws(a: 1, **h) # 1.16x faster kws(**h, **h) # 1.14x faster Notes: Merged:
2020-03-17support builtin for Kernel#cloneS.H
Notes: Merged: Merged-By: nobu <>