Unity 3Dのスクリプトの未来

最近、UnityでのWebGLサポートに関する記事を書きました 。 その中で、新しいIL2CPPテクノロジーを使用してWebGLでスクリプトがどのように機能するかについて簡単に説明しました。 ただし、IL2CPPはWebGLの新しいスクリプティングソリューションよりもはるかに大きなものであり、多くのプラットフォームでリリースされる独自の.Net Runtimeの高性能実装です。



しかし、未来に飛び込む前に、現在について語る価値があります。

今日のUnityのスクリプト

モノ （およびWindowsストアとWindows Phoneアプリケーション用のWinRT ）を使用して、UnityにC＃の使いやすさ、サードパーティライブラリへのアクセス、実質的にバイナリパフォーマンスをもたらします。 しかし、いくつかの困難があります。



-C＃ランタイムのパフォーマンスは、C / C ++にまだ劣っています

-.Netランタイム言語とランタイムの最新かつ最高の機能は、 現在Unityで使用されているMonoのバージョンではサポートされていません

-約23のプラットフォームとアーキテクチャオプションを使用すると、コードを転送し、同じレベルで品質を維持するために多くの労力が必要になります。

-ガベージコレクションは実行の遅延を引き起こす可能性があります







過去数年間、私たちは常にこれらすべてに対処する方法について考えてきました。 同時に、WebGLのスクリプトサポートの分野で研究が進行中です。 両方向に移動すると、1つのアプローチに統合されました。



問題の規模を認識して、私たちはそれを解決するさまざまな方法で実験を始めました。 有望な人もいれば、そうでない人もいました。 しかし、最終的に、問題を解決する革新的な方法を発見しました。



これはIL2CPPです。

IL2CPP：簡単な紹介

IL2CPPは、 Ahead of Time（AOT）コンパイラーと仮想マシン（VM）の2つの部分で構成されています



これらは、.NetやMonoに似たCommon Language Infrastructureの実装です。 Unityのスクリプトの現在の実装と互換性があります。



現在の実装との主な違いは、IL2CPPコンパイラがアセンブリをC ++ソースコードに変換することです。 次に、プラットフォームの標準C ++コンパイラを使用して、ネイティブバイナリを作成します。



コードは、IL2CCP VMが提供する追加サービス（ガベージコレクター、メタデータ、プラットフォーム固有のリソースなど）と同時に実行されます。

IL2CPPの利点

上記の各困難と、IL2CPPがそれをどのように処理するかを見てみましょう。

性能

IL2CPPでは、使いやすさとコーディング速度をC ++パフォーマンスと組み合わせることを目指しています。



これにより、現在のスクリプトプロセスの速度を維持し、生産性を即座に向上させることができます。 複雑なスクリプトを使用した一部のテストでは、実行速度が2〜3倍に向上しました。 このパフォーマンスの向上は、いくつかの理由で発生します。



-C ++コンパイラとリンカーは、以前はアクセスできなかった多数の最適化方法を提供します。

-コードは、速度とサイズの両方について静的分析の対象となります

-Unity指向のスクリプトランタイムの最適化



IL2CPPの作業はまだ完了していませんが、この生産性の早期の向上は、プロジェクトの素晴らしい将来を明確に示しています。

.Netを更新する

ランタイムを更新するリクエストを非常に頻繁に受け取ります。 近年、.Netは非常に急速に進化しており、Unityは現在、C＃コンパイラとサードパーティライブラリの両方で.NET 2.0 / 3.5時代の機能のみをサポートしています。 多くのユーザーが、コードとサードパーティライブラリの両方の新機能へのアクセスをリクエストしています。



IL2CPPが古くなると、Mono C＃コンパイラ、ベースクラスライブラリ、およびエディターのランタイムのバージョンを更新します（スクリプト開発の速度を維持するため、エディターはIL2CPPに変換されません）。 これら2つのプロセスの組み合わせにより、最新バージョンの.NetがUnityに導入されます。



マイクロソフトと協力して品質と安定性を保証し、現在および将来の.Net機能をUnityに追加していることは注目に値します。

移植性とサポート

これはUnityの内部問題のように思えるかもしれませんが、あなたにも関係しています。 Mono仮想マシンには、特定のプラットフォームとアーキテクチャに固有の大量のコードが含まれています。 Unityを新しいプラットフォームに移植するとき、このプラットフォームのMono VMの移植とサポートに多大な労力を費やします。 一部の機能（およびエラー）は、特定のプラットフォームにのみ存在する場合があります。 これは、Unityが提供しようとしている値、つまりプラットフォーム間でのコンテンツの転送のしやすさに影響します。



