あなたが測定するものに注意してください-MJIT対TruffleRuby：2.1倍遅いまたは4.2倍速い

MJITベンチマークの結果を見ましたか？ 彼らは素晴らしいですよね？ MJITは、オプションなしで他のすべての実装を文字通り取り出します。 彼はここ何年どこにいたのですか？ すべて、今はレースオーバー？

ただし、見出しから、物事はそれほど単純ではないことがわかります。 しかし、これらの特定のベンチマークの問題を分析する前に（もちろん、きれいな図までスクロールできます）、ベンチマークの重要な基本的な基礎を考慮する必要があります。

MJIT？ TruffleRuby？ これは何ですか？

MJITは、 GCC開発者のVladimir MakarovによるGithubのRubyの派生物であり、最も人気のあるRubyインタープリターであるCRubyで動的JITコンパイル（ Just In Time Compilation ）を実装しています。 これは最終バージョンではなく、反対に、プロジェクトは開発の初期段階にあります。 有望なベンチマーク結果は2017年6月15日に公開されました。これがこの記事の主な議論の主題です。

TruffleRubyは、Oracle LabsのGraalVMでのRuby実装です。 私の前回の記事「 Ruby plays Go Rumble 」でわかるように、印象的なパフォーマンス結果を示しています。 また、JITを実装し、少しウォームアップする必要がありますが、最終的には前述のベンチマークのRuby 2.0の約8倍高速です。

続行する前に...

私はウラジミールに非常に敬意を表しており、MJITは非常に貴重なプロジェクトだと思います。 実際、これは標準のRubyにJITを導入する数少ない試みの1つかもしれません。 JRubyには長年JITがあり、良好なパフォーマンスを示していますが、この実装は実際には普及していません（これは別の記事のトピックです）。

ベンチマークが実行された方法を批判しますが、これにはいくつかの理由がありますが、私は見逃しました（私は知っているものを指摘しようとします）。 最終的に、ウラジミールは私が世界で行っているよりもずっと長い間プログラミングを行ってきており、明らかに私の言語の実装についてより多くを知っています。

繰り返しますが、ここでは開発者の人格の問題ではなく、正確にベンチマークを実施する方法の問題です。 ウラジミール、それを読んだら、

何を測定しますか？

ベンチマークの結果を見ると、最初に生じるのは「何が測定されたのか」という質問です。ここでの答えは、コードと時間の2つです。

どのコードを測定していますか？

テストが実際にどのコードを測定するかを知ることは重要です。それは私たちにとって本当に関連性があるのですか、それは良いRubyプログラムなのですか これは、特定のRuby実装のパフォーマンスの指標としてベンチマークを使用する場合に特に重要です。

READMEファイルのベンチマークのリストを見ると（そして、 それらの意味の説明までスクロールするか、コードを調べると）、上半分のほぼ全体がマイクロテストであることがわかります。



インスタンス変数への書き込み、定数の読み取り、空のメソッドの呼び出し、whileループなどを測定します。 これらはもっぱらミニチュアテストであり、言語実装者の観点からは興味深いかもしれませんが、実際のRubyのパフォーマンスを実際には反映していません。 一定の検索がRubyアプリケーションのパフォーマンスのボトルネックになる日が最も幸せな日です。 また、コードのどの部分にwhileループが含まれていますか？

ここのコードの大部分（マイクロサンプルを除く）は、私が典型的なRubyコードと呼ぶものとはまったく異なります。 スクリプトとCコードの混合物によく似ています。 多くの場所でクラスは定義されていませんが、従来のEnumerableメソッドの代わりにforループが使用され、場所によってはビットマスクさえあります。

これらの構造の一部は、最適化の結果である可能性があります。 どうやら、それらは一般的な言語テストで使用されています 。 これも危険ですが、それらのほとんどは特定のプラットフォーム（この場合はCRuby）向けに最適化されています。 あるプラットフォームでの最速のRubyコードは、実装の詳細のために他のプラットフォームでははるかに遅くなる可能性があります（たとえば、TruffleRubyは異なるString実装を使用します ）。 当然、このため、他の実装には欠点があります。

ここでの問題はもう少し深いです。一般的なベンチマークにあるものは何であれ、ある種の実装のために最適化されることは避けられませんが、このコードはできるだけ実際のものに近いはずです。 したがって、 Ruby 3×3プロジェクトのベンチマークに非常に満足しています 。これらの新しいテストは、より関連性の高い結果を示しています。

何時に測定しますか？

これは実際に私の記事のお気に入りの部分であり、 間違いなく最も重要です。 私の知る限り、元の記事の時間測定は次のように行われました： /usr/bin/time -v ruby $script 、これはWebアプリケーションで広く使用されているプログラミング言語のベンチマークで私のお気に入りの間違いの1つです。 このことについての詳細は、会議での私のスピーチで読むことができます 。

