DOTSスタック：C ++＆C＃

これは、新しいData Oriented Technology Stack（ DOTS ）の簡単な紹介です。 Unityが今日どのように、そしてなぜそのようになったのかを理解するのに役立つ洞察をいくつか共有し、またどの方向に開発を計画しているのかを教えます。 将来的には、UnityブログのDOTSブログに新しい記事を公開する予定です。



C ++について話しましょう。 これは、現代のUnityが記述されている言語です。

ゲーム開発者が何らかの方法で対処しなければならない最も複雑な問題の1つは、これです：プログラマーは、ターゲットプロセッサに明確な命令を含む実行可能ファイルを提供する必要があり、プロセッサがこれらの命令を実行すると、ゲームが開始されます。



パフォーマンスに敏感なコードのその部分では、最終的な指示がどうあるべきかを事前に知っています。 ロジックを一貫して記述できる簡単な方法が必要なだけで、必要な命令が生成されていることを確認します。



C ++言語は、このタスクにはあまり適していないと考えています。 たとえば、ループをベクトル化したいが、コンパイラーがループをベクトル化できない理由は数百万あるかもしれません。 どちらかといえば、それはベクトル化されていますが、明日は、一見些細な変更のためにベクトル化されていません。 すべてのC / C ++コンパイラーがコードのベクトル化を開始することを確認することさえ困難です。



私たちは、すべての希望を満たす「マシンコードを生成する非常に便利な方法」を独自に開発することにしました。 C ++デザインのシーケンス全体を必要な方向にわずかに曲げるために多くの時間を費やすことは可能ですが、私たちが直面するすべてのデザインの問題を完全に解決するツールチェーンの開発にエネルギーを投資する方がはるかに合理的であると判断しました。 ゲーム開発者が解決しなければならないタスクを正確に考慮して開発します。



どの要因を優先しますか？

• パフォーマンス=正しい。 「なんらかの理由でこのループがベクトル化されていない場合、これはカテゴリの状況ではなく、コンパイラエラーである必要があります」と言うことができるはずです。ああ、コードの動作は8倍遅くなりましたが、真の価値、ビジネスの何か！」
• クロスプラットフォーム。 私が作成する入力コードは、ターゲットプラットフォームに関係なく、iOSまたはXboxにかかわらず、まったく同じままである必要があります。
• ソースコードを変更すると、アーキテクチャ用に生成されたマシンコードを簡単に確認できる、整然とした反復ループが必要です。 マシンコードの「ビューア」は、これらすべてのマシン命令が何をするのかを理解する必要がある場合に、トレーニング/説明に役立ちます。
• 安全性 原則として、ゲーム開発者は優先順位のリストで安全性を優先しませんが、Unityの最もクールな機能の1つは、Unity内のメモリを損傷することが非常に難しいことです。 コードを実行するこのようなモードが必要です-そして、ここで何が起こったのかについて大きな文字がメッセージを表示するエラーを明確に修正します：たとえば、読み取り/書き込み時に制限を超えたか、ゼロを逆参照しようとしました。

それで、私たちにとって何が重要なのかを理解したので、次の質問に移りましょう。そのようなマシンコードが生成されるプログラムを書くのはどちらの言語の方が良いでしょうか？ 次のオプションがあるとしましょう：

• 自国語
• CまたはC ++の一部の適応/サブセット
• cのサブセット＃

何、C＃？ パフォーマンスが特に重要な内部ループの場合 はい C＃は完全に自然な選択であり、Unityのコンテキストでは非常に素晴らしいことがたくさんあります。

• これは、ユーザーが現在既に使用している言語です。
• 編集/リファクタリングとデバッグの両方に優れたIDEを備えています。
• C＃を中間ILに変換するコンパイラーが既にあり（MicrosoftのC＃用Roslynコンパイラーについて話している）、独自のコードを作成する代わりに単純に使用することができます。 中間言語をILに変換した豊富な経験があるため、特定のプログラムのコード生成と後処理を実行するだけです。
• C＃には多くのC ++問題がありません（ヘッダー、PIMPLパターン、長いコンパイル時間を含む地獄）

私自身は、C＃でコードを書くのが大好きです。 ただし、パフォーマンスの点では、従来のC＃は最適な言語ではありません。 C＃開発チーム、過去数年にわたって標準ライブラリとランタイムを担当するチームは、この分野で大きな進歩を遂げました。 ただし、C＃で作業している間、データがメモリのどこに保存されるかを正確に制御することはできません。 そして、生産性を高めるために解決する必要があるのはまさにこの問題です。



