【CEDEC2018】CPUを使い切れ！ Entity Component System（通称ECS）が切り開く新しいプログラミング

CPUを使い切れ！
Entity Component System（通称ECS）
が切り開く新しいプログラミング
ユニティ・テクノロジーズ・ジャパン合同会社
フィールドエンジニア安原祐二

おすすめ資料
https://www.youtube.com/watch?v=eA2t8HBtRzg
https://www.slideshare.net/UnityTechnologiesJapan/gtmf2018tokyounity3
ハードウェアの性能を活かす為の、Unityの新しい3つの機能
動画：
スライド資料：

本講演の対象バージョン
Unity2018.2.2f1
{
"dependencies": {
"com.unity.entities": "0.0.12-preview.8",
"com.unity.package-manager-ui": "2.0.0-preview.3",
"com.unity.modules.ai": "1.0.0",
"com.unity.modules.animation": "1.0.0",
"com.unity.modules.assetbundle": "1.0.0",
"com.unity.modules.audio": "1.0.0",
"com.unity.modules.cloth": "1.0.0",
"com.unity.modules.director": "1.0.0",
"com.unity.modules.imageconversion": "1.0.0",
"com.unity.modules.imgui": "1.0.0",
"com.unity.modules.jsonserialize": "1.0.0",
"com.unity.modules.particlesystem": "1.0.0",
"com.unity.modules.physics": "1.0.0",
"com.unity.modules.physics2d": "1.0.0",
"com.unity.modules.screencapture": "1.0.0",
"com.unity.modules.terrain": "1.0.0",
"com.unity.modules.terrainphysics": "1.0.0",
"com.unity.modules.tilemap": "1.0.0",
"com.unity.modules.ui": "1.0.0",
"com.unity.modules.uielements": "1.0.0",
"com.unity.modules.umbra": "1.0.0",
"com.unity.modules.unityanalytics": "1.0.0",
"com.unity.modules.unitywebrequest": "1.0.0",
"com.unity.modules.unitywebrequestassetbundle": "1.0.0",
"com.unity.modules.unitywebrequestaudio": "1.0.0",
"com.unity.modules.unitywebrequesttexture": "1.0.0",
"com.unity.modules.unitywebrequestwww": "1.0.0",
"com.unity.modules.vehicles": "1.0.0",
"com.unity.modules.video": "1.0.0",
"com.unity.modules.vr": "1.0.0",
"com.unity.modules.wind": "1.0.0",
"com.unity.modules.xr": "1.0.0"
},
"registry": "https://packages.unity.com",
"testables": [
"com.unity.collections",
"com.unity.entities",
"com.unity.jobs"
]
}
Packages/manifest.json→

本講演のプロジェクト
https://github.com/Unity-Technologies/AnotherThreadECS
https://youtu.be/nOeOrJRf5NY
デモ動画

1. 復習　class と struct
2. Nativeコンテナってなんだ
3. C# Job System 概要
4. CPUキャッシュのおさらい
5. ECSの思想に迫る
6. Entity生成　step by step
7. ザ・Burst
8. マルチスレッドのおさらい
9. 最重要！　ComponentDataArray
10.IComponentDataを見極める
11.デモ
12.JobだってEntityを生成したい
13.Entityを追いかけろ！
14.実装！　トレイルレンダリング
15.Jobテクをもうひとつだけ
16.コリジョン作ってみた
17.自作せよ！　Nativeコンテナ
18.選ぶのは８個
19.伝えたい　Entity間通信
20.ECS & Job が奏でる未来
本日のコース

“ ”
１．復習　class と struct