問題は何ですか？ さて、スクリプトの実行時間（起動、ウォームアップ、実行）のみを測定する場合、全体的な結果に含まれるものを分析しましょう。

• 起動 -Rubyインタープリターの起動やコードの解析など、「有用な」ことを行う前の時間。 参考までに、標準Rubyを使用して空のRubyファイルを実行するには0.02秒、MJITで0.17秒、TruffleRubyで2.5秒かかります （ Substrate VMを使用してこの時間を大幅に削減する計画があります ）。 スクリプトの実行時間を単純に測定する場合、これらの秒は基本的に各ベンチマークに追加されます。
• ウォームアップ -プログラムが最高速度で動作し始める前の時間。 これは、JIT実装にとって特に重要です。 高レベルでは、次のことが発生します。どのコードが最も頻繁に呼び出されるかを確認し、さらに最適化を試みます。 このプロセスには多くの時間がかかりますが、実際の「ピークパフォーマンス」を達成することについては、その最後でしか話せません。 ウォームアップ時に、プログラムはピークパフォーマンスよりもはるかに遅く実行される可能性があります 。 以下に、ウォームアップのタイミングを詳細に分析します。
• 実行 -いわゆる「ピークパフォーマンス」-確立されたリードタイム。 この段階までに、コードのほとんどまたはすべてがすでに最適化されています。 これは、今後コードが実行されるパフォーマンスのレベルです。 理想的には、このパフォーマンスを測定する必要があります。99.99％以上の時間、コードは既に加熱された状態で実行されるためです。

元のベンチマークが開始時間とウォームアップ時間を確認するのは興味深いことですが、これらのインジケーターは、効果が和らげられるように処理されますが、完全には消えません：「JRubyやGraal Rubyとは異なり、MJITは非常に迅速に開始されます。 JRubyとGraal Rubyの可能性を均等にするために、ベンチマークが変更され、Ruby MRI v2.0が各テストで20〜70秒動作するようになりました。

より詳細なテストスキームでは、長期プロセスでパフォーマンスをテストすることが目標であれば、ロード時間とウォームアップ時間は結果に影響を与えないと考えています。

なんで？ たとえば、Webアプリケーションは通常、長期的なプロセスであるためです。 Webサーバーを起動します-そして、それは数時間、数日、数週間働きます。 読み込みとウォームアップは最初の1回だけに費やし、その後サーバーの電源を切るまでプロセスは長時間機能します。 通常のサーバーは、99.99％以上の時間、事前に暖められた状態で実行する必要があります。 これは、ベンチマークが反映すべきであるという事実です。 ロード後の最初の数秒または数分ではなく、サーバーの時間/日/週の間に最高のパフォーマンスを得る方法。

小さな例えは車です。 最短時間（直線）で300キロメートル走行します。 上記の表にある測定値は、最初の約500メートルの測定値と比較できます。 車に乗って、最高速度まで加速し、ピーク時に少しドライブします。 最速の車は最初の500メートルよりも300キロメートル高速ですか？ おそらくない。 （注：私は車が苦手です）。

これはベンチマークにとって何を意味しますか？ 理想的には、負荷とウォームアップ時間を取り除く必要があります。 これは、実際の測定（ウォームアップ時間）を行う前に、最初にベンチマークを数回開始するRubyで作成されたテストライブラリを使用して実行できます。 gemを必要とせず、長期間のテストに適しているため、 独自の小さなライブラリを使用します。

ロードとウォームアップの時間は本当に重要ではありませんか？ 彼らが持っています。 それらは、開発プロセス中に最も顕著に影響します-サーバーの起動、コードのリロード、テストの実施。 これらすべてのタスクについて、負荷とウォームアップ時間を「支払う」必要があります。 また、エンドユーザー向けのUIアプリケーションまたはCLIツールを開発している場合、ロードが頻繁に発生するため、ロードおよびウォームアップ時間が問題になる可能性があります。 ロードバランサーに送信する前にウォームアップすることはできません。 サーバー上のcronjobとしてのプロセスの別の定期的な起動も、ダウンロードとウォームアップに時間を費やすことを強制します。

それでは、負荷とウォームアップ時間を測定することに利点はありますか？ はい、これは上記の状況の1つにとって重要です。 また、 time -vパラメーターを使用した測定では、さらに多くのデータが生成されます。