IL2CPPは、この問題をいくつかの方法で解決します。



-コードはC ++に変換され、このアーキテクチャ固有のマシン固有のコードではありません。 特定のアーキテクチャごとにコード生成を移植およびサポートするコストが大幅に削減されます

-新機能とバグ修正の開発は著しく加速されています。 私たちにとって、アーキテクチャ固有のコードを選択する数日は、C ++を編集する数分に置き換えられます。 新しい機能とバグ修正は、すべてのプラットフォームですぐに利用できます。 IL2CPPの現在のバージョンは、非常に迅速に新しいプラットフォームに移行しています。



これに加えて、プラットフォーム固有またはアーキテクチャ固有のコンパイラは通常、単一のコードジェネレータよりもはるかに最適化されています。 これにより、C ++コンパイラの開発に費やしたすべての努力を、社内で再発明することなく再利用できます。

ごみ収集

IL2CPPは、特定のガベージコレクターに関連付けられているのではなく、特別なAPIを介してそれらを接続します。 IL2CPPの現在のバージョンでは、さまざまなオプションを検討していますが、改良版のlibgcを使用しています。 同時に、IL2CPPコンパイラで実行された分析を使用して、GCからの圧力を減らす可能性を調査しています。



現時点ではこれ以上言うことはありませんが、研究は進行中です。 これはあなたにとって重要であることがわかっているので、引き続き作業を続け、今後のエントリでお知らせします。 ガベージコレクションのコンテキストでは、IL2CPPに関係なく、Unity 5では割り当てのないAPIがはるかに多く表示されることに注意してください。

IL2CPPではないもの

IL2CPPは、.NetまたはMono環境全体を再作成する試みではありません。 MonoのC＃コンパイラを引き続き使用します（将来的にはRoslynも可能です）。 引き続きMonoクラスライブラリを使用します。 Mono AOTと互換性のある現在利用可能なすべての機能とサードパーティライブラリは、IL2CPPで動作します。 Mono VMとAOTコンパイラのみを置き換え、 すばらしいMonoプロジェクトを引き続き使用します。

IL2CPPはいつ試せますか？

この瞬間までに、IL2CPPを試してみる機会が私たちと同じくらいあなたを興奮させ、あなたが疑問に思っていることを願っています。 IL2CPPの初期バージョンは、Unity 5のWebGLサポートの一部になります。



WebGLに続き、他のプラットフォーム向けにIL2CPPの開発を続けます。 実際、サポートしている多くのプラットフォームの実装が既にあります。 今年は少なくとももう1つのプラットフォームをリリースする予定です。 現時点では、iOSをIL2CPPをサポートする次のプラットフォームにする予定です。



Mono環境の計画的なアップグレードは、IL2CPPがより多くのプラットフォームでサポートされ、少し古くなった後に行われます。



セキュリティ上の制限により、IL2CPPをサポートしないプラットフォームはWebPlayerのみです。 前述のように、エディターは引き続きMonoで動作します。



IL2CPPランタイムの動作を今すぐ確認できます。 以前に投稿した2つのWebGLデモは 、それに関する作業です。

次は？

IL2CPPには引き続き取り組みます：新機能の追加、コード生成の最適化、バグの修正、新しいプラットフォームのサポートの追加。 作業が進むにつれて、より詳細な記事を公開し、 フォーラムで引き続き議論します。



Unityスクリプトチーム。



開発者の回答から英語のコメントの質問への小さな追加とUnityフォーラムの特別なトピック ：



「仮想マシン」という用語は、少し誤解を招く可能性があります。 実際、実際の仮想マシンは存在せず、すべてがバイナリコードになりますが、実行時に利用可能な多くの機能があり、この場合は仮想マシンと呼ばれるシステムサービスやガベージコレクションなど、マネージコードに必要な機能を実装します。



***



C ++でスクリプトを記述することは、IL2CPPの公式の目標ではなく、近い将来、この種の決定は行われませんが、決定の副作用として将来発生する可能性があります。



***



ソースコードは、同様の機会について長い間議論しており、まだ同様の決定を下すまで、公開されません。 ソースを公開することには、私たちにとっての利点と欠点の両方があるので、そのような重大な決定を下す十分な理由がなければなりません。



***



動的コード生成の制限は、Mono AoTの制限と完全に類似しており、互換性のあるコードはIL2CPPで動作します。 リフレクションは機能します。 System.Reflection.Emitのようなものはありません。 実行時に動的なコード生成はありません。



***



iOSはAoTがすでに使用されているため、最初のIL2CPP対応プラットフォームになり、移行がよりスムーズになります。 その後、PC、Mac、Linuxなどの他のプラットフォームがサポートされます。



