ハードウェアのベンチマーク (2017 年半ば時点)

ハードウェアのベンチマーク分析を示し、それぞれのプロジェクトで理想的なハードウェア構成を選ぶ支援をします。

Windows
MacOS
Linux

以下の分析、価格見積もり、および発生しうる負荷に対する見解 (2017 年半ば時点のもの) は、情報目的に限ったものです。

以下のハードウェアのベンチマーク テストは、プライベートの P4V ストリームで、すなわち //UE4/Private-HardwareTest で、//UE4/Main の Changelist (CL) 3477826 からとった一定のコードのスナップショットを使って実施しました。結果を効率的に自動化して収集する目的で、このジョブは計時データ (同期、待機などは除外) を使ってビルド システムを通して実行されました。調査の目的上、以下のマシン構成でテストしました。

マシンの名称

タイプ

CPU

コア/スレッド

RAM

Dell T7910

デスクトップ

Xeon E5-2667 v3 @ 3.2 GHz (Dual)

8C/16T x 2

96GB

Dell T7810

デスクトップ

Xeon E5-2643 v3 @ 3.4 GHz (Single)

6C/12T

64GB

Lenovo P710

デスクトップ

Xeon E5-2637 v4 @ 3.5 GHz (Dual)

4C/8T x 2

96GB

Lenovo P510

デスクトップ

Xeon E5-1650 v3 @ 3.5 GHz (Single)

6C/12T

64GB

Current Builder

サーバー

Xeon E5-2680 v2 @ 2.8 GHz (Dual)

10C/20H x 2

64GB

Cisco C220-01 (S)*

サーバー

Xeon E5-2637 v4 @ 3.5 GHz (Single)

4C/8H

64GB

Cisco C220-01 (D)

サーバー

Xeon E5-2637 v4 @ 3.5 GHz (Dual)

4C/8H x 2

64GB

Cisco C220-02 (S)*

サーバー

Xeon E5-2698 v4 @ 2.2 GHz (Single)

20C/40H

64GB

Cisco C220-02 (D)

サーバー

Xeon E5-2698 v4 @ 2.2 GHz (Dual)

20C/40H x 2

64GB

Cisco C220-03 (S)*

サーバー

Xeon E5-2640 v4 @ 2.4 GHz (Single)

10C/20H

64GB

Cisco C220-03 (D)

サーバー

Xeon E5-2640 v4 @ 2.4 GHz (Dual)

10C/20H x 2

64GB

*これらは、 (D) タイプと同じマシンですが、CPU がひとつ取り除かれています。

テスト中、デスクトップ マシンでは Windows 10 を実行し、サーバー マシンでは、Windows Server 2012 R2 を実行しました。 さらに、すべてのマシンで Samsung 850 PRO データ ドライブとギガビット イーサネット接続を用いました。

XGE でコンパイル

デスクトップ マシンだけがテスト対象とみなされました。エピック本社では標準の Incredibuild-XGE (XGE) のコーディネータとエージェント プールを使用していました。

すべてのマシンは同じ様に実行しましたが、T7910 は他に比べて速度が少し遅い傾向がありました。T7910 のクロック速度は最低ですが、このマシンのパフォーマンスが他に比べて遅い理由は特定しませんでした。

T7910

T7810

P710

P510

UE4Editor Win64 のコンパイル

0:07:03

0:06:28

0:06:35

0:06:29

ParagonEditor Win64 のコンパイル

0:06:22

0:05:42

0:06:03

0:05:48

Compile FortniteEditor Win64 のコンパイル

0:05:24

0:05:08

0:04:57

0:05:00

XGE によるコンパイル時間はかなり不安定なため、小さな違いは無視した方が無難です。通常、エディタ をコンパイルするのに 5 分から 8 分かかります。

HB_1.png

一日の様々な時刻 (午前 12時、午前 6 時、午後 12 時、および 6 時) に別個のテストを実行し、エージェント ファームのロードによって著しいボトルネックを生じたかを判断しました。

HB_2.png

