「Stellaris」開発日記#181――スレッディングとロード時間

およそ3か月半ぶりとなる「Stellaris」の開発日記#181が公開されていましたので、その内容をご紹介。今回はスレッディングとロード時間について。2.7「ウェルズ」リリース後の開発日記です。

前回：開発日記#180――DLCの視認性実験

開発日記

開発日記#181は、今回はスレッディングとロード時間について。

• 私たちはまだオフィスにはいないが、仕事に戻っている。面白いニュースがあり、この秋冬は刺激的なものになるだろう。
• 今日は、次の2.8についてプログラマーが夏の間に取り組んできた技術的なことを紹介していく。次回以降の開発日記ではコンテンツや機能について明らかにしていく予定だ。

スレッドとは？

• ファンの間ではVictoria IIIとスレッディングを使ったパラド社開発スタジオのゲームのどちらが先に出るかというジョークがある。しかし残念ながらこの神話を（再度）打ち消さなければならない。すなわち、現在開発中のすべてのパラド社開発スタジオのゲームはEU4からCK3まで、Stellarisも含めて複数のスレッドを使用している。

ここでCPUのスレッドとコアの簡単な歴史が触れられていますが省略します。

• 高速なCPUでより高速に動作するコードを書くことは大したことではない。ほとんどのコードは自然にそうなる。しかしスレッドとコアの使用は別だ。プログラムは、プログラマーの設計次第で複数のコアで同時に実行できるようにするために2、4、8個に魔法のように計算を「分割」するわけではない。

どこも速くならないスレッディング

• フォーラムの懸念事項である「ゲームは複数のスレッドを使っているのか？」に対する答えはイエスだが、本当の疑問はこうではないだろうか。つまり「スレッドを効率的に使っているのか？」その答えは「場合による」だ。より多くのコアを効率的に利用するのはより多くのクロックサイクルを利用することよりもはるかに複雑な問題だ。私たちの場合、スレッド間で作業を分散させるときにはシーケンシングと順序付けという2つの大きな問題がある。
• シーケンシングの問題は同時に実行されている2つの計算が同じデータにアクセスする必要がある場合に発生する。例えば、Prikki-TiとBlorgの2つのPopの清算を計算するとしよう。どちらも現在のエネルギー備蓄量にアクセスし、そこにエネルギー生産量を加算して、その値を返す。シーケンスによっては、どちらも初期値（例えば100）を読み込み、生産量（例えば12と3、Blorgは今日は調子が悪かった）を追加して値を返すことがある。理想としては最終的に115（100+12+3）としたいが、潜在的にはどちらも100を読み込んで計算し、最終的に112または103となってお互いを上書きすることもある。
• これを回避する簡単な方法は、ロックを導入することだ。Prikki-Tiは計算が終わって新しい値を返すまでエネルギー値を「ロック」し、それからBlorgの計算をする。これで問題は解決するが、より大きな問題が発生する。すなわち、計算が再びシーケンシャルになり、複数スレッドで並行して計算する利点が失われる。さらに悪いことに、ロック、アンロック、同期のコストがかかるため、最初に同じスレッドで両方を計算した場合よりも時間がかかる。

• 2つ目の問題は順序付け、あるいは「順序依存性」だ。つまり、操作の順序を変えると結果が変わる場合があるということだ。例えば、Prikki-TiとBlorgが「友好的な」手段で紛争を解決することにしたとしよう。戦闘システムは双方の戦闘員を処理するが、可能性としては多くの戦闘行動があるのでどれが最初に起こるかわからないし、2つのマシンで順序が異なる場合がある。
• 例えば、サーバーではPrikki-Tiの行動が先に起こり、クライアントではBlorgの行動が先に発生するような場合だ。サーバー上ではPrikki-Tiの行動が先に処理され、Blorgが殺害される。死んだBlorgは撃てないので、後で発生したBlorgの行動は破棄される。しかし、クライアントは別の方法で計算を分散させ（サーバーよりもコア数が多いのかもしれない）、この世界ではBlorgが先にPrikki-Tiを殺害してしまい、それに反撃できなくなった。そして、双方のプレイヤーの状況が乖離しているため、「Player is Out of Sync（プレイヤーが同期ズレ）」という恐ろしいポップアップが表示される。
• もちろんこの問題を解決する方法はあるが、通常は両方の制約を満たすように設計をやり直す必要がある。例えば、最初のケースでは各スレッドが各帝国に追加するPopごとの生産量を保存し、最後にそれらを統合している。同様に、2人の決闘者の問題はダメージを即座に記録することで解決できるが、決定性の順序付けの必要を排除するため、別のフェーズでこの効果を適用している。
• 想像できると思うが、既存のシステムを改造するよりも、スレッディングを念頭に置いて設計するほうがはるかに容易だ。

いいニュース