サイズ不定
（継承、文字列型…）
class=参照型
サイズ固定
struct＝値型
(int、Vector3…）

0
1
2
3
4
5
6
7
そもそも配列は
等間隔が必須
参照型はサイズが異なるため
配列に格納できない
配列を考える

0
1
2
3
4
5
6
7
ポインタは等間隔
サイズの異なる実体を別の場所に置く
参照型の配列
メモリはバラバラ

0
1
2
3
4
5
6
7
サイズ一定
メモリは
カタマリになる
値型の配列

“ ”
２．Nativeコンテナってなんだ

• NativeArray
• 通常配列
• ポインタからの変換可能(ConvertExistingDataToNativeArray)
• NativeSlice
• NativeArrayの部分切り出しが可能
• ポインタからの変換可能(ConvertExistingDataToNativeSlice)
• NativeList
• マルチスレッド書き込み非対応
• NativeArray化にメモリコピーを使用しない
• Job中でのサイズ変更後の状態でNativeArray化できる ToDeferredJobArray
• NativeQueue
• いわゆるFIFO。マルチスレッド書き込み対応
• NativeHashmap, NativeMultiHashmap
• Key-Value コンテナ。マルチスレッド書き込み対応
Unmanaged（GCが起きない）メモリを使用したコンテナ

var a = new NativeArray<MyStruct>(32, Allocator.Persistent);
生成
解放
Allocator.Persistent
Allocator.Temp
Allocator.TempJob
永続的に使用可能
同じフレームで解放しないとエラー
４フレーム以内に解放しないとエラー
a.Dispose();
例：NativeArray
フレームの概念が組み込まれている素晴らしさ

var a = new NativeArray<MyStruct>(32, Allocator.Persistent);
var b = new MyStruct[32];
a.CopyTo(b);
生成
コピー（memcpyのloop）
今後NativeArray対応APIは増えていきます
a.CopyFrom(b);
とはいえ通常の配列を要求するUnityのAPIは多い・・・

Nativeコンテナまとめ
• Unityが用意した便利コンテナ
• Managedメモリを使用しない
• Gabage Collection とは無縁
• 実装はMalloc/Freeを使用してメモリ確保
• structで定義されているが概念は参照型（スマートポインタ）に近い
• IL2CPPを想定した効率化が計られている
• 性能測定はビルド後のものを
• ユーザの自作も設計に組み込まれている（後述）

“ ”
３．C# Job System 概要

var th = new System.Threading.Thread(Func);
th.Start();
・これまでもスレッドは自作できた
・Unityが用意したWorkerThreadを使えるように
プロファイラで可視化
安全に書ける（エラーがたくさん出てくれる）
使いやすくなったThread

Worker Thread で動いている

・Main Thread 動作中に実行可能
・メニーコアの有効利用
Camera.Renderなどの不可避な処理の裏はたいてい空いている
WorkerThreadのメリット

３．C# Job System のおさらい
Camera.Render
Camera.Renderの裏で動いている

struct AJob : IJobParallelFor {
public NativeArray<Vector3> positions;
public void Execute(int i) {
var pos = positions[i];
pos.y += 1f;
positions[i] = pos;
}
}
IJobParallelForを実装してExecuteを定義
indexは供給される
Jobが実行する
Uniform的なもの
Jobの書きかた

public void Execute(int id) {
var pos = positions[id];
pos.y += 1f;
positions[id] = pos;
}
}
毎フレームScheduleを呼ぶ
読んでしまったら ajob は破棄して良い
void Update() {
var ajob = new AJob() { positions = m_Positions, };
var handle = ajob.Schedule(positions.Length, 8, );
}
生成
実行指令
データ参照
Jobの呼びかた

pos.y += 1f;
}
}
idは供給される
Jobが実行する
Uniform的なもの
Jobの書きかた
参照なので危険がつきまとう
[ReadOnly]や[WriteOnly]属性をつける

InvalidOperationException: The native container has been
declared as [WriteOnly] in the job, but you are reading from it.
Unity.Collections.LowLevel.Unsafe.AtomicSafetyHandle.Check
ReadAndThrowNoEarlyOut
(Unity.Collections.LowLevel.Unsafe.AtomicSafetyHandle
handle) <0x1472e5a80 + 0x00052> 本当にありがとうございます
出してくれるエラーの例

Scheduleの引数にJobHandleを渡す
void Update() {
var ajob = new AJob() { positions = m_Positions, };
var bjob = new BJob() { positions = m_Positions, };
var handle = ajob.Schedule(positions.Length, 8, );
handle = bjob.Schedule(handle);
JobHandle.ScheduleBatchedJobs();
handle.Complete();
}
ジョブ発行時に依存関係を定義

C# Job Systemまとめ
• 危険なマルチスレッドを回避
• 属性[ReadOnly][WriteOnly]でランタイムチェック
• 依存や同期が簡単に書ける
• 命令の発行(Schedule)や同期(Complete)がメインスレッドからしか呼べない
• デッドロックを起こせない

“ ”
４．CPUキャッシュのおさらい

L2キャッシュ
メモリ
コア
L1
コア
L1
コア
L1
コア
L1
コア
L1
コア
L1
コア
L1
コア
L1
遅い
速い
メモリ・キャッシュ・メニーコア

L2キャッシュ
メモリ
コア
L1
コア
L1
コア
L1
コア
L1
コア
L1
コア
L1
コア
L1
コア
L1
遅い
速い
x10
x20
x200
（※数値は例）
メモリ・キャッシュ・メニーコア

L2キャッシュ
メインメモリ
コア
L164
64
コ
1byteの使用でも
近傍の64bytesが
キャッシュに乗る
配置を最適化すれば
100倍ぐらい速いはず(?)
キャッシュラインは64bytes

“ ”
５．ECSの思想に迫る

Enemy
Position
Rotation
Health
Rigidbody
Position
Rigidbody
Rotation
Position
Rotation
Health
Rigidbody
Position
Rigidbody
Rotation
Renderer
Transform
Matrix
Transform
Matrix
Player
Renderer
Position
Rotation
Health
Transform
Matrix
Missile
Renderer
Position
Rotation
Health
Rigidbody
Position
Rigidbody
Rotation
Transform
Matrix
Enemy
Renderer
Position
Rotation
Health
Transform
Matrix
Missile
Renderer
Position
Rotation
Transform
Matrix
Bullet
Renderer
Position
Rotation
Transform
Matrix
Bullet
Renderer
横の要素をメモリ的に近くに置く

Enemy
Position
Rotation
Health
Rigidbody
Position
Rigidbody
Rotation
Position
Rotation
Health
Rigidbody
Position
Rigidbody
Rotation
Renderer
Transform
Matrix
Transform
Matrix
Player
Renderer
Position
Rotation
Health
Transform
Matrix
Missile
Renderer
Position
Rotation
Health
Rigidbody
Position
Rigidbody
Rotation
Transform
Matrix
Enemy
Renderer
Position
Rotation
Health
Transform
Matrix
Missile
Renderer
Position
Rotation
Transform
Matrix
Bullet
Renderer
Position
Rotation
Transform
Matrix
Bullet
Renderer
Entity（物体）

Enemy
Position
Rotation
Health
Rigidbody
Position
Rigidbody
Rotation
Position
Rotation
Health
Rigidbody
Position
Rigidbody
Rotation
Renderer
Transform
Matrix
Transform
Matrix
Player
Renderer
Position
Rotation
Health
Transform
Matrix
Missile
Renderer
Position
Rotation
Health
Rigidbody
Position
Rigidbody
Rotation
Transform
Matrix
Enemy
Renderer
Position
Rotation
Health
Transform
Matrix
Missile
Renderer
Position
Rotation
Transform
Matrix
Bullet
Renderer
Position
Rotation
Transform
Matrix
Bullet
Renderer
ComponentData（要素）

Enemy
Position
Rotation
Health
Rigidbody
Position
Rigidbody
Rotation
Position
Rotation
Health
Rigidbody
Position
Rigidbody
Rotation
Renderer
Transform
Matrix
Transform
Matrix
Player
Renderer
Position
Rotation
Health
Transform
Matrix
Missile
Renderer
Position
Rotation
Health
Rigidbody
Position
Rigidbody
Rotation
Transform
Matrix
Enemy
Renderer
Position
Rotation
Health
Transform
Matrix
Missile
Renderer
Position
Rotation
Transform
Matrix
Bullet
Renderer
Position
Rotation
Transform
Matrix
Bullet
Renderer
System（共通部分に対する処理）

Enemy
Position
Rotation
Health
Rigidbody
Position
Rigidbody
Rotation
Position
Rotation
Health
Rigidbody
Position
Rigidbody
Rotation
Renderer
Transform
Matrix
Transform
Matrix
Player
Renderer
Position
Rotation
Health
Transform
Matrix
Missile
Renderer
Position
Rotation
Health
Rigidbody
Position
Rigidbody
Rotation
Transform
Matrix
Enemy
Renderer
Position
Rotation
Health
Transform
Matrix
Missile
Renderer
Position
Rotation
Transform
Matrix
Bullet
Renderer
Position
Rotation
Transform
Matrix
Bullet
Renderer
例：RigidbodyPositionSystemが対象とするデータ

ECSまとめ
• メモリ配置を考慮
• ECSに従えば効率の良いデータ配置を実現できる
• System で同一要素を一括処理

“ ”
６．Entity生成　step by step

public struct RigidbodyPosition : IComponentData {
public float3 velocity;
public float3 acceleration;
public float damper;
}
IComponentData は interface
手順１/３・Componentの定義

namespace Unity.Entities
{
public interface IComponentData
{
}
何も書いてない
…/com.unity.entities@0.0.12-preview.8/Unity.Entities/IComponentData.cs

namespace Unity.Transforms
{
public struct Position : IComponentData
{
public float3 Value;
}
}
…/com.unity.entities@0.0.12-preview.8/Unity.Transforms/PositionComponent.cs
ところで、なにか違和感を感じませんか？
例：Positionの定義

通常： struct Vector3
struct Position
struct Velocity
struct AimDirection
様々な意味に使う
構造体が特定の意味ＥＣＳ：
Vector3 position;
Vector3 velocity;
Vector3 aimDirection;
構造体が型ではなく、具体的な意味になる

var entity_manager = World.Active.GetOrCreateManager<EntityManager>();
arche_type = entity_manager.CreateArchetype(typeof(Unity.Transforms.Position)
, typeof(Unity.Transforms.Rotation)
, typeof(Unity.Transforms.TransformMatrix)
, typeof(RigidbodyPosition)
, typeof(RigidbodyRotation)
, typeof(SphereCollider)
, typeof(HitInfoPlayer)
, typeof(Player)
, typeof(Unity.Rendering.MeshInstanceRenderer));
ふつうは起動時にやっておく
手順２/３・ArchType（型）を作る

var entity = entity_manager.CreateEntity(arche_type);
var entity = entity_manager.CreateEntity(arche_type);
var pos0 = new Unity.Transforms.Position { Value = new float3(0,0,0), };
entity_manager.SetComponentData<Unity.Transforms.Position>(entity, pos0);
SetComponentDataで初期化
SetComponentDataがEntityManager経由！
オブジェクト指向との思想の違い
手順３/３・CreateEntityでEntityを作成

Entity生成まとめ
• コンパイル時にComponentDataを定義
• 実行時にArchetypeを定義
• ArchetypeからEntityを生成
• Entityは単なるIDでしかない
• すべてを把握するEntityManager経由で操作する

７．ザ・Burst
高速コード(主にSIMD化による)を生成する特殊コンパイラ
[BurstCompile]
pos.y += 1f;
}
}
何もかも速くなるわけではない
ここがBurstCompileされる

７．ザ・Burst
いつコンパイルしているのか？
なんと実行時
エディタ実行の場合
タイミングをコンソールに出すと・・

７．ザ・Burst
差し替えられるということは
副作用のないプログラムに限定
強い制約を守らないとBurstできない
static 変数にアクセス不能
Managedオブジェクト（通常の参照型）にアクセス不能

７．ザ・Burst
Burstまとめ
• ランタイムに差し替え可能
• 副作用なし
• bssセクションなし
• 常に[BurstCompile]するよう心がけよう
• 自然にプログラムが安全になる
• Debug.Logは使えない（Jobでは可能）
• [BusrtDiscard]を関数に設置することでBusrt時に消滅させられる（デバッグ用）
• e.g. [BurstDiscard] public static void print<T>(T v) { Debug.Log(v); }

“ ”
８．マルチスレッドのおさらい

スレッドＡ
スレッドのリソース
スタックレジスタ
スタックとレジスタはスレッド固有
プログラム言語におけるオート変数に相当
スレッドB スタックレジスタ
スレッドC スタックレジスタ
スレッドD スタックレジスタ

スレッドＡ
CPUひとつでマルチスレッド
スタックレジスタ
リソースを切り替える（コンテキストスイッチ）
スレッド切り替えはカーネルのお仕事
スレッドB スタックレジスタ
スレッドＡのレジスタを退避
スレッドＢのレジスタを復帰
いつ行われるのか？

int add(int a, int b)
{
return a + b;
}
.section __TEXT,__text,regular,pure_instructions
.macosx_version_min 10, 13
.globl __Z3addii ## -- Begin function
_Z3addii
.p2align 4, 0x90
__Z3addii: ## @_Z3addii
.cfi_startproc
## BB#0:
pushq %rbp
Lcfi0:
.cfi_def_cfa_offset 16
Lcfi1:
.cfi_offset %rbp, -16
movq %rsp, %rbp
Lcfi2:
.cfi_def_cfa_register %rbp
movl %edi, -4(%rbp)
movl %esi, -8(%rbp)
movl -4(%rbp), %esi
addl -8(%rbp), %esi
movl %esi, %eax
popq %rbp
retq
.cfi_endproc
## -- End function
.subsections_via_symbols
Ｃ言語のコンパイル結果
オレンジ色は
有効な命令
コンパイル方式のプログラムは
例外なくこの形式で実行される

.section __TEXT,__text,regular,pure_instructions
.macosx_version_min 10, 13
.globl __Z3addii ## -- Begin function
_Z3addii
.p2align 4, 0x90
__Z3addii: ## @_Z3addii
.cfi_startproc
## BB#0:
pushq %rbp
Lcfi0:
.cfi_def_cfa_offset 16
Lcfi1:
.cfi_offset %rbp, -16
movq %rsp, %rbp
Lcfi2:
.cfi_def_cfa_register %rbp
movl %edi, -4(%rbp)
movl %esi, -8(%rbp)
movl -4(%rbp), %esi
addl -8(%rbp), %esi
movl %esi, %eax
popq %rbp
retq
.cfi_endproc
## -- End function
.subsections_via_symbols
スレッド切り替えの発生ポイント
いつでも発生しうる
大丈夫なように作るスレッドセーフ

スレッドセーフでない　とは？
オート変数以外のメモリにアクセスしているのに
マルチスレッドを考慮していない状態
スレッドＡスタックレジスタ
メモリ
スレッドＢスタックレジスタ
スレッドＤスタックレジスタ
スレッドＣスタックレジスタ

この関数はスレッドセーフか？
{
return a + b;
}

この関数はスレッドセーフか？
{
return a + b;
}
セーフ！
オート変数しか使用していない
副作用がない

スレッドセーフでない関数
int add(int a)
{
static int p = 0;
p += a;
return p;
}
アウト！
static変数はスレッド間で共有されてしまう
副作用がある

何が起きるのか？
static int p;
p += a;
１：pをメモリから読み込む
２：読み込んだ値にaを加える
３：加えた値をpに書き込む

何が起きるのか？
スレッドＡスレッドＢ
スレッド切り替え
スレッド切り替え
スレッドＢの処理が無効となるバグ
static int p;
p += a;

スレッドセーフまとめ
• オート変数を使う
• スタックおよびレジスタはスレッドローカル
• 副作用が必要ならスレッドセーフ、機構を実装する（後述）
• マルチコアも事情は同じ
• L1キャッシュの動作に関してはマルチコア特有の事情を考慮する
• 学習としてはまずマルチスレッドを押さえよう

“ ”
９．最重要！　ComponentDataArray

Systemの記述
public class MySystem : JobComponentSystem {
// ここで Inject を受ける記述
protected override void JobHandle OnUpdate(JobHandle inputDep) {
// ここで実行
}
}
ECSの実行機構

Systemの記述
MonoBehaviour→JobComponentSystem
Update→OnUpdate に対応
ただしインスタンスは見えない
// ここで Inject を受ける記述
// ここで実行
}
}

Inject する
InjectによりComponentDataArrayの準備が整う
OnUpdateの前に毎フレーム働く
struct MyGroup {
ComponentDataArray<Foo> foos;
…
}
[Inject] MyGroup group;
// ここで実行
}
}

Jobに渡ったComponentDataArray
…
struct MyJob : IJobParallelFor {
public void Exec(int i) {
// 処理
}
}
// ここでComponentDataArrayを渡したジョブをスケジュール
}
}

ComponentDataArray は只者ではない
不連続なデータに効率的にアクセス
Chunk
Chunk
Chunk
…
Foo f = foos[i]
内部のキャッシュ機構で効率化

ComponentDataArray は只者ではない
不連続なデータに効率的にアクセス
Chunk
Chunk
Chunk
…
Foo f = foos[i]
内部のキャッシュ機構で効率化
ちょっと待て・・・それはスレッドセーフなのか？

実行スレッドごとにコピーが作られる(!)
よって内部キャッシュはスレッドローカル
Chunk
Chunk
Chunk
…
Foo f = foos[i]
…
Foo f = foos[i]
…
Foo f = foos[i]
スレッドセーフ!
スレッドＡスレッドBスレッドC

ReadとWriteの記述
Foo foo = foos[i]; // read
// 処理
foos[i] = foo; // write
}
}
foos[i].value = 10;
のような書き方は許可されない
インデクサは単純なアクセサではない

[ReadOnly] ComponentDataArray<Foo> foos;
// 処理
}
}
[ReadOnly] の場合は
コピーを取り出すのみ

[WriteOnly] ComponentDataArray<Foo> foos;
// 処理
}
}
[WriteOnly] の場合は
新規生成を書き込むのみ
e.g. foos[i] = new Foo();

ComponentDataArrayまとめ
• Nativeコンテナの一種
• [Inject]されることで利用可能
• 内部のデータは必ずしも連続ではない
• とびとびというわけでもなく、時々ギャップがあるぐらい
• 内部キャッシュで効率化
• それでもスレッドセーフ
• ジョブ構造体ごと実行スレッド用にコピーされており、キャッシュが独立しているため
• アクセスは構造体単位。部分的なメンバーへのアクセスはできない
• ただし JobComponentSystem を使うと特定箇所のアクセスが可能
• JobComponentSystem が速度的に有利（とドキュメントに書いてある）な理由
• ただしJobComponentSystemは３種類のIComponentDataしか扱えない（現在）

“ ”
10．IComponentDataを見極める

IComponentDataに書けるもの/書けないもの
public unsafe struct MyComponent : IComponentData {
public int i; // OK
public string str; // NG （参照型）
public byte* ptr; // OK (要unsafe)
public bool flg; // NG (non blittable)
public NativeArray na; // NG
public ﬁxed int fa[256]; // OK (要unsafe)
}
要するにblittableかどうか

IComponentDataまとめ
• blittable なもののみ定義可能
• unsafe にすれば pointerも可能
• unsafe はもう恐れない（基盤側で使いまくっている）
• NativeArray は定義不可
• 内部のDisposeSentinelという開発支援機構がReference型
• 自作のNativeContainerはその点に気をつければ定義可能
• 固定サイズバッファ(Fixed Size Buﬀers)はunsafeで定義可能
• ただし型の制限が厳しい。以下の型のみで float3 などは使用できない（C#の制限)
• bool, byte, short, int, long, char, sbyte, ushort, uint, ulong, float or double
• ﬁxed bool flg[32];
• C#上は許可されるがnon-blittableなのでIComponentData上はランタイムエラー

“ ”
12．JobだってEntityを生成したい

並列実行中にEntityを生成・削除できるものなのか？
できません
AddComponentやRemoveComponentも不可

並列実行でEntityを追加するには
コマンドキューに積む：
すべてのJobを停止してキューを実行する：
EntityCommandBuﬀer
BarrierSystem
正確にはキュー実行時にEntityManagerがJob完了待ちをする

BarrierSystem の Inject
public class MySystem : ComponentSystem {
struct MyGroup {
}
class MyBarrier : BarrierSystem {}
[Inject] MyBarrier barrier;
System内に定義して[Inject]する

BarrierSystemからEntityCommandBufferを生成
class MyBarrier : BarrierSystem {}
[Inject] MyBarrier barrier;
protected override JobHandle OnUpdate(JobHandle dep) {
var combuf = barrier.CreateCommandBuffer();
var job = new MyJob {
commandbuffer = (EntityCommandBuffer.Concurrent)combuf;
Concurrent版をJobに渡す

EntityCommandBuﬀerは遅延実行用のキュー
internal enum ECBCommand {
CreateEntity,
DestroyEntity,
AddComponent,
RemoveComponent,
SetComponent,
AddSharedComponentData,
SetSharedComponentData
}
可能なのはこれだけ

遅延実行ということは・・・
public void CreateEntity(EntityArchetype archetype)
返り値は得られないよね
public void SetComponent<T>(T component) where T : struct, IComponentData
直前に生成したEntityに対して実行

EntityCommandBuﬀer まとめ
• 遅延実行であることに留意しよう
• EntityManagerと同じインタフェースにはならない
• Concurrentによる並列実行が可能（できるようになったのはわりと最近）
• Entityの構造変化(Create, Destroy, AddComponent, RemoveComponent, …)は
ジョブの完全停止が必要
• BarrierSystemで実行
• Entityが格納されるバッファはCapacityを越えると倍にしてmemcpyする
• 起動時に EntityManager.EntityCapacity を想定最大値に設定するとよい
EntityManager tips

BarrierSystem まとめ
• Injectすることで定義した場所（System)の直後に実行される
• Barrierは継承して使用すべし
• 継承したBarrierにはわかりやすい名前をつけておくとよい
• プロファイラでBarrierの名前が見える

“ ”
13．Entityを追いかけろ！
ComponentDataFromEntity

13．Entityを追いかけろ！　ComponentDataFromEntity
ロックオンターゲットを追尾したい
追尾レーザーはロックオンターゲットのEntityを保持
public struct LaserData : IComponentData
{
…
public Entity target_entity_;
…

ComponentDataFromEntity
public class LaserSystem : JobComponentSystem
{
[Inject] [ReadOnly] public ComponentDataFromEntity<Position> position_list_from_entity_;
…
…
var target_pos = position_list_from_entity_[ld.target_entity_];
Entityを引数にしてComponent取得
Inject で利用可能に

ExistsでEntityの存在確認がジョブからでも可能
ゲームプログラムにおける超重要機能
…
[ReadOnly] public ComponentDataFromEntity<Position> position_list_from_entity_;
…
if (!position_list_from_entity_.Exists(ld.target_entity_)) {
…

ComponentDataFromEntity まとめ
• Nativeコンテナの一種
• Injectして使う
• 任意のEntityからComponentを取得できる
• ジョブの中でEntityの存在をチェック可能

“ ”
14．実装！　トレイルレンダリング

いかにしてIComponentDataで点群を実現するか
Fixed Size Buﬀersは・・・
public ﬁxed float points[256];
IComponentDataはコピーされる宿命にある
あまり大きなバッファを起きたくない
そもそもfloat3などを書けない

そんなときはFixedArrayArray（注）
ただの構造体を定義
public struct TrailPoint {
public float3 position;
public float3 normal;
}
archetype_ = entity_manager.CreateArchetype(
typeof(Destroyable)
…
, ComponentType.FixedArray(typeof(TrailPoint), 64));
Archetype定義でFixedArrayを使う

〜注意〜
より高機能なDynamicBuﬀersが登場
FixedArrayArray は廃止されます
とにかくEntityにもバッファを配置できますよ、という話

FixedArrayArray を Injectして使う
public class TrailSystem : JobComponentSystem{
struct Group {
public FixedArrayArray<TrailPoint> trail_points_list_;
}
[Inject] Group group_;
固定長配列がEntityぶんある
二次元配列

Jobで使用する例
public FixedArrayArray<TrailPoint> trail_points_list_;
var trail_points = trail_points_list_[i];
for (var j = 0; j < trail_points.Length; ++j) {
var tp = trail_points[j];
…
Entity毎に固定長配列を入手できた
このとき trail_points はNativeArray

FixedArrayArrayまとめ
• 複数のコンポーネントを同一Entityに配置したい場合にも使用を検討してよい
• インデクサで返されるのはNativeArray
• 保持メモリの部分参照をNativeArray化
• 確保されたものではないのでDisposeを呼ぶとクラッシュする（はず）
• 部分アクセスが可能
• IComponentData単位でのコピーから逃れられる
• Componentと同じくチャンクに格納される
• Entityひとつのサイズ上限（現在は16KiBらしい）があるため無茶はできない
• 要素数が多ければ固定サイズバッファより利便性も効率も高いはず
• FixedArrayArrayは廃止されるが当面使う分には問題ない
• あとでDynamicBuﬀersに置き換えれば良い

“ ”
15．Jobテクをもうひとつだけ

Jobに参照型(Managedメモリ)は渡せない
struct MyJob : IJob {
public List<Vector3> vertices; // 実行時エラー
…
しかし static 関数にはアクセスできる

どこかにオブジェクトを定義しておけば
struct MyJob : IJob {
public void Execute() {
List<Vector3> list = Foo.GetList();
…
staticでアクセス可能(!)
public static class Foo {
static List<Vector3> list;
public static GetList() { return list; }
…

MainThread
トレイルレンダラの頂点生成
List<T>に頂点情報を生成
vertices normals uvs triangles

WorkerThread
Job化
メインスレッドからオフロード＆並列化
vertices
MainThread
WorkerThread normals
WorkerThread uvs
WorkerThread triangles
vertices normals uvs triangles

頂点生成をバックスレッド化する前

頂点生成をバックスレッド化した後
0.49ms
0.024ms

C# Job System テクニックまとめ
• Busrtをあきらめれば意外と制限は緩い
• static や Managedメモリを扱う場合は慎重に
• なるべくBurstを心がけて安全に
• 並列Entity生成において、Material（つまりManagedオブジェクト)を保持する
ISharedComponentDataを扱いたい場合はBurstを切ることで可能になる

“ ”
16．コリジョン作ってみた

コリジョン仕様
特定の組み合わせで総当たり
プレイヤーエネミー
エネミー弾プレイヤー弾

戦略
空間を分割して総当たりコストを減らす
NativeMultiHashmap を使う

所属グリッドを量子化で決定、ハッシュ値を取る
ハッシュ値の算出はサンプルの実装を利用
https://github.com/Unity-Technologies/EntityComponentSystemSamples.git
EntityComponentSystemSamples/Samples/Assets/GameCode/Samples.Common/Utilities/HashUtility.cs

同一ハッシュ値に従い、コリジョン判定を実行
ハッシュの衝突については問題にならない

NativeMultiHashMap
Positionからハッシュ値を生成してキーにする
101 231 473 534 343 56 472 354キー
同一ハッシュに属する集団を取得できる

周囲のグリッドにまたがっている場合も考慮
コリジョンには大きさがある

コリジョンを取る前にNativeArrayにコピーしてしまうテクニック
並列アクセス用のクラスを別にする
var colliders = new NativeArray<SphereCollider>(player_group.Length,
Allocator.TempJob,
NativeArrayOptions.UninitializedMemory);
var job = new CopyComponentData<SphereCollider> {
Source = player_group.sphere_collider_list,
Results = colliders,
};
var handle = job.Schedule(len, 32, handle);
ComponentDataArrayの使用が早期に終了するメリット

コリジョン実装まとめ
• 総当たりコストを軽減する
• NativeMultiHashMapは並列処理に対応
• Positionからハッシュ値を生成する
• ハッシュ値がぶつかっても問題ない。運悪くコリジョン判定が増えるだけ
• コリジョンに大きさがあることに注意
• 周辺セルにも登録する。多重登録は問題ない
• 場合によっては総当たりで十分な場合もある
• 一時的なNativeArrayにコピーすることで効率を上げられる可能性
• 数が多い場合など
• NativeArrayはIL2CPP環境において最大効率（zero-overhead)を実現している

“ ”
17．自作せよ！　Nativeコンテナ

Spriteをまとめて描画したい
並列で格納したい
描画発行を高速化したい
これ

Nativeコンテナ典型パターンその１
ポインタでデータを扱う
public unsafe struct NativeBucket {
byte* m_HeaderBlock;
}
基本的にコピーして扱われるので
変動するデータはすべてポインタの先に格納する

Nativeコンテナ典型パターンその２
並列アクセス用のクラスを別にする
public unsafe struct Concurrent {
}
}
並列アクセス用のインタフェースを Concurrent だけに置く

Nativeコンテナ典型パターンその３
秘技[NativeSetThreadIndex]
で実行中のスレッドを特定する
public unsafe struct Concurrent {
}
[NativeSetThreadIndex] int m_ThreadIndex;
}

スレッドがわかっていれば・・
スレッドＡ
スレッドB
スレッドC
スレッドD
メモリ
アクセス領域を分離できるスレッドセーフ
JobsUtility.MaxJobThreadCountでスレッド最大数を取得可能

さらに効率を求めて
スレッドＡ
スレッドB
スレッドC
スレッドD
メモリ
64bytes
64bytes
64bytes
64bytes
アクセス領域を64bytes以上離す
L1キャッシュの競合を避ける
JobsUtility.CacheLineSizeでキャッシュラインサイズを取得可能

NativeBucket実装
スレッドＡ
スレッドB
スレッドC
スレッドD
最大効率で並列追加＆描画コマンド生成
data
data
data
data data data
memcpy
描画

Nativeコンテナ自作まとめ
• ポインタの理解は必須
• C言語のポインタを習得すればOK
• ジョブの使用に限定することでNativeSetThreadIndexによるスレッドセーフが容易に実現
• 汎用的に作る場合lock-freeアルゴリズム（後述）の理解も必要
• 事実上lockは使えない
• メモリをスレッドで分離する実装だとCapacityなどで事前確保するのは難しい
• NativeQueueにCapacityがない理由
• DisposeSentinelなどのセーフティ機構は可能な限り取り入れる
• 積極的にTestを書こう
• レースコンディションを確認するためのtorture testは必須
• Test RunnerのEditModeでもジョブが動作する（！）
• 始める際にはサンプルを参照：
• https://github.com/Unity-Technologies/EntityComponentSystemSamples/blob/master/Samples/Assets/NativeCounterDemo/NativeCounter.cs
•実装が見えているNativeQueue.csなども参考になる
•NativeArrayは公開ソースコードで UnityCsReference/Runtime/Export/NativeArray/NativeArray.cs

“ ”
18．選ぶのは８個

ロックオンターゲット
ロックオンできる数には上限を設けたい

条件を満たす物体のうち8個の状態を変更したい
それを並列で実行したい
難易度高

８匹まで
難易度高！
あらよ
ちょ・・
いけるッ
・・・
いらすとや

NativeLimitedCounter を自作
元気よくポインタを定義
public unsafe struct NativeLimitedCounter {
[NativeDisableUnsafePtrRestriction] int* m_Counter;
[NativeDisable… はジョブに渡すために必要

NativeLimitedCounter のコンストラクタ
UnsafeUtility.Malloc で確保
public unsafe struct NativeLimitedCounter {
[NativeDisableUnsafePtrRestriction] int* m_Counter;
Allocator m_AllocatorLabel;
public NativeLimitedCounter(Allocator label) {
m_AllocatorLabel = label;
long size = UnsafeUtility.SizeOf<int>();
m_Counter = (int*)UnsafeUtility.Malloc(size, 16, label);
UnsafeUtility.MemClear(m_Counter, size);
}

Interlocked.CompareExchange
いわゆる CAS(Compare And Swap)
public bool TryIncrement(int inclusive_limit) {
int current = *m_Counter;
while (current < inclusive_limit) {
int next = current + 1;
int prev = Interlocked.CompareExchange(ref *m_Counter, next, current);
if (prev == current) {
return true;
} else {
current = prev;
}
}
return false;
}

Lock Free アルゴリズム
public bool TryIncrement(int inclusive_limit) {
int current = *m_Counter; // メモリから読み込み(4byteなのでatomicと想定）
while (current < inclusive_limit) { // 引数の制限以下なら
int next = current + 1; // 増加後の値
int prev = Interlocked.CompareExchange(ref *m_Counter, next, current);
if (prev == current) { // 想定通りだった
return true; // 成功、終了
} else { // 想定と異なる。再入が発生している！
current = prev; // 比較するレジスタをメモリの状態で更新してやり直し
}
}
return false;
}

ジョブ実装
TryIncrementが成功したらロックオン成立
[BurstCompile]
struct LockonJob : IJobParallelFor {
public NativeLimitedCounter lc;
…
bool can_lock = …
if (can_lock) {
if (lc.TryIncrement(8)) {
ロックオン処理
…

Systemで生成してジョブに流す
毎フレーム生成して使用する
public class PlayerSystem : JobComponentSystem {
NativeLimitedCounter lockon_limit_;
protected override JobHandle OnUpdate(JobHandle inputDeps) {
if (lockon_limit_.IsCreated) { lockon_limit_.Dispose(); }
lockon_limit_ = new NativeLimitedCounter(Allocator.TempJob);
var sumup_job = new SumupJob { lockon_limit_ = lockon_limit_, };
handle_ = sumup_job.Schedule(lockon_group_.Length, 32, handle_);
var lockon_job = new LockonJob { lockon_limit_ = lockon_limit_,};
handle_ = lockon_job.Schedule(lockon_group_.Length, 32, handle_);
現在の数
を計上
上限まで
ロックオン処理

Lock Freeアルゴリズムまとめ
• Nativeコンテナの思想に沿って実装しよう
• ポインタ先のメモリを意識しよう
• Interlocked.CompareExchange の性質を理解しよう
• テストを書こう

“ ”
19．伝えたい　Entity間通信

一体に複数のターゲットが配置される
ロックオンの基本

親子関係は仕組みが用意されている（注）
TransformSystemが解決してくれる
親
子
子
子
archetype_ = entity_manager.CreateArchetype(
typeof(Destroyable)
, typeof(LockTarget)
, typeof(TransformParent)
, typeof(LocalPosition)
, typeof(LocalRotation)
, typeof(Position)
, typeof(Rotation)
, typeof(TransformMatrix));

〜注意〜
より効率の良い LocalToWorld などの仕組みに
親子関係の仕組みは刷新されます
とにかく親子関係は作れますよ、という話

ダメージ情報をどうやって親に伝えるか
レーザーも並列で計算されている
親
子
子
子
レーザーが命中！

AtomicFloatの実装
public float add(float value) {
float current = UnsafeUtility.ReadArrayElement<float>(m_Data, 0 /* index */);
int currenti = math.asint(current);
for (;;) {
float next = current + value;
int nexti = math.asint(next);
int prev = Interlocked.CompareExchange(ref *(int*)m_Data, nexti, currenti);
if (prev == currenti) {
return next;
} else {
currenti = prev;
current = math.asfloat(prev);
}
}
} Interlocked.Add は整数のみなので自作

LockFreeオブジェクトを作る
多数必要なので工夫する
親
子
子
子

自作 AtomicFloatResource
AtomicFloatを振り出せる仕組み
AtomicFloatResource
AtomicFloat
AtomicFloat
AtomicFloat

共有メモリをLockFreeでアクセス
ダメージの累積を正しく認識
親
子
子
子
レーザーが命中！
AtomicFloat
AtomicFloat
AtomicFloat
AtomicFloat

AtomicFloatの工夫
AtomicFloatResourceを埋め込む
破棄にAtomicFloatResourceが必要
破棄済みかどうかがわからない

AtomicFloatResourceを埋め込めば自己破壊可能
Nativeコンテナの思想で作ってあればコピー可能
AtomicFloatResource
AtomicFloat
AtomicFloat
AtomicFloat
AtomicFloatResource
AtomicFloatResource
AtomicFloatResource
AtomicFloatResource
AtomicFloatResource
AtomicFloatResource
AtomicFloatResource
AtomicFloatResource

Entity間通信オブジェクトAtomicFloatResourceまとめ
• 小さなメモリ確保をしないことで断片化を抑制
• 破棄済みかを自己判定できる仕組み
• スロット再利用との区別もしている
• 破棄も任意のタイミングで呼べる
• DisposeはDestructor的なタイミングで呼ばれるべき
• 現状は明示的にDisposeを呼んでいるため解放もれなどのミスを犯しやすい
• ISystemStateComponentData を利用した ReactiveSystem を検討すべき
• .NetではCompareExchangeにfloat(Single)版が用意されているが、これの使用をBurstは許
可していない。cmpxchg(x86系)などの命令がfloatレジスタに対応していないので、いずれにせ
よ整数レジスタに値を移動する必要があるからだろう。そもそもInterlocked.Addにfloat版が用
意されていないのも同様の理屈と思われる。なおUnity.Mathematicsには整数レジスタと浮動
小数レジスタの相互変換をサポートする math.asfloat および math.asint が用意されている

“ ”
20．ECS & Job が奏でる未来

•従来の仕組みがなくなるわけではない
•作りやすさは正義！
•性能はゲームの商品価値のほんの一部
•パフォーマンスに目をとらわれ過ぎぬよう
•「Jobを使用しない単体のECS」は決して難しくはない
•ECSだけでも検討の価値あり
•高みを目指せば難易度は上がる
•Unityを使いながら高みを目指せる
•パフォーマンスを理由にエンジンを採用する時代に

4msec
性能例：今回のデモを iPhone X で実行

【CEDEC2018】CPUを使い切れ！ Entity Component System（通称ECS）が切り開く新しいプログラミング

Recommended

More Related Content

What's hot (20)

Similar to 【CEDEC2018】CPUを使い切れ！ Entity Component System（通称ECS）が切り開く新しいプログラミング (20)

More from Unity Technologies Japan K.K. (20)