朝のコンパイル時間は、不安定でした。これは、多くのデベロッパーが有効にしている UnrealGameSync で朝 6 時にスケジュールされているデフォルトの同期に関連している可能性があります。

メモリ

P710P9710 にインストールされている追加の RAM はパフォーマンスの向上につながっていないようでした。

I/O

こうしたテストはすべて Samsung 850 PRO データ ドライブ上で実行されていました。P710 にはデュアル RAID-0 PCIe m.2 システム ドライブがあり、読み出し / 書き込みのパフォーマンスは以下のように大幅に高くなっています。

HB_3.png

HB_4.png

RAID-0 PCIe m.2

Samsung 850 PRO

XGE コンパイルのタイミングが不安定なことから、このドライブでのコンパイルではパフォーマンスの大幅な向上はみられませんでした。

P710 - Samsung 850 PRO

P710 - 2 x PCIe m.2

違い

UE4Editor Win64 のコンパイル

0:06:35

0:05:33

-15.74%

FortniteEditor Win64 のコンパイル

0:04:57

0:05:16

6.37%

XGE なしでコンパイル

以下の黄色の線のように、T7910 のパフォーマンスには若干の低下がありました。T7910 のパフォーマンスの低下理由はわかりませんでしたが、すべてのマシンでこうしたテストを実行した場合に、別の CPU 構成ではコンパイル時間が安定しました。

HB_5.png

Editor のコンパイル時間を見ると、ビルド時間は物理的なコア数にかなり線形になります。コア数が同じならばシングル CPU 構成の方が、デュアル CPU 構成よりも若干速くなりました。

HB_6.png

IWYU (Include-What-You-Use) のリファクタリング以降、Editor のコンパイルがかなり並列になり、PCH (プリコンパイル済ヘッダー) のボトルネックもほとんどないため、上記の相関関係が予測されます。

メモリ

ビルド プロセスでは、各論理コアに対してひとつのコンパイラ インスタンスをスポーンしますが、これが C220-02 (D) の制約要因になります。テストで使った他のどのマシンよりもコア (40C/80H) が多いためです。C220-02 (D) の制約要因に対処するため、RAM を倍の 128 GB にしました。以下のように、パフォーマンスがかなり向上しました。

C220-02 (D) - 64GB

C220-02 (D) - 128GB

違い

UE4Editor Win64 のコンパイル

0:10:06

0:06:43

-33.50%

ParagonEditor Win64 のコンパイル

0:08:12

0:05:29

-33.13%

FortniteEditor Win64 のコンパイル

0:06:08

0:04:12

-31.52%

C220-03 (D) マシン (20C/40H) の RAM を倍にした後、パフォーマンスが約 10 % 向上しました (以下参照)。

C220-03 (D) - 64GB

C220-03 (D) - 128GB

違い

UE4Editor Win64 のコンパイル

0:12:33

0:10:40

-14.92%

ParagonEditor Win64 のコンパイル

0:10:03

0:09:03

-10.01%

FortniteEditor Win64 のコンパイル

0:07:08

0:06:37

-7.24%

コア数が少ないマシンでは、コンパイラ プロセスが少なければメモリ使用も少ないため、急速に減少することが予測されます。

I/O

デュアル RAID-0 PCIe m.2 (P710 で利用可能) マシンの Editor のコンパイルでは、目立ったパフォーマンスの改善はみられませんでした。このマシンのコア数はかなり少ないものです (2 x 4C/8T)。そのため、制約要因にはならなかった可能性があります。

P710 - Samsung 850 PRO

P710 - 2 x PCIe m.2

違い

UE4Editor Win64 - NoXGE のコンパイル

0:21:11

0:20:59

-0.94%

利用可能な RAM を増やすと、C220-02 (D) マシン (このマシンでより高速なハードドライブの選択肢は用意しませんでした) の残りのボトルネックになるのは I/O である可能性が高くなります。このドキュメント作成時点では、CPU のコストが高くなると (1 つの CPU について約 3,500 ドル、合計で 7,000 ドル)、幅広く展開可能なものとしての選択肢から外れる可能性があります。

