私の友人のAras は最近 、C ++、C＃、Unity Burstコンパイラなど、さまざまな言語で同じレイトレーサーを作成しました。 もちろん、C＃がC ++よりも遅いと予想するのは自然ですが、Monoが.NET Coreよりも非常に遅いことは興味深いように思えました。

彼の公開された指標は貧弱でした：

• C＃（.NET Core）：Mac 17.5 Mray / s、
• C＃（Unity、Mono）：Mac 4.6 Mray / s、
• C＃（Unity、IL2CPP）：Mac 17.1 Mray / s

何が起こっているのかを確認し、改善できる場所を文書化することにしました。

このベンチマークとこの問題の調査の結果、改善が可能な3つの領域が見つかりました。

• 最初に、デフォルトのMono設定を改善する必要があります。ユーザーは通常、設定を構成しないためです。
• 第二に、MonoのLLVMコード最適化バックエンドに世界を積極的に導入する必要があります
• 第三に、いくつかのMonoパラメーターのチューニングを改善しました。

このテストの基準点は、マシンで実行されたレイトレーサーの結果であり、ハードウェアが異なるため、数値を比較することはできません。

私の自宅のiMac for .NET Coreでの結果は次のとおりです。

作業環境	結果、MRay /秒
.NET Core 2.1.4、 dotnet run debug build	3.6
.NET Core 2.1.4リリースビルドdotnet run -c Release	21.7
mono Maths.exe 、 mono Maths.exe	6.6
LLVMおよびfloat32を備えたバニラモノ	15.5

この問題を研究する過程で、いくつかの問題を発見しました。修正後、次の結果が得られました。

作業環境	結果、MRay /秒
LLVMおよびfloat32を備えたモノ	15.5
LLVM、float32、固定インラインを備えた高度なMono	29.6

全体像：


単にLLVMとfloat32を適用するだけで、浮動小数点コードのパフォーマンスをほぼ2.3倍向上させることができます。 そして、これらの実験の結果としてMonoに追加したチューニング後、標準のMonoに比べて生産性を4.4倍向上させることができます。Monoの将来のバージョンのこれらのパラメーターはデフォルトのパラメーターになります。

この記事では、調査結果について説明します。

32ビットおよび64ビットのフロート

Arasは、計算の主要部分に32ビットの浮動小数点数を使用します（C＃ではfloat型、.NETではSystem.Single型）。 Monoでは、ずっと前にミスを犯しました。すべての32ビット浮動小数点計算は64ビットとして実行され、データはまだ32ビット領域に保存されていました。

今日、私の記憶は以前ほど鮮明ではなく、なぜこのような決定をしたのかを正確に思い出すことができません。

私はそれが当時のトレンドやアイデアに影響されたとしか考えられません。

その後、フロートコンピューティングの精度が向上しました。 たとえば、Intel x87プロセッサは、オペランドが2倍の場合でも、浮動小数点の計算に80ビット精度を使用したため、ユーザーはより正確な結果を得ることができました。

当時、以前のプロジェクトの1つであるGnumericスプレッドシートでは、統計関数がExcelよりも効率的に実装されていたという考えも関連していました。 したがって、多くのコミュニティは、精度を高めたより正確な結果を使用できるという考えを十分に受け入れています。

Mono開発の初期段階では、すべてのプラットフォームで実行される数学演算のほとんどは、入力で2倍しか受け取ることができませんでした。 32ビットバージョンがC99、Posix、およびISOに追加されましたが、当時は業界全体で広く利用できませんでした（たとえば、 sinfはsinのfloatバージョン、 fabsfはfabsfのバージョンなど）。

つまり、2000年代初期は楽観的な時代でした。

アプリケーションは計算時間の増加に大きな代償を払っていましたが、Monoは主にHTTPページと一部のサーバープロセスを提供するデスクトップLinuxアプリケーションに使用されていたため、浮動小数点速度は日常的に発生する問題ではありませんでした。 一部の科学的ベンチマークでのみ顕著になり、2003年には.NETで開発されることはほとんどありませんでした。

今日、ゲーム、3Dアプリケーション、画像処理、VR、AR、機械学習により、浮動小数点演算がより一般的なタイプのデータになりました。 トラブルは単独では発生せず、例外もありません。 Floatは、ほんの2、3の場所でコードで使用されているフレンドリーなデータ型ではなくなりました。 彼らは雪崩に変わり、そこから隠れ場所はありません。 それらの多くがあり、それらの配布を止めることはできません。

ワークスペースフラグfloat32

したがって、数年前に、他のすべての場合と同様に、32ビット操作を使用して32ビットフロート操作を実行するためのサポートを追加することにしました。 ワークスペースのこの機能を「float32」と呼びました。 Monoでは、作業環境でオプション--O=float32追加することで有効になり、Xamarinアプリケーションでは、このパラメーターはプロジェクト設定で変更されます。

基本的にモバイルデバイスはまだ強力ではないため、この新しいフラグはモバイルユーザーに好評でした。精度を上げるよりも速くデータを処理する方が望ましいためです。 モバイルユーザーは、LLVM最適化コンパイラとfloat32フラグを同時にオンにすることをお勧めします。

このフラグは数年間実装されていますが、ユーザーの不快な驚きを避けるために、このフラグをデフォルトにしませんでした。 しかし、標準の64ビットの動作が原因で驚きが生じるケースに遭遇し始めました。Unityユーザーが提出したこのバグレポートを参照してください。

