From: takashikkbn@...
Date: 2017-10-19T08:23:30+00:00
Subject: [ruby-core:83385] [Ruby trunk Feature#12589] VM performance improvement proposal
Issue #12589 has been updated by k0kubun (Takashi Kokubun).
> Saving stack insns is what we discussed with Koichi at RubyKaigi and after that. I promised to investigate another way of RTL generation through stack insns. I am now realizing that it might be a better way than generating RTL directly from MRI nodes because
>
> it will not break existing applications working with stack insns
Oh, I didn't know that plan. I like that approach.
> stack insns could be a stable existing interface to VM. RTL will be definitely changing as some new optimizations are implemented. So RTL will be unstable for long time and probably there is no sense to open RTL to Ruby programmers at all. Actually a similar approach is used by JVM: bytecode as an interface with JVM and another internal IR for JIT which is not visible for JVM users.
Good to know. That sounds a good way to introduce RTL insns for easy maintenance.
> Slowdown of nodes->stack insns->RTL path might be negligible in comparison with nodes->RTL path. And slowdown is a major disadvantage for stack insn -> RTL path.
I agree that the slowdown is negligible. For major disadvantage, compared to YARV-MJIT, implementation and debugging would be more complex.
So maintainability and performance would be trade-off. Thus I think we need to decide approach comparing differences in implementation complexity and performance difference.
> An alternative approach can be useful but it might be a waste of your time at the end. But any performance work requires a lot alternative implementations (e.g. the current global RA in GCC was actually one of my seven different RA implementations), some temporary solutions might become permanent. who knows.
As I'm hacking Ruby as not work but just hobby to enjoy improving my Ruby core understanding, so it wouldn't be a waste of time even if I end up with developing seven different JIT implementations :)
> So the solution would be implementing analysis on RTL to use double values in JITted code of a method to avoid double->flonum and flonum->double conversions. RTL is a good fit to this.
Question for my better understanding: Do you mean GCC and Clang can't optimize double<->flonum conversion well even if all necessary code is inlined? If so, having special effort to optimize it in Ruby core makes sense. I'm not sure why we can't do that with stack-based instructions or just in JIT-ed C code generation process. Can't we introduce instruction specialization (to avoid double<->flonum conversion, not sure its details) without having all instructions as register-based?
> Basic type inference could be another example for RTL necessity. I could find other examples.
Type inference at RTL instructions is interesting topic which I couldn't understand well from discussion with you at RubyKaigi. I'm looking forward to seeing the example!
----------------------------------------
Feature #12589: VM performance improvement proposal
https://bugs.ruby-lang.org/issues/12589#change-67346
* Author: vmakarov (Vladimir Makarov)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
Hello. I'd like to start a big MRI project but I don't want to
disrupt somebody else plans. Therefore I'd like to have MRI
developer's opinion on the proposed project or information if somebody
is already working on an analogous project.
Basically I want to improve overall MRI VM performance:
* First of all, I'd like to change VM insns and move from
**stack-based** insns to **register transfer** ones. The idea behind
it is to decrease VM dispatch overhead as approximately 2 times
less RTL insns are necessary than stack based insns for the same
program (for Ruby it is probably even less as a typical Ruby program
contains a lot of method calls and the arguments are passed through
the stack).
But *decreasing memory traffic* is even more important advantage
of RTL insns as an RTL insn can address temporaries (stack) and
local variables in any combination. So there is no necessity to
put an insn result on the stack and then move it to a local
variable or put variable value on the stack and then use it as an
insn operand. Insns doing more also provide a bigger scope for C
compiler optimizations.
The biggest changes will be in files compile.c and insns.def (they
will be basically rewritten). **So the project is not a new VM
machine. MRI VM is much more than these 2 files.**
The disadvantage of RTL insns is a bigger insn memory footprint
(which can be upto 30% more) although as I wrote there are fewer
number of RTL insns.
Another disadvantage of RTL insns *specifically* for Ruby is that
insns for call sequences will be basically the same stack based
ones but only bigger as they address the stack explicitly.
* Secondly, I'd like to **combine some frequent insn sequences** into
bigger insns. Again it decreases insn dispatch overhead and
memory traffic even more. Also it permits to remove some type
checking.
The first thing on my mind is a sequence of a compare insn and a
branch and using immediate operands besides temporary (stack) and
local variables. Also it is not a trivial task for Ruby as the
compare can be implemented as a method.
I already did some experiments. RTL insns & combining insns permits
to speed the following micro-benchmark in more 2 times:
```
i = 0
while i<30_000_000 # benchmark loop 1
i += 1
end
```
The generated RTL insns for the benchmark are
```
== disasm: #<ISeq:<main>@while.rb>======================================
== catch table
| catch type: break st: 0007 ed: 0020 sp: 0000 cont: 0020
| catch type: next st: 0007 ed: 0020 sp: 0000 cont: 0005
| catch type: redo st: 0007 ed: 0020 sp: 0000 cont: 0007
|------------------------------------------------------------------------
local table (size: 2, temp: 1, argc: 0 [opts: 0, rest: -1, post: 0, block: -1, kw: -1@-1, kwrest: -1])
[ 2] i
0000 set_local_val 2, 0 ( 1)
0003 jump 13 ( 2)
0005 jump 13
0007 plusi <callcache>, 2, 2, 1, -1 ( 3)
0013 btlti 7, <callcache>, -1, 2, 30000000, -1 ( 2)
0020 local_ret 2, 0 ( 3)
```
In this experiment I ignored trace insns (that is another story) and a
complication that a integer compare insn can be re-implemented as a
Ruby method. Insn bflti is combination of LT immediate compare and
branch true.
A modification of fib benchmark is sped up in 1.35 times:
```
def fib_m n
if n < 1
1
else
fib_m(n-1) * fib_m(n-2)
end
end
fib_m(40)
```
The RTL code of fib_m looks like
```
== disasm: #<ISeq:fib_m@fm.rb>==========================================
local table (size: 2, temp: 3, argc: 1 [opts: 0, rest: -1, post: 0, block: -1, kw: -1@-1, kwrest: -1])
[ 2] n<Arg>
0000 bflti 10, <callcache>, -1, 2, 1, -1 ( 2)
0007 val_ret 1, 16
0010 minusi <callcache>, -2, 2, 1, -2 ( 5)
0016 simple_call_self <callinfo!mid:fib_m, argc:1, FCALL|ARGS_SIMPLE>, <callcache>, -1
0020 minusi <callcache>, -3, 2, 2, -3
0026 simple_call_self <callinfo!mid:fib_m, argc:1, FCALL|ARGS_SIMPLE>, <callcache>, -2
0030 mult <callcache>, -1, -1, -2, -1
0036 temp_ret -1, 16
```
In reality, the improvement of most programs probably will be about
10%. That is because of very dynamic nature of Ruby (a lot of calls,
checks for redefinition of basic type operations, checking overflows
to switch to GMP numbers). For example, integer addition can not be
less than about x86-64 17 insns out of the current 50 insns on the
fast path. So even if you make the rest (33) insns 2 times faster,
the improvement will be only 30%.
A very important part of MRI performance improvement is to make calls
fast because there are a lot of them in Ruby but as I read in some
Koichi Sasada's presentations he pays a lot of attention to it. So I
don't want to touch it.
* Thirdly. I want to implement the insns as small inline functions
for future AOT compiler, of course, if the projects described
above are successful. It will permit easy AOT generation of C code
which will be basically calls of the functions.
I'd like to implement AOT compiler which will generate a Ruby
method code, call a C compiler to generate a binary shared code
and load it into MRI for subsequent calls. The key is to minimize
the compilation time. There are many approaches to do it but I
don't want to discuss it right now.
C generation is easy and most portable implementation of AOT but
in future it is possible to use GCC JIT plugin or LLVM IR to
decrease overhead of C scanner/parser.
C compiler will see a bigger scope (all method insns) to do
optimizations. I think using AOT can give another 10%
improvement. It is not that big again because of dynamic nature
of Ruby and any C compiler is not smart enough to figure out
aliasing for typical generated C program.
The life with the performance point of view would be easy if Ruby
did not permit to redefine basic operations for basic types,
e.g. plus for integer. In this case we could evaluate types of
operands and results using some data flow analysis and generate
faster specialized insns. Still a gradual typing if it is
introduced in future versions of Ruby would help to generate such
faster insns.
Again I wrote this proposal for discussion as I don't want to be in
a position to compete with somebody else ongoing big project. It
might be counterproductive for MRI development. Especially I don't
want it because the project is big and long and probably will have a
lot of tehcnical obstacles and have a possibilty to be a failure.
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>