コンテンツのクック

クック 中、タスク マネージャ には 1 つまたは 2 つのスレッドがアクティブであることが表示されます。蓄積された (または頻繁にアクセスされる) DDC Derived Data Cache があるため、パッケージのシリアル化がボトルネックの原因になりがちでした。

T7910

T7810

P710

P510

Paragon Win64

0:38:00

0:35:04

0:37:18

0:35:15

Fortnite Win64

0:59:59

0:55:49

1:01:41

0:55:47

Current

C220-01 (D)

C220-02 (D)

C220-03 (D)

Paragon Win64

0:32:05

0:29:38

0:32:19

0:34:13

Fortnite Win64

1:03:59

0:51:32

0:55:47

0:58:32

デスクトップ

ビルダー

シングル コア構成の C220 マシンのテスト結果は、無効とみなされ破棄されました。デフォルトの Windows Server のパワー構成では、シリアル タスク (コンテンツのクックなど) に対する CPU のパフォーマンスで良い結果が得られませんでした。

メモリ

Fortnite のクックでは、RAM の使用が約 55 GB でピークになる傾向があり、RAM を増やしてもクック時間に違いはありませんでした。 さらに ガーベジ コレクション を無効にしてパッケージをリロードしないようにしました。これは 64 GB の RAM で十分ワーキング セット全体をカバーすることを意味します。この指標は、ゲームの進化に伴い高くなりそうです。

C220-03 (D) - 64MB

C220-03 (D) - 128MB

違い

Paragon Win64 のクック

0:34:13

0:32:10

-6.01%

Fortnite Win64 のクック

0:58:32

0:57:09

-2.35%

C220-02 (D) - 64MB

C220-02 (D) - 128MB

違い

Paragon Win64

0:32:19

0:33:33

3.83%

Fortnite Win64 のクック

0:55:47

0:55:58

0.34%

I/O

I/O のパフォーマンスの影響を見るために、P710 のデュアル RAID-0 PCIe m.2 システム ドライブで Fortnite をクックしました。驚くべきことに、パフォーマンスの違いはほとんどありませんでした。

P710 - Samsung 850 PRO

P710 - 2 x PCIe m.2

違い

Fortnite Win64 のクック

1:01:41

1:01:02

-1.04%

ローカル DDC

ビルド マシンは、レガシーを使用しているため、ローカル DDC を維持しません。複数ブランチからクックを実行する場合のディスク管理はレガシーを使っているため、少々やっかいなものになっています。定期的にディスク空間をクリーンアップするというこれまでのやり方では、ローカル キャッシュを使用するよりもバックフィルするのに時間がかかっていました。

マシン名

Current

共有 DDC のみ

ローカルと共有 DDC

違い

Paragon のクック

0:32:05

0:31:55

-0.52%

Fortnite のクック

1:03:59

1:02:19

-2.60%

C220-01 (D)

共有 DDC のみ

ローカルと共有 DDC

違い

Paragon のクック

0:29:38

0:20:43

-30.09%

Fortnite のクック

0:51:32

0:48:24

-6.08%

C220-02 (D)

共有 DDC のみ

ローカルと共有 DDC

違い

Paragon のクック

0:32:19

0:23:36

-26.97%

Fortnite のクック

0:55:47

0:52:37

-5.68%

C220-03 (D)

共有 DDC のみ

ローカルと共有 DDC

違い

Paragon のクック

0:34:13

0:24:35

-28.15%

Fortnite のクック

0:58:32

0:54:23

-7.09%

共有 DDC

クック時のネットワークのパフォーマンス (およびネットワーク共有のパフォーマンス) の影響を測定するために、共有 DDC を無効にした状態で、ローカルの DDC をデータが十分にデータが入った状態でテストを実行しました。共有 DDC への書き込みは非同期で行われます。そのためローカル DDC に整合性があれば、共有 DDC を無効にしてもクック時間に影響はありません。