ここでfloat32でMono float32を使用float32 。進行状況はhttps://github.com/mono/mono/mono/issues/6985で追跡できます 。

それまでの間、友人のArasのプロジェクトに戻りました。 彼は.NET Coreに追加された新しいAPIを使用しました。 .NET Coreは常に32ビットの浮動小数点演算を32ビットの浮動小数点演算として実行していましたが、 System.Math APIはプロセス内でfloatからdoubleへの変換を引き続き実行します。 たとえば、float値の正弦関数を計算する必要がある場合、唯一のオプションはMath.Sin (double)を呼び出すことであり、floatからdoubleに変換する必要があります。

これを修正するために、単精度浮動小数点演算を含む新しいタイプのSystem.MathFが.NET Coreに追加されましたが、この[System.MathF] をMonoに移植しただけです。

64ビットから32ビットフロートへの移行により、パフォーマンスが大幅に向上します。これは次の表からわかります。

作業環境とオプション	Mrays /秒
System.Mathを備えたモノ	6.6
System.Mathと-O=float32	8.1
System.MathFを備えたモノ	6.5
System.MathFおよび-O=float32	8.2

つまり、このテストでfloat32を使用するとパフォーマンスが本当に向上し、MathFの効果はほとんどありません。

LLVMセットアップ

この調査の過程で、Fast JIT Monoコンパイラーはfloat32サポートしていますが、このサポートをLLVMバックエンドに追加していないことがfloat32 。 つまり、LLVMを備えたMonoは、floatからdoubleへのコストのかかる変換をまだ実行していました。

そのため、ZoltanはLLVMコード生成エンジンにfloat32サポートを追加しました。

それから彼は、私たちのインライナーがLLVMに使用されるものと同じヒューリスティックをFast JITに使用することに気付きました。 Fast JITを使用する場合、JIT速度と実行速度のバランスを取る必要があるため、埋め込みコードの量を制限してJITエンジンの作業量を削減しました。

しかし、MonoでLLVMを使用することに決めた場合は、コードを可能な限り高速にしようとするため、それに応じて設定を変更しました。 現在、このパラメーターはMONO_INLINELIMIT環境MONO_INLINELIMITを使用して変更できますが、実際にはデフォルト値に書き込む必要があります。

変更されたLLVM設定での結果は次のとおりです。

作業環境とオプション	Mrays /秒
System.Mathでモノラル--llvm -O=float32	16.0
System.Mathのモノラル--llvm -O=float32 、定数ヒューリスティック	29.1
System.MathFを--llvm -O=float32 Mono --llvm -O=float32 、定数ヒューリスティック	29.6

次のステップ

これらのすべての改善を行うのに少しの努力が必要でした。 これらの変更は、Slackでの定期的な議論によって導かれました。 System.MathFをMonoに移植するために、ある夕方になんとか時間を作ることさえできました。

Arasレイトレーサーコードは、自給自足であり、実際のアプリケーションであり、合成ベンチマークではなかったため、研究の理想的な対象となりました。 生成するバイナリコードを研究するために使用できる他の同様のソフトウェアを見つけ、最適なデータをLLVMに送信して、その作業の最適なパフォーマンスを確保する必要があります。

また、LLVMを更新し、新しく追加された最適化を使用することも検討しています。

別注

余分な精度には素晴らしい副作用があります。 たとえば、Godotエンジンのプールリクエストを読んで、コンパイル時に浮動小数点演算の精度をカスタマイズ可能にするかどうかについて活発な議論があることがわかりました（ https://github.com/godotengine/godot/pull/17134 ）。

ゲームには32ビットの浮動小数点演算で十分だと信じていたので、なぜこれが誰かに必要なのかとJuanに尋ねました。

フアンは、一般的な場合、フロートはうまく機能すると説明しましたが、ゲームの中心から「離れる」、たとえばゲームの中心から100キロメートル移動すると、計算エラーが蓄積し始め、興味深いグラフィックの不具合につながる可能性があります。 この問題の影響を軽減するためにさまざまな戦略を使用できますが、そのうちの1つは精度を高めて作業することであり、そのためにパフォーマンスに対して支払う必要があります。

会話の直後、Twitterフィードで、この問題を実証する投稿を見ました： http : //pharr.org/matt/blog/2018/03/02/rendering-in-camera-space.html

問題は以下の画像に示されています。 ここでは、 pbrt-v3-scenes ** パッケージのスポーツカーモデルを示します 。 カメラとシーンの両方が原点に近く、すべてが素晴らしく見えます。


** （ 森康俊の 著者 。）

次に、原点からxx、yy、zzでカメラとシーンを200,000ユニット移動します。 マシンのモデルが非常に断片化されていることがわかります。 これは、精度の浮動小数点数が不足しているためです。


さらに5×5×5回、原点から100万単位移動すると、モデルは崩壊し始めます。 マシンは、おもしろくて恐ろしい、それ自体の非常に粗雑なボクセル近似に変わります。 （キアヌは質問をしました：Minecraftは、すべてが原点から非常に遠くにレンダリングされているという理由だけで、立方体ですか？）


** （ 彼の美しいモデルで私たちがしたことについて、 森康敏 に謝罪し ます。）