Improves 2.6.0-preview1 post (en, ja) #1750
Conversation
JuanitoFatas
force-pushed
the
jf.patch-1
branch
2 times, most recently
from
169ba62 to
f66b178
Compare
| @@ -18,50 +18,51 @@ Ruby 2.6 introduces an initial implementation of JIT (Just-in-time) compiler. | |||
|
|
|||
| JIT compiler aims to improve performance of any Ruby program execution. | |||
| Unlike ordinary JIT compilers for other languages, Ruby's JIT compiler does JIT compilation in a unique way, which prints C code to a disk and spawns common C compiler process to generate native code. | |||
| See also: https://github.com/vnmakarov/ruby/tree/rtl_mjit_branch#mjit-organization | |||
| See also: [Vladimir Makarov's mjit-organization branch](https://github.com/vnmakarov/ruby/tree/rtl_mjit_branch#mjit-organization). | |||
There was a problem hiding this comment.
There is no mjit-organization "branch", it's just a section in the README.
So maybe See also: [MJIT organization by Vladimir Makarov]?
|
|
||
| `binding`のソースコード上の位置を `__FILE__` と `__LINE__` の二要素配列として返します。従来でも `eval("[__FILE__, __LINE__]", binding)` とすることでこれらの情報は得られましたが、将来的に `Kernel#eval` はbindingのソースコード行を無視する変更を予定しているため [Bug #4352]、この新しいメソッドを用いることが今後は推奨されます。 | ||
|
|
||
| * `Kernel#system` の失敗時に、`false`を返す代わりに例外を上げさせる :exception オプションを追加 [Feature #14386] |
There was a problem hiding this comment.
:exception is better, isn't it?
| * `Random.bytes` の追加 [Feature #4938] | ||
| * `Binding#source_location` の追加 [Feature #14230] | ||
|
|
||
| `binding`のソースコード上の位置を `__FILE__` と `__LINE__` の二要素配列として返します。従来でも `eval("[__FILE__, __LINE__]", binding)` とすることでこれらの情報は得られましたが、将来的に `Kernel#eval` はbindingのソースコード行を無視する変更を予定しているため [Bug #4352]、この新しいメソッドを用いることが今後は推奨されます。 |
| Ruby 2.5ではブロック渡しの性能が改善されましたが [Feature #14045]、加えてRuby 2.6では渡されたブロックの呼び出しも改善されました。 | ||
| マイクロベンチマークにおいては2.6倍高速化されています。 | ||
|
|
||
| ## その他の注目すべき 2.5 からの変更点 | ||
|
|
||
| * $SAFE はプロセスグローバルで扱われることになると共に、0以外を設定した後に0に戻せるようになりました [Feature #14250] | ||
| * `$SAFE` はプロセスグローバルで扱われることになると共に、`0`以外を設定した後に0に戻せるようになりました [Feature #14250] |
|
|
||
| The main purpose of this JIT release is to provide a chance to check if it works for your platform and to find out security risks before the 2.6 release. | ||
| Currently JIT compiler is supported only when Ruby is built by gcc or clang and the compiler is available on runtime. Otherwise you can't use it for now. | ||
|
|
||
| As of 2.6.0-preview1, we're just preparing infrastructure for JIT and very few optimizations are implemented. | ||
| You can measure some of potential improvements in micro benchmarks with this release, but it is NOT ready for benchmarking final performance of Ruby's JIT compiler, especially for larger programs like Rails applications. | ||
| As of 2.6.0-preview1, we're just preparing infrastructure for JIT and very few optimizations are implemented. You can measure some of potential improvements in micro benchmarks with this release, but it is NOT ready for benchmarking final performance of Ruby's JIT compiler, especially for large programs like Rails applications. | ||
|
|
||
| We're going to implement method iniling in JIT compiler, which is expected to increase Ruby's performance in order of magnitude. |
There was a problem hiding this comment.
iniling => inlining
which is expected to increase Ruby's performance by an order of magnitude.
Personally, I would just simplify to "significantly", it's too hard to predict. No inlining is an optimization barrier, but it doesn't tell how well the larger compilation will optimize better.
cc @k0kubun
There was a problem hiding this comment.
Personally, I would just simplify to "significantly", it's too hard to predict.
I'm okay with it. Thank you for the correction.
No inlining is an optimization barrier, but it doesn't tell how well the larger compilation will optimize better.
Sorry, I couldn't understand what you want to mean here. Could you rephrase?
As you know, the background of expectation is that inlining allows to widen the scope to be optimized by C compiler. Do you mean this should describe about it?
There was a problem hiding this comment.
Sorry, I wrote that sentence in a rather unclear way.
Inlining enables other optimizations: it makes it possible to compile a wider scope/more code and more optimizations might trigger on that larger code.
But in general it's hard to predict how much performance inlining gains, because the gains essentially depend on other optimizations (if they trigger) and how much the heuristic decides to inline of course.
By that sentence I was trying to justify significantly is safe but an order of magnitude feels like it could be wrong. At least, I expect inlining alone will not gain that much. I expect quite a few other tweaks in the current MJIT will be needed to achieve a 10x speedup on general Ruby code.
As an extreme example, inlining on MJIT microbenchmarks without method/block calls cannot gain anything.
Do you mean this should describe about it?
No, I think this news should stay simple, so I was just suggesting changing by an order of magnitude to significantly.
There was a problem hiding this comment.
That makes sense. Totally agreed.
@JuanitoFatas Could you include his suggestion too?
- fix typos - wraps code in code tags - list item description - linkify Vladimir's MJIT branch
JuanitoFatas
force-pushed
the
jf.patch-1
branch
from
2bddf52 to
41ccb4f
Compare
|
All reviews addressed, thanks everyone! Ready to merge. |
This PR:
Screenshots
English Before
English After
Japanese before
Japanese After
Ruby Happy birthday! 🎂