***



AoTおよびLGPLの制限により、iOSでMonoを使用することはできません。これにより、エディターや他のプラットフォームのMonoを更新できなくなります。



***



私は弁護士ではありません。 間違いなく弁護士ではありません。 しかし、MonoとLGPLに関連する法的制限については、次のように言えます。 問題はレイアウトにありません。ユーザーに追加のデータ（オブジェクトファイル）を提供することでレイアウトを作成できます。 問題は、制限がUnityでゲームやアプリケーションを作成するすべてのお客様に影響することです。 LGPLもすべての顧客にオブジェクトファイルを提供することを余儀なくされます。 繰り返しますが、私は弁護士ではないことに注意してください。これはUnityの公式な立場ではなく、プログラマーなどの状況に対する私の理解を反映しているだけです。



***



Monoでは、新しいプラットフォームごとに専門家のチームを維持する必要がありました。 Monoがこのプラットフォームをサポートしていない場合、実際には各プラットフォーム用に独自のJITツールをゼロから作成する必要があるため、膨大な作業を行う必要がありました。 一部のプラットフォームでは、Monoを他のすべての作業の3倍の電力を転送することに費やしました。 IL2CPPを使用すると、JITツールを作成する代わりに、既存のC ++コンパイラを簡単に使用できます。



***



私は9年間Monoに取り組んできましたが、Monoとこのプラットフォームの両方の本当の専門家がMonoを新しいプラットフォームに移すのに約1年かかると自信を持って言えます。実装を必要とするすべての機能を追加し、このプラットフォームに固有。 新しい技術プラットフォームの専門家がどれほど喜んでいるかを言葉で説明することは困難です。 彼らは、C ++でアセンブリコードを生成、デバッグ、および保守する権利と引き換えになります。 ノートには、移植には数か月や数年ではなく数日かかることが記載されているはずです。 多くの人がこの方向に動いているように思えます。 Microsoftが.Net Nativeを発表する前に作業を開始しましたが、これは選択した戦略の正確性を確認するだけです。 実行時に少し制限された可能性（動的生成なし）があると、多くの利点が得られます。 スタンドアロンPCアプリケーションにこれを強制的に使用することはありません。 IL2CPPがAoTプラットフォームで十分に安定するとすぐに、Monoの更新バージョンとエディターが提供されます。 IL2CPPの主な目標は、AoTが本当に理にかなっているプラ​​ットフォームです。



***



通常、スクリプトはパフォーマンスのボトルネックではなく、通常、スクリプトが正しくない場合や問題がある場合に問題が発生することを理解しています。 C＃メソッドの実行が遅すぎないという不満はまだありません。 ガベージコレクションは別の会話で、後で使用します。 しかし、人々はパフォーマンスについて議論するのが好きです。 IL2CPPは、多くの場合、以前は重すぎると見なされ、C ++で実行されていたものに対してスクリプトを有意義に使用するように思われます。 AI、物理学、およびそのようなものは、すべてのほとんどを加速し、新しい、興味深い可能性が表示されます。



個人的に、私はすぐに次の最適化を思い出すことができます

-配列の境界の確認を拒否

-例外のサポートの排除（それらからの負荷はプラットフォームによって異なります）

-インスタンスを作成したり、静的メソッド/プロパティにアクセスしたりするたびに、静的初期化を削除し、静的コンストラクターを使用してすべてのタイプで実行されたことを確認する必要があります

-SIMDサポート

-バイナリコードとマネージコード間の相互作用の最適化。 私たちは最大限にそれを実現しようとしますが、追加の制限に自発的に同意することでそれを強化する機会を与える可能性が高いです



これはすべて、私が今覚えていたもののランダムなリストです。 後で、より詳細な情報を公開します。



***

Unityは、ゲームのMODを作成する機能をサポートしておらず、パッチを作成する機能もサポートしていません。 これで、追加の.Net dllからmodをロードできるサードパーティのソリューションができました（ただし、パッチはこの方法では実行できません）。 しかし、IL2CPPではこれもできません。

Mac / Linux / Windowsおよびエディターでは、非常に長い間、Monoをオプションの1つとしてサポートし、しばらくしてから新しいバージョンに更新します。 したがって、これらのプラットフォーム用にmod対応のゲームを作成している場合は、引き続きMonoを使用できます。 問題ありません。 Mac / Linux / Winのクロスパブリッシングも引き続き変更されません。



iOSやUnityコンソールなどの他のプラットフォームでは、UnityはすでにMono AoTを使用しているため、dllのロードはすでに不可能であり、プラットフォーム自体の制限により不可能になります。 ここでは何も失われません。