マシン名

Current

共有 DDC のみ

ローカルと共有 DDC

違い

Paragon のクック

0:31:55

0:30:36

-4.13%

Fortnite のクック

1:02:19

1:02:57

1.02%

C220-01 (D)

共有 DDC のみ

ローカルと共有 DDC

違い

Paragon のクック

0:20:43

0:20:40

-0.24%

Fortnite のクック

0:48:24

0:48:13

-0.38%

C220-02 (D)

共有 DDC のみ

ローカルと共有 DDC

違い

Paragon のクック

0:23:36

0:23:16

-1.41%

Fortnite のクック

0:52:37

0:52:08

-0.92%

C220-03 (D)

共有 DDC のみ

ローカルと共有 DDC

違い

Paragon のクック

0:24:35

0:24:08

-1.83%

Fortnite のクック

0:54:23

0:54:50

0.83%

DDC を無効にする

クッカの時間は主にパッケージのシリアライズのイン、アウトに使われます。これは、CPU のコアを増やしても効果はありません。ただし、アニメーション データの圧縮、シェーダーのコンパイル、プラットフォーム固有のテクスチャなどの派生データを生成する場合に並列して実行されます。

DDC はほとんどのアセットのタイプでクッカのマスクで適切な処理を行います。テクスチャ圧縮は特に遅くなる可能性がありますが、コンプレッサーは滅多に変わりません。そのため負荷は各テクスチャ変更で一回だけ発生します。

DDC データを無効にする多くのきっかけは、エンジンのシェーダー バージョンが変わったときです。こうした変更は、オフサイトで作業をしているユーザーに大きな影響を及ぼします。そのため、新しいシェーダー バージョンでクックの時間を測定しました。

あるマシンのキャッシュされたデータが別のマシンによって使われないように共有 DDC を無効にしてこうしたテストを行いました。

マシン名

古いシェーダー

新しいシェーダー

違い

Current

Paragon のクック

0:30:36

7:53:40

1,447.93%

C220-01 (D)

Paragon のクック

0:20:40

15:04:22

4,275.97%

C220-02 (D)

Paragon のクック

0:23:16

7:55:22

1,943.12%

C220-03 (D)

Paragon のクック

0:24:08

9:08:44

2,173.76%

現在のビルド マシン (2 x 10C/20H) が、C220-03 (D) (同じく 2 x 10C/20H) ではなく、C220-02 (D) (2 x 20C/40H) と同じように実行するのには驚かされました。ただし、テストは一回しか実行していません。テストをあと数回行っていたら、結果に若干の違いが出たかもしれません。

興味深いのは、他のゲームでは、Paragon のシェーダーをビルドするとクック時間が妥当な範囲に収まることです (シェーダーのほとんどがローカルの DDC にある状態で)。

マシン名

Current

古いシェーダー

新しいシェーダー

違い

Fortnite のクック

1:02:57

1:49:16

73.58%

C220-01 (D)

古いシェーダー

新しいシェーダー

違い

Fortnite のクック

0:48:13

終了せず

該当なし

C220-02 (D)

古いシェーダー

新しいシェーダー

違い

Fortnite のクック

0:52:08

2:08:57

147.35%

C220-03 (D)

古いシェーダー

新しいシェーダー

違い

Fortnite のクック

0:54:50

2:20:54

156.05%

エディタをコンパイルし、Paragon をクック後、C220-01 (D) の組込みコントローラーでジョブのタイムアウトがあり、テスト中に終了しませんでした。

オンサイト デベロッパー向け推奨事項

オンサイトで作業する場合、XGE の使用は、コア数の多い CPU の優れた代替になります (ただしパフォーマンスは不安定になることがあります)。 これに匹敵する唯一のスタンドアロン マシンは、128GB の RAM を搭載した 2 x 20C/40T ビルダーでした。 T7810 は新しい T7910 の性能を上回り、その違いはわずかですが、プロセッサが高速なマシンの方が好ましいようです。