• 次のパッチでは具体的になにがあるのか？　エンジンの特に古い部分であるファイルとアセットのロードシステムに時間を割いたと聞いてみなさんは喜んでくれるだろう。長い間、私たちはこれを処理するためにサードパーティのソフトウェアを使用してきた。これによって多くのトラブルから救われたが、スレッディングが非常にまずいということもわかった。上で述べたロックの問題により、ときにはコア数が多いほど遅くなることもあったが、他の最適化も合わせて、ゲームの起動時間を大幅に短縮できた。
• 理由を説明するのに多くの言葉を費やすより、上の動画のほうがわかりやすいだろう。この比較は私（注：プログラマーのMatRopert氏）の自宅にある古いi7 2600KとSSDドライブを使っているPCで行った。どちらも「ホット」スタートアップ（直前にゲームを起動していた）だったが、実験では「コールド」スタートでも大きな違いがあることがわかった。
• 最高のスピードアップを実現するには、新しいベータ版のDirectX11レンダリングエンジンを使用する必要がある。読んでのとおり、次のパッチではオープンベータ版が提供され、旧式のDX9レンダラーをより新しいDX11バージョンに置き換える。これは協力会社であるTantalusが最初にStellarisコンソールエディションのために作ったものだ。視覚的には同じだが、DX11を使用してグラフィックスをレンダリングすることで、DX9では困難または不可能な幅広いマルチスレッディングの最適化が可能になる。古いレンダラーでプレイしても、起動時の高速化が図られ、スプラッシュスクリーンの段階はさらに高速化されるが、ゲームがモデルやテクスチャをロードするときに DX11のように進捗バーが「ジャンプ」することはほとんどない。
• こうした最適化の一部はクラウゼヴィッツエンジンの新しいバージョンにも適用されており、リリース時にはCK3にも含まれる。また、Imperatorもその恩恵を受けるはずだ。EU4やHoI4にも適用できるかもしれないが、今のところEU4での私の実験では、StellarisやCK3のような大きなスピードアップは見られなかった。Stellarisを高速化するために適用された最適化の技術的な詳細については、私が最近ブログで公開した記事を参照してほしい。
• これが私の最後のStellaris開発日記になる。というのは、来月にはチームを移ってHoI4のプログラマーを率いることになったからだ。この最適化は私からの餞別と思ってほしい。

質疑応答

Q1：じゃあこのアップデートはベータ版で来てるってこと？

A1：秘密保持契約の下でパラド社スタッフとベータテスターのみが利用できる内部ベータ版のみだ。

Q2：DX11になったことで最初のロード画面以外にパフォーマンスの改善はないの？

A2：言及していない他の最適化もあり、セーブのロードが早くなったはずだ。

Q3：Windowsでは次のパッチからDX11に変更するということ？　あとMacとかLinuxではOpenGL 4.1だったと思うんだけど。

A3：DX11は選択式で、デフォルトは依然としてDX9だ。MacとLinuxでレンダリングについて変更する計画は今のところない。

Q3-2：DX11でLinuxも影響を受けるの？　あとレンダリングにVulkanはどう？

A3-2：DX11はWindows以外では明らかな変更はなにもない。私たちのエンジンチームは新しいゲームのためにVulkanとDX12で実験しているが、私が知る限りではStellarisについてそうした計画はない。

Q4：前にあなたの開発日記でコンソールコマンド「debug_ai」を使うと軍事AIがなにを考えているかわかるとあったけど、これはリリースされてないの？　軍事AIは今全然機能してないし、すごく必要とされている。

A4：そのコマンドは現在のバージョンでも存在している。オブザーバーモードに切り替えてからAI国家を見る必要がある。

私は輸送処理が現在の艦隊AIで最も弱い部分のように感じる。目標選定を改善する変更を行った（艦隊が長距離移動するのを避ける）が、提示するには早すぎるし、問題の対処になっていないかもしれない。これがAIの難しいところで、与えられた1つのテストケースではうまく動くかもしれないが、他のすべてでは振る舞いが悪くなるリスクもある。

Q5：今後の機能拡張ではゲームの技術的な限界にもっと注意が払われるようになる？　Stellarisは「Megacorp」前（注：タイル制廃止の前）と比べるとまだかなり重い。新機能はいいかもしれないけど、ゲーム終盤が今のように重いままなら、私はあまり楽しいとは思わない。

A5：ゲームスピードについての懸念は承知している。機能は通常、ゲームのパフォーマンスが変わる原因ではない。「Megacorp」以来の大きな影響は無料パッチでの人口システムの変更によるものだ。現在の銀河はそれ以前の4-5倍の人口をシミュレートする必要があり、これにコストがかかっている。

私たちがどうして先に起動速度に注目したかというと、第一に、開発者は開発中にゲームを再起動することが多く（1日に20回以上やっていると思う）、私たちの生産性を高めることができるからだ。第二に、開発日記でも述べたようにこれは他のタイトルと共有でき、Stellarisチームのみならず他のほとんどのパラド社開発スタジオタイトルにとっても有益だからだ。

Q6：ホストで全部計算してクライアントに配信するのではだめなの？

A6：これは時々出てくるアイディアだが、問題は更新中にどのようなデータが変更されたかを識別する効率的な方法と、それを回線を経由して送信する別の効率的な方法が必要になるということだ。これまでのところ、この方法がより効率的であることを証明する実証的な証拠はあまりない。

2020年9月3日追記：開発日記#182はスクリプティングとパフォーマンスに関する技術的な内容となっています。当サイトでは記事にして紹介はしませんので、内容が気になる方は直接フォーラムをご覧ください。

次回：開発日記#183――メモリの割り当て