ネイティブコード生成

Luauのネイティブコード生成をサポートすることで、ゲーム内のサーバーサイドスクリプトは、Luau VMが操作する通常のバイトコードではなく、CPUが実行するマシンコード命令に直接コンパイルされます。この機能は、特に重いLuauライブラリやRoblox API呼び出しを多く使用せずに、多くの数値計算を行うスクリプトの実行速度を向上させるために使用できます。

ネイティブコード生成の有効化

Scriptのネイティブコード生成を有効化するには、最上部に--!nativeコメントを追加します:¹

--!native

print("ネイティブコードからこんにちは！")

これにより、スクリプト内のすべての関数と、利益が見込まれる場合はトップレベルスコープに対してネイティブコード生成が有効化されます。追加の変更は必要ありません; ネイティブに実行されるスクリプトの動作は以前とまったく同じで、パフォーマンスだけが異なります。Luau言語のすべての機能とすべてのRoblox APIは引き続きサポートされます。

また、個々の関数に対してネイティブコード生成を有効化するには、@native属性を追加します:

@native
local function f(x)
  return (x + 1)
end

ベストプラクティス

次のヒントは、ネイティブコード生成の利点を最大限に引き出すのに役立ちます:

• 大量の計算をLuau内部で直接行うスクリプト内でこの機能を有効にするのが最も良いです。テーブルに対する多くの数学的操作、特にbufferタイプがある場合、そのスクリプトは良い候補になるかもしれません。

• スクリプトの関数のみがネイティブにコンパイルされます。外側のスコープのコードはほとんどの場合1回だけ実行され、多くの回数呼び出される関数ほど恩恵を受けません。

• ネイティブコンパイル有無でスクリプトや関数がかかる時間を測定して、使用するのが最適なタイミングを判断することをお勧めします。スクリプトプロファイラーツールは、情報に基づいた決定を下すために関数のパフォーマンスを測定できます。

• すべてのスクリプトに--!nativeコメントを配置するのは魅力的かもしれませんが、ネイティブコード生成にはいくつかの欠点があります:

  • コードコンパイル時間が必要で、サーバーの起動時間が増加する可能性があります。
  • ネイティブにコンパイルされたコードを保存するために追加のメモリが占有されます。
  • ゲーム内で許可されるネイティブにコンパイルされたコードの合計量には制限があります。

これらの問題は、@native属性を賢く使用することで対処できます。

避けるべきコード

ネイティブコード生成が有効であっても、すべての機能が同じように動作しますが、いくつかはネイティブに実行されず、最適化が非効率になるか、解釈された実行にフォールバックする可能性があります。これには以下が含まれます:

• 非推奨のgetfenv()/setfenv()呼び出しの使用。
• 数値引数でないmath.asin()などのさまざまなLuau組み込み関数の使用。
• 型の異なるパラメータを型付き関数に渡すこと、たとえばfunction foo(arg: string)と宣言された関数にfoo(true)と呼び出すこと。常に正しい型アノテーションを使用することを忘れないでください。

スクリプトプロファイラーを使用することで、通常のバージョンの関数とネイティブにコンパイルされたものとの実行時間を比較できます。--!nativeスクリプト内または@nativeでマークされた関数がネイティブで実行されていない場合、上記のリストの1つ以上の要因が最適化を無効にしている可能性があります。

型アノテーションを使用する

ネイティブコード生成は、与えられた変数に対して最も可能性の高い型を推測して、コードパスを最適化しようとします。たとえば、a + bは数字で行われると仮定され、t.Xでテーブルにアクセスされると想定されます。しかし、演算子のオーバーロードによって、aとbはテーブルまたはVector3型である可能性があり、tはRobloxデータ型である可能性があります。

ネイティブコード生成は任意の型をサポートしますが、誤った予測は不要なチェックを引き起こし、コードの実行を遅くする可能性があります。

いくつかの一般的な問題を解決するために、関数引数のLuau型アノテーションがチェックされますが、特にVector3引数にアノテーションを付けることが推奨されます:

--!native

-- "v"はテーブルであると仮定されるため、テーブルチェックにより関数が遅く実行される
local function sumComponentsSlow(v)
	return v.X + v.Y + v.Z
end

-- "v"はVector3として宣言されるため、ベクトル用に特化されたコードが生成される
local function sumComponentsFast(v: Vector3)
	return v.X + v.Y + v.Z
end

スタジオツール

次のスタジオツールは--!nativeスクリプトおよび@native関数をサポートしています。

デバッグ

スクリプトの一般的なデバッグがサポートされていますが、ローカル/アップバリューのビューは不完全で、ネイティブに実行されているコールスタックフレームから変数が欠落している場合があります。

また、ネイティブコンパイル用に選択されたコードをデバッグする際には、ブレークポイントを配置すると、その関数のネイティブ実行が無効化されることに注意してください。

スクリプトプロファイラー

スクリプトプロファイラーでは、ネイティブに実行されている関数の横に<native>が表示されます:

@nativeでマークされた関数または--!nativeスクリプト内の関数が<native>アノテーションを表示しない場合、その関数はブレークポイントの配置、避けるべきコードの使用、あるいは不一致な型アノテーションのためにネイティブに実行されていない可能性があります。

Luauヒープ

Luauヒーププロファイラーでは、ネイティブ関数によって占有されたメモリがグラフ内の[native]要素として表示されます。

サイズ分析

すべてのネイティブコンパイルされたスクリプトはメモリを消費します。コンパイルされたコードのサイズがあらかじめ定義された制限に達すると、ネイティブコンパイルは停止し、残りのコードは非ネイティブで実行されます。これにより、ネイティブコンパイル用のスクリプトを慎重に選択することが重要です。

個々の関数やスクリプトのネイティブコードサイズを監視するには:

1. クライアント/サーバー切替ボタンを通じてサーバービューになっていることを確認します。
2. コマンドバーでdebug.dumpcodesize()を呼び出します。

出力ウィンドウには、呼び出し時点までにネイティブにコンパイルされたスクリプトや関数の合計数、ネイティブコードが占有するメモリ、ネイティブコードのサイズ制限が表示されます。概要の後、コードサイズの降順でネイティブコンパイルされたスクリプトごとの表が表示されます。

各スクリプトについて、出力にはコンパイルされた関数の数とネイティブコードメモリ消費量が表示されます。その後、各関数はネイティブコードサイズの降順でリストされ、匿名関数は[anonymous]として、全体のスクリプトは[top level]として表示されます。最後の列には、ネイティブコードサイズ制限に関するパーセンテージが計算されて表示されます。関数のネイティブコードサイズは正確に報告されますが、スクリプトのメモリ消費量は最も近いページサイズに切り上げられます。

制限とトラブルシューティング

特定のCPU用にコードを命令にコンパイルすることは、追加のストレージメモリを必要とします。さらに、複雑な関数の最適化には時間がかかる場合があります。内部制限に達すると、スタジオの出力ウィンドウにエラーが報告されます: