第4部 現代CPUの悲鳴を聞け! Bevyが提唱する「データ指向(ECS)






第4部 現代CPUの悲鳴を聞け! Bevyが提唱する「データ指向(ECS)」の根源


第4部 現代CPUの悲鳴を聞け!
Bevyが提唱する「データ指向(ECS)」の根源

60歳になってRustを学び始めると、次々と常識が覆されます。

前回は「なぜRustにはClassが存在しないのか」をテーマに取り上げました。

そしてその中で、ECS(Entity Component System)という考え方が登場しました。

私は最初、ECSをただの設計手法だと思っていました。

オブジェクト指向の次に流行った新しいプログラミングスタイル。

その程度の認識だったのです。

しかし調べれば調べるほど、本当の理由はもっと深いところにありました。

ECSは流行ではありません。

設計者の趣味でもありません。

現代コンピュータが抱える物理的な問題への回答だったのです。

そしてその問題とは、

「CPUが速くなりすぎた」

ことでした。

CPUは信じられないほど進化した

私が最初に触ったパソコンは8bit機でした。

CPUクロックは数MHz。
メモリ容量は数十KB。

ゼビウスやギャラガが動くだけでも奇跡のような時代でした。

ところが現在は違います。

ノートパソコンはもちろん、スマートフォンですら数GHzで動作します。

単純比較で数百倍から数千倍以上の性能向上です。

1980年代

数MHz

2020年代

数GHz

CPUだけを見るなら、人類はものすごい成功を収めたと言えるでしょう。

しかしメモリは置いていかれた

ところが問題があります。

CPUは猛烈な速度で進化しました。

しかしメモリのアクセス速度は、それほど劇的には進化していません。

たとえるなら、F1マシンを作ったのに道路が農道のままだったようなものです。

CPU
↓↓↓↓↓↓↓↓↓↓↓↓
超高速

メモリ
↓↓↓
普通

CPUは一瞬で計算できます。

しかし必要なデータがメモリから届くまで待たされる。

実はこれが現代コンピュータ最大のボトルネックなのです。

本当に遅いのは計算ではない

私たちはつい、

ゲームが重い

計算が大変

と思ってしまいます。

しかしCPUから見ると事情は少し違います。

計算そのものは得意です。

むしろ苦手なのは、

データを探し回ること

なのです。

目的のデータが遠くに散らばっていると、その取得に時間を使ってしまいます。

そしてCPUは待機状態になります。

まるで優秀な職人が材料待ちで手を止めているようなものです。

1000体の敵を処理すると何が起きるのか

シューティングゲームを考えてみましょう。

1000体の敵が存在するとします。

各敵は次のようなデータを持っています。

Position

Velocity

Health

Attack

オブジェクト指向の場合、これらの情報は敵ごとにまとまって保存されます。

Enemy1

Enemy2

Enemy3

Enemy4

するとCPUは敵ごとにデータを探しに行かなければなりません。

あちこち飛び回るので効率が悪くなります。

図書館問題で考える

私はこれを図書館で考えると理解しやすくなりました。

100人分のデータがあるとします。

その中から全員の身長だけ調べたい。

オブジェクト指向では本がバラバラの場所に置かれています。

1階

地下

5階

3階

7階

毎回移動しながら探さなければいけません。

非常に非効率です。

ECSでは違います。

身長

身長

身長

身長

身長

すべてのデータがまとめて並んでいます。

一気に読めます。

CPUも同じです。

キャッシュという秘密兵器

CPUには超高速な小型メモリが存在します。

これをキャッシュと呼びます。

L1 Cache

L2 Cache

L3 Cache

CPUは可能な限り、このキャッシュ内だけで仕事を終わらせたいのです。

ところがデータがあちこちに散らばっていると、毎回メインメモリへ取りに行かなければなりません。

そのたびに待ち時間が発生します。

結果としてCPU性能を使い切れなくなるのです。

ECSはCPUを待たせないために生まれた

ここで発想が逆転します。

私は長い間、

ECS

新しい設計パターン

だと思っていました。

しかし本質は違います。

CPUが待たされる

データを並べる

CPUが喜ぶ

ECS

つまりECSはCPU効率を最大化するための構造だったのです。

ゼビウスで考えるとよく分かる

ゼビウスには大量の敵が登場します。

  • ガルザカート
  • トーロイド
  • ドモグラム
  • ザカート

現代的なECSでは、

Positionだけまとめる

Velocityだけまとめる

Healthだけまとめる

という考え方をします。

するとCPUは一直線にデータを読めます。

兵隊1000人が整列している状態と、
1000人が街中に散らばっている状態の違いに似ています。

点呼するなら整列している方が圧倒的に速いのです。

BevyがECSを選んだ理由

RustゲームエンジンBevyは最初からECS中心で設計されています。

その理由はシンプルです。

現代CPUとの相性が抜群だから

です。

ゲーム設計だけを考えた結果ではありません。

CPUアーキテクチャそのものを考慮した結果なのです。

だから大量のオブジェクトを扱うゲームに強い。

だからBevyはECSを中核に据えているのです。

60代だから見える進化

若い世代にとってECSは当たり前かもしれません。

しかし私たちには歴史があります。

  • スペースインベーダー
  • ギャラクシアン
  • ギャラガ
  • ゼビウス
  • Bevy

ゲームの進化を見てきた世代だからこそ分かります。

ECSは単なる流行ではありません。

コンピュータそのものが進化した結果、生まれた必然だったのです。

まとめ

前回は「オブジェクト指向の継承がなぜ苦しくなったのか」を見ました。

今回はさらに深い理由を見てきました。

CPUは速くなった

メモリは追いつかなかった

CPUが待たされる

データを並べる

ECSが生まれた

ECSはプログラマーの流行ではありません。

現代コンピュータの物理的な制約から生まれた設計思想です。

そしてBevyは、その思想をゲーム開発へ持ち込んだエンジンなのです。

次にBevyのコードを見るとき、その裏側でCPUがどれだけ喜んでいるかを想像してみてください。

そこには現代コンピュータ工学の知恵が詰まっています。


コメントする

メールアドレスが公開されることはありません。 が付いている欄は必須項目です