tobi@speedy $ /usr/bin/time -v ~/dev/graalvm-0.25/bin/ruby pent.rb
Command being timed: "/home/tobi/dev/graalvm-0.25/bin/ruby pent.rb"
User time (seconds): 83.07
System time (seconds): 0.99
Percent of CPU this job got: 555%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:15.12
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 1311768
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 57
Minor (reclaiming a frame) page faults: 72682
Voluntary context switches: 16718
Involuntary context switches: 13697
Swaps: 0
File system inputs: 25520
File system outputs: 312
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0

メモリ使用量、CPU、経過時間（ウォールクロック）などを含む多くの情報を取得します。これは言語の実装を評価するためにも重要であるため、元のベンチマークにも含まれています 。

構成

（最終的に！）ベンチマークに進む前に、「ここに測定が行われたシステムがあります」という必須の部分が必要です。

次のRubyバージョンが使用されました：特別な設定なしでコンパイルされた2017年8月25日のこのコミットの MJIT、graalvm 25および27（詳細は後述）、およびベースレベルとしてのCRuby 2.0.0-p648

これらはすべて、16 GBのメモリとi7-4790プロセッサ（3.6 GHz、4 GHzターボ）を搭載したLinux Mint 18.2デスクトップPC（Ubuntu 16.04 LTSベース）で実行されていました。

tobi@speedy ~ $ uname -a
Linux speedy 4.10.0-33-generic #37~16.04.1-Ubuntu SMP Fri Aug 11 14:07:24 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

デュアルコアラップトップでPolyconf会議のテストを初めて行ったとき、TruffleRubyの結果ははるかに悪かったため、ここでの構成について言及することが特に重要だと思われます。 コアでのCPU使用率がかなり高いため、graalvmは2つのコアを開くなどのメリットがあります。

このリポジトリで、テスト用のスクリプトとその他すべてを確認できます 。

しかし... ...あなたはベンチマークを約束しました、どこにありますか？

申し訳ありませんが、理論はテスト結果自体よりも重要であるように思われましたが、それらは間違いなく論文を説明するのに役立ちます。 最初に、 pent.rbベンチマークを選択した理由と、 graalvmのわずかに古いバージョンで実行した理由を説明します（心配しないでください、現在のバージョンもビジネスにあります）。 そして最後に、グラフと数字が表示されます。

このベンチマークはなぜですか？

まず、元のパフォーマンステストがgraalvm-0.22で実行されました。 graalvm-0.25の現在の（現在の）バージョンで結果を再現しようとすると、それらの多くがすでに最適化されているため（そしてバージョン0.22にはいくつかの本格的なパフォーマンスバグが含まれています）、難しいことがわかりました

パフォーマンスの問題を再現できた唯一のベンチマークはpent.rbであり、異常を最も明確に示しました。 元のベンチマークでは、Ruby 2.0のパフォーマンスの0.33としてマークされています（つまり、3倍遅い）。 しかし、TruffleRubyでの私の経験はすべて、これはおそらく間違っていると言っています。 彼はTruffleRubyで最速だったので、私は彼を除外しませんでしたが、それどころか、 彼は最速でした 。

さらに、これは主に最も典型的なRubyコードではありませんが、私の意見では（クラス、多くのグローバル変数はありません）、each、collect、sort、uniqなどのEnumerableメソッドを使用していますが、同時にビットマスクなどもありませんそのような。 ですから、私はここでも比較的良い候補者を獲得できるように思えました。

元のベンチマークはサイクル内に配置され、数回繰り返されたため、ウォームアップ時間を測定してから、パフォーマンスのピーク時の平均稼働時間を測定できます。

では、なぜ古いバージョンのgraalvm-0.25で実行したのですか？ ベンチマーク用に最適化されたものは何でも、ここでの違いはそれほど明白ではありません。

Benoit Dalousは、このベンチマークのTruffleRubyのウォームアップ時間を最適化したことをツイートしました。そのため、TruffleRubyはMJITよりも3倍高速になりました。 彼は、 pen.rbベンチマークコードが引数の代わりにグローバル変数を使用して値をメソッドに渡すという事実に注意を向けています。


後ほど、新しい改良版を試します。

MJIT対Graalvm-0.25

そのため、私のマシンでは、 TruffleRuby 0.25でのpent.rbベンチマーク（ロード、ウォームアップ、実行時間）の最初の実行には15.05秒かかり、MJITでは7.26秒しかかかりませんでした。 つまり、MJITは2.1倍高速でした。 印象的！

しかし、ロードとウォームアップを考慮しないものは何ですか？ 通訳を開始した後に測定を開始したらどうなりますか？ この場合、コードを60秒間ループで実行してウォームアップし、その後、実際のパフォーマンスを60秒間測定します。 この図は、最初の15回の反復のテスト実行時間を示しています（その後、TruffleRubyは安定します）。