64GB の RAM はベースライン構成では妥当と思われますが、将来も使い続けられるようにするには、96-128GB の RAM (または将来の拡張を計画する場合) が賢明な選択です。

Samsung 850 PRO SSD はうまく機能するようです。システム / データのドライブを別に持つことはスペースが少なくなっている場合にシステムの安定性を確保するうえで妥当なポリシーです。ただし、必要とするツールに対して標準の 256 GB ドライブでは不十分だという不満をよく耳にします。 SSD の Write Amplification によるパフォーマンスの損失を防ぐために、システムのページファイルの拡張のために空きスペースをリザーブします。倍の 512 GB にするのが妥当な選択です。

オフサイト デベロッパー向け推奨事項

共有 DDC や XGE のファームを利用できないデベロッパーは、コア数が多い方が必ずメリットがあります。2 x 10C/20H 構成 (それぞれ約1,000 ドル) は妥当な選択と思われます。それぞれ約 3,500 ドルの 2 x 20C/40H 構成は、期待される性能に対して少々割高と考えられるからです。

最終的に、 (コンパイル時に) パフォーマンスを 10 % 上げるために 128GB の RAM をインストールするのは価値がありそうです。

ビルド ファームをセットアップする

オフサイトのデベロッパーの場合、ビルド マシンは通常、エピック社内のビルド ファームの仕様に合わせます。通常のデベロッパーとは異なり、過去の我々の経験から、ビルダーのロードはかなり一定であり、XGE を使用するとダウンタイム中の作業負荷を広範囲に分散するよりも、コンテンションと不安定さが増すことがわかりました。 XGE がない場合にパフォーマンスに主に影響を及ぼすのは、CPU のコア数です。

ビルド ファームで実行しているジョブを分析することで、クックとコンパイルの所要時間の割合についてのアイデアが浮かびました。この情報を使って、同じ作業負荷を処理するときに異なる CPU 構成を使うとコスト効率はどのようになるかを評価しました。現在のファームを使用すると、50/50 に近い状態になりました。毎日コンパイルに 418 ビルダー時間を費やし、クックや他の (主に) シリアル タスクに約 423 のビルダー時間を費やしました。

5,000 ドルをベース マシン価格と想定し、Amazon の個々の CPU 価格から、平均的な作業単位をどれくらい迅速に行うかに基づいて標準的なマシン価格を見積もりました。これでハイエンドのマシンに 100,000 ドルを費やした方が良いか、倍の台数のローエンドのマシンを購入した方がよいかの評価基準が得られます。

マシン名

CPU

行われた相対的作業

CPU 価格

マシンの標準価格

実施された作業当たりの価格

C220-01 (S)

E5-2637 v4 - 4C/8H 3.5GHz

1.395

$996.00

$5,996.00

$8,367.12

C220-01 (D)

E5-2637 v4 - 4C/8H 3.5GHz (dual)

1.276

$1,992.00

$6,992.00

$8,922.15

C220-02 (S)

E5-2698 v4 - 20C/40H 2.2GHz

0.931

$3,226.00

$8,226.00

$7,662.22

C220-02 (D)

E5-2698 v4 - 20C/40H 2.2GHz (dual)

0.851

$6,452.00

$11,452.00

$9,744.96

C220-03 (S)

E5-2640 v4 - 10C/20H 2.4GHz

1.268

$939.00

$5,939.00

$7,531.10

C220-03 (D)

E5-2640 v4 - 10C/20H 2.4GHz (dual)

1.006

$1,878.00

$6,878.00

$6,921.82

デュアル 10C/20H 構成が一番になり、現在のファームにあるデュアル E5-2680v2 10C/20H 構成に匹敵します。

Select Skin
Light
Dark

Welcome to the new Unreal Engine 4 Documentation site!

We're working on lots of new features including a feedback system so you can tell us how we are doing. It's not quite ready for use in the wild yet, so head over to the Documentation Feedback forum to tell us about this page or call out any issues you are encountering in the meantime.

We'll be sure to let you know when the new system is up and running.

Post Feedback