お世話になっております。
現在開発中のプロジェクトにおいて2種類のビルドマシンを利用していますが、スペックの違いに対してビルド時間に大幅な乖離が生じているように見えます。
ハードウェアスペック以外にアセットなどの差分はありません。
共通スペック
memory: 128 GB
OS: Microsoft Windows 11 Enterprise 10.0.22631 ビルド 22631
SSD: Samsung SSD 870 EVO 4TB
UE: 5.4.4+独自拡張
マシン1
CPU: AMD Ryzen 9 5950X
GPU: NVIDIA GeForce RTX 3090
ビルド時間: 平均2h
マシン2
CPU: 12th Gen Intel(R) Core™ i9-12900K
GPU: NVIDIA GeForce RTX 3070
ビルド時間: 平均3.8h
ビルドマシンの置き換えを含めて検討したく、下記ご教示頂けますでしょうか？
- 各ビルドステージ （Build / Cook / Stage / Pak）でどのようにハードウェアリソースが使われるでしょうか？重視すべき性能が知りたいと考えています。
- このようなスペックの差異によるパフォーマンスネックを疑う場合Insightsをどのように確認すると良いでしょうか？
- 上記2種類のマシンでビルド時間に倍近く差がでることは平常でしょうか？
他、不足の情報があればご指摘ください。
お忙しい中恐縮ですがご確認頂けますと幸いです。
お世話になっております。
- 各ビルドステージ （Build / Cook / Stage / Pak）でどのようにハードウェアリソースが使われるでしょうか？重視すべき性能が知りたいと考えています。
Build：ソースコードのビルドを行うステージですが、CPU/RAM/Storage が関係します。コア数が多いCPUを利用すると、同一PC内でも並列ビルドがより多く実行できるようになりビルド時間が短縮されます。ただしその分スレッドごとに必要なメモリも増えるためRAMも同様に大きくしておくことが望ましいです。RAMはビルド時のメモリが不足しているとOSがスワップして仮想メモリを使うためビルド速度が低下するため注意が必要です。コンパイラはソースコードを解析、変換する過程で大量の中間データやキャッシュファイルを生成します。そのため Storage は SSDの方がHDDに比べて高速となりファイルIOが早くなります。
Cook：アセットをプラットフォーム毎にコンバート処理を行うステージですが、主にCPU/RAM/Storage が関係します。CPUは純粋にアセットのロード、クック処理速度に直結しますが、コア数がCPUほどシェーダーコンパイルやDDCアクセスなどの並列処理が効率的に実行できます。RAMも大きくしておくことが望ましいのは、クックするアセットを順番に処理していく過程でメモリが増加し続けてOOOが発生するのを避けるために、一定以上でGCを発生させてオブジェクトを開放する処理が行われるためです。RAMが大きいほどメモリ上限に到達しにくく、GCの発生頻度も下がりますが、GCはオブジェクトの捜査や破棄処理が行われるためそこそこの時間がかかることから出来るだけ起きさせないようにすることが望ましいです。そしてクックするファイルが多いほどファイルアクセスが頻発するため、SSDの利用は必須といっても過言ではありません。
Stage：ここではBuildで作成した実行ファイル、クックしたアセットをステージングディレクトリにコピーするステージですが、主にStrageが関係します。単なるファイルコピーなのでCPU, RAMは関与しませんが、ファイルアクセスが発生するためSSDを利用することをおすすめします。パックファイル／コンテナファイル(.pak, .utoc)もこのステージで作成されますが、ファイルを１ファイルとして保存する処理のため、主にファイルアクセスが発生するぐらいです。
Package：ここではステージングディレクトリにコピーされた実行ファイルとクック済アセットからアプリケーションパッケージを作成するステージですが、主にStorageぐらいが関与するところかと思います。アプリケーションパッケージの作成は、各プラットフォームのツールにエンジン側から指示を出すだけなので、実際にはプラットフォームのツール次第です。そのためファイルアクセスによるStorageは関与しますが、CPUもやや関与する部分です。
- このようなスペックの差異によるパフォーマンスネックを疑う場合Insightsをどのように確認すると良いでしょうか？
すべてのプロセスをInsightsで確認することはできないため、まずは各ステージの時間を計測してどの部分で差が大きいかを見てみることをおすすめします。UATで実行して各プロセスの時間を見ても良いですが、簡単に確認できるのはProject Launcherから各ステージにかかった時間を調べることです。Hordeをご利用の場合も各ステージでかかった処理をダッシュボードで確認できます。
- 上記2種類のマシンでビルド時間に倍近く差がでることは平常でしょうか？
実際に弊社でこのような検証をしていないため何ともコメントが難しいですが、CPUのスペックに有意差がない場合はここまでの差が出ることは考えにくいですが、ClockやL2/L3キャッシュなどの差が影響しているかもしれません。ビルド時間=Buildのみであればそれほど差が出ないと思われますが、最初の質問でビルドステージ（Build / Cook / Stage / Pak）と記載頂いておりましたので、ここでのビルド時間というものが全てのビルドステージについて言及しているのであれば、CookやStageでCPUの差による影響があるのかもしれません。ただし弊社ではソースコードのビルド・シェーダーコンパイルをUBAを利用して複数PCにビルドを分散させているため、1台のPCに対してそれほど有意差を計測することはありませんでした。
詳しく回答頂きありがとうございます。
大変お手数ですが下記についてさらに確認させてください。
- GCはオブジェクトの捜査や破棄処理が行われるためそこそこの時間がかかることから出来るだけ起きさせないようにする
- CookSettingsのMemoryMinFree、MemoryMaxUsedなどの値を利用してGCタイミングをコントロールできる理解ですが、なるべくGCさせないようにするためにはどのような設定を行うことが推奨でしょうか？現在はMin2GB、Max0のデフォルト値で運用しており、Cook中のメモリには多少の余裕がありそうです。
- UBAを利用
- 現在プロジェクトでは複数のビルドマシンをイニシエーターとしてIncredibuildを用いて分散ビルドしていますが、併せてUBAの導入も検討したいと考えています。ドキュメントを見るとUBAの構成はAgentインストール時に一台のイニシエーターを指定している理解なのですが、複数台からビルド開始するためにどのように構成すればよいでしょうか？あるいはUBA利用時は1台のビルドマシンからビルド開始することが推奨でしょうか？
- UATの各プロセス時間の計測について
- コンソールからRunUAT.batをキックするようなジョブを用いてビルド自動化しています。各プロセスの時間は実行ログのタイムスタンプを確認する理解であっていますでしょうか？各プロセスごと経過時間を簡単に確認する手段はありますか？
わかりやすくご教示いただきありがとうございます。
よろしくお願いいたします。
追加のご質問について、
クックコンテンツ次第の部分も多いためここに推奨設定は特にありませんが、MemoryMinFreePhysical,MemoryMinFreeVirtual (またはMemoryMaxUsedPhysical, MemoryMaxUsedVirtual)を調整して頂くことでGC頻度を調整できます。
Editor.ini:[CookSettings]:MemoryMaxUsedVirtual=0 および MemoryMaxUsedPhysical=0 に設定することで、メモリの上限を解除して極力GCの発生を抑制できます。MemoryMinFreePhysical=<使用可能な物理メモリの約 5～10%> を設定すると、ガベージ コレクションの前に使用可能なすべてのメモリを全て使用するような、良好なパフォーマンスが得られます。
ネットワーク上のどこかにイニシエーター(ビルドの中央管理を行うHorde Sever)が配置されていれば問題ありません。各作業者は自分のPCからビルドを行った際に、Horde Serverへのリクエストを元にして自動的にビルドプロセスが分散されます。
はい、ログのタイムスタンプをご確認いただくことで問題ございません。プロセスごとの経過時間を知りたい場合、UATを利用する場合はあまり良い方法がなく、ログをご確認いただくことになります。