さらに、この言語の標準ライブラリは、「ヒープ上のオブジェクト」と「他のオブジェクトへのポインターを持つオブジェクト」を中心に構成されています。



同時に、パフォーマンスが重要なコードフラグメントを使用して、標準ライブラリ（Linq、StringFormatter、List、Dictionaryにさよなら）なしでほぼ​​完全に行うことができ、選択操作を禁止します（=クラスなし、構造のみ）、リフレクション、ガベージコレクターと仮想化を無効にします呼び出し、使用が許可されているいくつかの新しいコンテナ（NativeArrayおよびcompany）を追加します。 この場合、C＃言語の残りの要素は既に非常によく見えます。 例については、Arasブログを参照してください。彼はその場しのぎのパストレーサプロジェクトについて説明しています。



このようなサブセットは、ホットサイクルで作業するときに関連するすべてのタスクに簡単に対処するのに役立ちます。 これはC＃の完全なサブセットであるため、通常のC＃と同様に作業できます。 アクセスしようとすると、海外に行くことに関連するエラーを受け取ることができます。優れたエラーメッセージが表示され、デバッガーがサポートされ、コンパイル速度はC ++での作業を忘れてしまいます。 多くの場合、このサブセットはHigh Performance C＃またはHPC＃と呼ばれ​​ます。

バーストコンパイラ：今日は何ですか？

Burstと呼ばれるコードジェネレーター/コンパイラーを作成しました。 Unityバージョン2018.1以降では、「プレビュー」モードのパッケージとして利用できます。 彼と一緒にやるべきことはたくさんありますが、今日は彼に満足しています。



時々、C ++よりも速く動作することがありますが、C ++よりもさらに遅いことがよくあります。 2番目のカテゴリには、パフォーマンスのバグが含まれます。これは、対処できると確信しています。



ただし、単にパフォーマンスを比較するだけでは十分ではありません。 そのようなパフォーマンスを達成するために何をしなければならないかということも重要です。 例：現在のC ++レンダラーからカリングコードを取得し、バーストに移植しました。 パフォーマンスは変更されていませんが、C ++バージョンでは、C ++コンパイラーにベクトル化を行わせるために、信じられないほどのバランスをとる必要がありました。 バーストのあるバージョンは、約4倍コンパクトでした。



正直なところ、「C＃でのパフォーマンスに重要なコードを書き直すべきです」というストーリー全体は、内部Unityチームの誰にもアピールしませんでした。 私たちのほとんどにとって、C ++で作業しているときは、「ハードウェアにより近い」ように聞こえました。 しかし、今状況は変わりました。 C＃を使用して、ソースコードのコンパイルからマシンコードの生成までのプロセス全体を完全に制御します。詳細が気に入らない場合は、それを取得して修正します。



ゆっくりですが確実にC ++からHPC＃にすべてのパフォーマンスクリティカルなコードを移植します。 この言語では、必要なパフォーマンスを達成しやすく、バグを記述しにくく、操作しやすくなります。



バーストインスペクターのスクリーンショットを次に示します。ここでは、さまざまなホットループに対して生成されたアセンブリ命令を簡単に確認できます。







Unityにはさまざまなユーザーがいます。 記憶からarm64命令のセット全体を思い出す人もいれば、コンピューターサイエンスの博士号がなくても熱意を持って作成する人もいます。

エンジンコードの実行に費やされるフレーム時間の一部（通常は90％以上）を加速すると、すべてのユーザーが勝ちます。 Asset Storeパッケージの作成者はHPC＃を採用しているため、Asset Storeパッケージの実行可能コードで作業する割合は本当に加速しています。



上級ユーザーは、HPC＃で独自の高性能コードを作成できるという事実からも恩恵を受けるでしょう。

ポイント最適化

C ++では、プロジェクトのさまざまな部分でコードを最適化する上で、コンパイラにさまざまな妥協の判断を下すことは非常に困難です。 信頼できる最も詳細な最適化は、最適化のレベルをファイルごとに示すことです。



バーストは、このプログラムの唯一のメソッドを入力として受け入れることができるように設計されています。つまり、ホットループへのエントリポイントです。 Burstは、この関数と、それが呼び出すすべてのものをコンパイルします（呼び出される要素は、事前に知られていることが保証されている必要があります。仮想関数または関数ポインターは許可されません）。



バーストはプログラムの比較的小さな部分でのみ動作するため、最適化レベルを11に設定します。バーストはほぼすべての通話サイトを埋め込みます。 組み込みフォームでは関数引数に関するより完全な情報を取得するため、if-checksを削除します。削除しないと削除されません。

一般的なスレッド化問題の解決にどのように役立ちますか？

C ++（およびC＃）は、開発者がスレッドセーフコードを記述するのに特に役立ちません。



典型的なゲームプロセッサに2つ以上のコアが搭載され始めてから10年以上経った今日でも、複数のコアを効率的に使用するプログラムを作成することは非常に困難です。



データレース、非決定論、デッドロックは、マルチスレッドコードの記述を非常に困難にする主な課題です。 このコンテキストでは、「この関数とそれが呼び出すすべてのものがグローバル状態の読み取りまたは書き込みを開始しないようにする」というカテゴリの機能が必要です。 この規則の違反はすべてコンパイラエラーを発生させ、「すべてのプログラマーが順守することを望んでいる規則」のままにしないでください。 バーストはコンパイルエラーをスローします。



Unityユーザー（およびサークル内で同じものを使用）がコードを作成し、その中で計画されているすべてのデータ変換をタスクに分割することを強くお勧めします。 各タスクは「機能的」であり、副作用として無料です。 これは、読み取り専用バッファーと、それが機能する必要がある読み取り/書き込みバッファーを明示的に示します。 他のデータにアクセスしようとすると、コンパイルエラーが発生します。

タスクスケジューラは、タスクの実行中に誰も読み取り専用バッファに書き込まないようにします。 また、タスクの実行中は、読み取りおよび書き込み用に設計されたバッファから誰も読み取らないことを保証します。



これらのルールに違反するタスクを割り当てると、コンパイルエラーが発生します。 レースの状況などの不幸なイベントだけでなく。 エラーメッセージは、バッファーAから読み取る必要があるタスクを割り当てようとしていることを説明しますが、以前にAに書き込むタスクを既に割り当てているため、本当にこれを行うには、前のタスクを依存関係として指定する必要があります。



このような安全メカニズムは、修正される前に多くのバグをキャッチするのに役立ち、したがってすべてのコアの効率的な使用を保証すると考えています。 競合状態またはデッドロックを引き起こすことが不可能になります。 スレッドの数、または他のプロセスの介入によりスレッドが中断された回数に関係なく、結果は確定的であることが保証されています。

スタック全体をマスターする

これらすべてのコンポーネントの最下部に到達できる場合、それらが互いに認識していることを確認することもできます。 たとえば、ベクトル化の失敗の一般的な原因は次のとおりです。コンパイラは、2つのポインターが同じメモリポイントを指すことを保証できません（エイリアス）。 コレクションライブラリを記述しているため、2つのNativeArrayがこのように重複することはありません。また、バーストでこの知識を使用できるため、2つのポインターが1つに向けられる可能性があるという恐怖だけで最適化を拒否しませんメモリの同じ部分。



同様に、 Unity.Mathematics数学ライブラリを作成しました。 バースト彼女は「完全に」知られているバースト（将来）は、math.sin（）のような場合に最適化のオプトアウトを指摘することができます。 Burstの場合、math.sin（）はコンパイルする必要のある通常のC＃メソッドではないため、sin（）の三角法の特性も理解するため、小さなx値に対してsin（x）== x（Burstが独立して証明できる）、テイラー級数の展開で置き換えることができることを理解し、部分的に精度を犠牲にします。 将来的には、バーストは浮動小数点を使用してクロスプラットフォームと設計の決定論を実装することも計画しています-そのような目標は達成可能であると信じています。

ゲームエンジンコードとゲームコードの違いは消去されます。

HPC＃でUnityランタイムコードを記述する場合、ゲームエンジンとゲーム自体は同じ言語で記述されます。 HPC＃に変換したランタイムシステムをソースコードとして配布できます。 誰もが彼らから学び、改善し、自分自身に適応させることができます。 一定レベルの競技場がありますが、ユーザーが書いたよりも優れたパーティクルシステム、ゲーム物理学、またはレンダラーを書くことを妨げるものは何もありません。 内部開発プロセスをユーザー開発プロセスに近づけることで、ユーザーの気分を良くすることができるため、2つの異なるワークフローではなく、単一のワークフローの構築に全力を注ぎます。