TruffleRubyとMJITのランタイムは徐々に変化します-反復後の反復

ご覧のとおり、 TruffleRubyの起動は非常に遅くなりますが、すぐに速度が上がりますが、MJITはほぼ同じように動作し続けます。 興味深いことに、TrufleRubyはイテレーション6および7で再びスローダウンします。完了するまでにかなりの時間がかかる新​​しい最適化を見つけたか、以前の最適化の制限が無効になったために最適化が解除されました。 その後、TruffleRubyは安定し、最高のパフォーマンスに達します。

ウォームアップ後にベンチマークを開始すると、TruffleRuby 1.75秒およびMJIT-7.33秒で平均時間が得られます。 つまり、この測定方法では 、 TruffleRubyはMJITよりも予想外に4.2倍高速です 。

2.1倍遅くなる代わりに、測定方法を変更するだけで4.2倍速くなりました。

テスト結果を毎秒の反復回数（ips / ipm）として表示するのが好きです。なぜなら、ここではより良いので、グラフがより直感的に出てくるからです。 ランタイムは、TruffleRubyでは1分あたり34.25反復、MJITでは1分あたり8.18反復に変換されます。 それでは、毎分反復として変換されたテスト結果を見てみましょう。 これにより、元の測定方法と新しい方法が比較されます。


スクリプト全体の実行中の1分あたりの反復数（初期時間）および加熱後の反復数

TruffleRubyの結果の大きな違いは、最初の数回の反復中のウォームアップ時間が長いためです。 一方、MJITは非常に安定しています。 この違いは、統計誤差の範囲内にあります。

Ruby 2.0 vs MJIT vs Graalvm-0.25 vs GRAALVM-0.27

したがって、より多くのデータを約束しましたが、ここにあります！ このデータセットには、比較のためのベースラインとしてのCRuby 2.0ベンチマーク、および新しいgraalvmも含まれています。

	初期時間（秒）	IPM開始時間	平均（秒）	ウォームアップ後のipm medium	合計の一部としての標準偏差
CRuby 2.0	12.3	4.87	12.34	4.86	0.43％
トリュフルビー0.25	15.05	3.98	1.75	34.25	0.21％
トリュフルビー0.27	8.81	6.81	1.22	49.36	0.44％
ムジット	7.26	8.26	7.33	8.18	2.39％

各反復の実行時間（秒単位）。 反復が終わったため、CRubyの結果がフェードします

TruffleRuby 0.27は、最初の反復からのMJITよりも高速であることがわかります。これは非常に印象的です。 また、6回目の反復の前後で奇妙な速度低下を回避したため、TruffleRuby 0.25よりもはるかに速くピークパフォーマンスに達しました。 4つの競合他社すべてをウォームアップした後のパフォーマンスを比較すると、一般に新しいバージョンは一般的に高速になりました。


4人のテスト参加者の加熱後の1分あたりの平均反復回数

したがって、TruffleRuby 0.27では、ウォームアップが加速しただけでなく、全体的なパフォーマンスがわずかに向上しました。 現在では、MJITよりも6倍以上高速です。 もちろん、TruffleRubyの開発者がおそらく既存のベンチマークの最適化を実行したため、これは部分的に起こりました。 これは、より良いパフォーマンステストが必要であるという私の主張をもう一度強調しています。

最後の奇妙な図として、1分あたりの反復回数に応じて、スクリプトの合計実行時間（ timeを使用 ）と加熱後のパフォーマンスを比較しています。


スクリプトの合計実行時間（1分あたりの反復回数）とウォームアップ後のパフォーマンスの差

予想通り、CRuby 2は非常に安定しており、TruffleRubyはすぐにかなりまともなパフォーマンスを示しますが、その後数回加速します。 これにより、 異なる測定方法が劇的に異なる結果につながることを確認できます。

おわりに

それでは、どのような結論を出すことができますか？ 読み込みとウォームアップの時間は重要であり、これらの指標がどれほど重要であるか、およびそれらを測定する必要があるかどうかを慎重に検討する必要があります。 Webアプリケーションの場合、ダウンロードとウォームアップの時間は、プログラムがウォームアップ後にパフォーマンスを示す時間の99.99％以上であるため、実質的に無関係です。

計測する時間だけでなく、コードも重要です。 ベンチマークは、結果が可能な限り有意義になるように、可能な限り現実的なものにする必要があります。 インターネットでのある種のarbitrary意的なテストは、ほとんどの場合、アプリケーションの動作に直接関係しません。

常に独自のベンチマークを開始し、どのコードが測定され、どのように行われ、どのように時間がベンチマークに取り込まれるかを確認してください