Rewrite Kernel#tap with Ruby

[k0kubun]

because Ruby is faster than C.

$ benchmark-driver -v --rbenv 'before;after' benchmark/kernel_tap.yml benchmark/vm_symbol_block_pass.rb --repeat-count=4
before: ruby 2.8.0dev (2020-07-03T06:16:55Z master 01776ca) [x86_64-linux]
after: ruby 2.8.0dev (2020-07-03T07:14:40Z builtin-tap be549c7) [x86_64-linux]
Calculating -------------------------------------
                         before       after
          kernel_tap    22.130M     29.958M i/s -     20.000M times in 0.903731s 0.667597s
vm_symbol_block_pass      1.439       1.485 i/s -       1.000 times in 0.694709s 0.673524s

Comparison:
                       kernel_tap
               after:  29958213.1 i/s
              before:  22130488.0 i/s - 1.35x  slower

             vm_symbol_block_pass
               after:         1.5 i/s
              before:         1.4 i/s - 1.03x  slower

[shyouhei]

Second thought you might also want to do this for Kernel#then.

[benoittgt]

Related explanation submitted by @k0kubun on twitter:

I thought a block must be inlinable over methods which are currently written in C with future JIT, but it's actually hard to update (for inlining block) a part of C code from JIT. My current plan is to mix C and Ruby for methods like #each, but then I noticed #tap was too easy :)

😊

[k0kubun]

Second thought you might also want to do this for Kernel#then.

Absolutely 🙂 I'll prepare another PR to see CI results for it separately though.

[ruurd]

because Ruby is faster than C.

Lies. Damned lies. Statistics. Did you find out WHY it is faster?

[simi]

Lies. Damned lies. Statistics. Did you find out WHY it is faster?

It is not meant it is faster in general, but in this case of Kernel#tap implementation. Stats are in original post.

[ruurd]

WHY is it faster. That is the question. Concluding that Ruby is faster here is uninteresting. Do a root cause analysis. Then we learn something perhaps.

[simi]

Everything is written in this thread actually.