SpringBoneのJobSystem化でわかったこと
はじめに
Unityで揺れもの動かすの、重くない...?
ということで最近ちょこちょこ作っているのがuSpringBone。以下のやつ。
揺れもの用のBoneを揺らすSpringBoneの計算処理をJobSystem使ってごっそりWorkerThreadに持っていこうというのがコンセプトです。
ベース部分しか作っていないのでまだまだ未完成なんですが、JobSystemを使う上で気をつけるべき事がわかってきたのでメモがてら色々書き残しておこうと思います。
ちなみにuSpringBoneは試行錯誤しながら場当り的に書いたので、今後ちゃんと作るとしたらよりパフォーマンスを改善するために色々変わると思います。というか変えてます。
ちょっと前の検証結果ですが、パフォーマンスの変化はこんな感じ。
パフォーマンス改善大分成果が出てきた。
— Es (@Es_Program) 2018年6月27日
①某所SpringBone
②IJobParallelForTransformで1つのJobとして処理
③IJobParallelForTransformで複数のJobとして処理
④今作ってるやつ
MainThreadのScript占有時間だけでなくMainThreadのWait時間に注目。 pic.twitter.com/OM6MbsvEIg
JobSystemで揺れものテスト。
— Es (@Es_Program) 2018年7月9日
ベース部分のみ。これからロジック改良する。
パフォーマンス的には結構よくなった気がする。
IJobParallelForTransformさえなんとかなればなぁ...もっと高速化できるんだけど...https://t.co/V7vaN1DFhL pic.twitter.com/rXriqpmwyI
35体のユニティちゃん(CRSモデル)のSpringBone負荷。左は最適化前で右が最適化後。
— Es (@Es_Program) 2018年7月27日
SpringBoneの設定や処理内容は同じ。
もっと速くなる。もっといける。 pic.twitter.com/pHhtQLwKQ1
因みに
- Unity: 2018.1.0f2
- Burst: 0.2.4 Preview
で開発してます。
さて、今回はuSpringBoneの基盤を作ってく上で得たJobSystemの知識についてとか、気をつけておきたいこととか、そこらへんをメモしておこうと思います。あくまで現状のJobSystemについてのメモなので、今後色々変わると思います。
エディタと実機での負荷計測
JobSystemを使う上で、実機だとそこまで高負荷にならないような部分がエディタ上では負荷が高く見える事があるので注意が必要です。
一部処理については、UnityのJobsメニューから各種チェックを外したりすれば多少実機での実行速度に近付きますが、ちゃんとした計測は実機で行うことをお勧めします。
Jobはなるべく減らす
Jobは可能な限り減らしましょう。 当然ですが、JobをScheduleするのにも多少コストがかかります。 Jobを細分化しすぎると、JobのScheduleがちょっとした負荷になってしまう場合があります。
using UnityEngine; using Unity.Collections; using Unity.Jobs; using Unity.Burst; using UnityEngine.Profiling; using System.Threading; namespace Es.JobSystem.Sample._01 { public class JobSystemSample01 : MonoBehaviour { struct JobA : IJob { public void Execute() { Thread.Sleep(System.TimeSpan.FromMilliseconds(0.1)); } } public void Update() { const int JobCount = 1000; var job = new JobA(); JobHandle[] jobHandles = new JobHandle[JobCount]; Profiler.BeginSample(">> Schedule"); for(int i = 0; i < JobCount; ++i) jobHandles[i] = job.Schedule(); Profiler.EndSample(); JobHandle.ScheduleBatchedJobs(); for(int i = 0; i < JobCount; ++i) jobHandles[i].Complete(); } } }
阿保みたいな例ですが、上記コードは適当なJobを1000個Scheduleしてみるやつです。
とりあえずエディタとビルド後で実行してプロファイラーでScheduleの負荷を計測してみました。
これくらいだと「そこまで高負荷じゃないじゃん!」と思われるかもしれませんが、塵も積もればです。 せっかくJobSystemに重い計算処理を退避させるので、MainThreadにはちょっとでも楽させてあげたいところ。
上記のような簡単な例だと、単純にIJobParallelFor
を使って以下のように書き換えられます。
using UnityEngine; using Unity.Collections; using Unity.Jobs; using Unity.Burst; using UnityEngine.Profiling; using System.Threading; namespace Es.JobSystem.Sample._01 { public class JobSystemSample01 : MonoBehaviour { struct JobA : IJobParallelFor { public void Execute(int index) { Thread.Sleep(System.TimeSpan.FromMilliseconds(0.1)); } } public void Update() { const int JobCount = 1000; var job = new JobA(); Profiler.BeginSample(">> Schedule"); var jobHandle = job.Schedule(JobCount, 32); Profiler.EndSample(); JobHandle.ScheduleBatchedJobs(); jobHandle.Complete(); } } }
当然、Schedule呼び出し回数が減ったのでMainThreadに掛かる負荷が少なくなりました。
ただし、今回のように単純には解決できないケースもあります。というより殆どがそういったケースだと思います。 Jobがあまりにも多くなる場合はより良い設計を考え直しましょう。
NativeContainerへのアクセスについて
下記2つのスクリプトを実行して、NativeArrayへのアクセス部分の負荷の変化を見てみました。
using UnityEngine; using Unity.Collections; using Unity.Jobs; using Unity.Burst; using UnityEngine.Profiling; using System.Threading; using Unity.Jobs.LowLevel.Unsafe; namespace Es.JobSystem.Sample._01 { public class JobSystemSample01 : MonoBehaviour { struct JobA : IJob { [WriteOnly] public NativeArray<int> rand; public void Execute() { var random = new System.Random(); for(int i = 0; i < rand.Length; ++i) rand[i] = random.Next(0, 100); } } public void Update() { var rand = new NativeArray<int>(100000, Allocator.Temp); var job = new JobA() { rand = rand }; Profiler.BeginSample(">> Schedule"); var jobHandle = job.Schedule(); Profiler.EndSample(); JobHandle.ScheduleBatchedJobs(); jobHandle.Complete(); var sum = 0; Profiler.BeginSample(">> Access"); for(int i =0; i < rand.Length; ++i) sum += rand[i]; Profiler.EndSample(); Debug.Log(sum); rand.Dispose(); } } }
using UnityEngine; using Unity.Collections; using Unity.Jobs; using Unity.Burst; using UnityEngine.Profiling; using System.Threading; using Unity.Jobs.LowLevel.Unsafe; namespace Es.JobSystem.Sample._01 { public class JobSystemSample01 : MonoBehaviour { struct JobA : IJob { [WriteOnly] public NativeArray<int> rand; public void Execute() { var random = new System.Random(); for(int i = 0; i < rand.Length; ++i) rand[i] = random.Next(0, 100); } } public void Update() { var rand = new NativeArray<int>(100000, Allocator.Temp); var job = new JobA() { rand = rand }; Profiler.BeginSample(">> Schedule"); var jobHandle = job.Schedule(); Profiler.EndSample(); JobHandle.ScheduleBatchedJobs(); jobHandle.Complete(); var sum = 0; var tmp = new int[rand.Length]; rand.CopyTo(tmp); Profiler.BeginSample(">> Access"); for(int i =0; i < rand.Length; ++i) sum += tmp[i]; Profiler.EndSample(); Debug.Log(sum); rand.Dispose(); } } }
2つのコードの違いはNativeArrayに直接アクセスするか、配列にコピーしてアクセスするかです。
要素数及びアクセス回数が多ければ多いほど、配列にコピーしてそちらを使うようにした方がいいです。
ちなみにNativeArray.CopyTo自体のコストを計測すると
コピーのコスト合わせても、NativeArrayのインデクサーから各要素にアクセスするより安定して速いです。
ちなみにrand
やtmp
のアクセス回数を増やし、それぞれ該当箇所を
sum = rand[i] + rand[i];
sum = tmp[i] + tmp[i];
としてBuildして計測したところ、以下のようになりました。
コピー安定かなと思います。
ちなみに、アクセス部分をunsafeコードに置き換えて以下のような感じにしてみます。
unsafe { var ptr = (int*)rand.GetUnsafeReadOnlyPtr(); Profiler.BeginSample(">> Access"); for (int i = 0; i < rand.Length; ++i) sum += *(ptr + i); Profiler.EndSample(); }
コピーの必要がない上高速なので、使えるのであればガシガシ使っていきたいところ。 uSpringBoneはガシガシ使う方針にしました。
2018-08-31 追記
using UnityEngine; using Unity.Collections; using Unity.Jobs; using Unity.Burst; using UnityEngine.Profiling; using System.Threading; using Unity.Jobs.LowLevel.Unsafe; using Unity.Collections.LowLevel.Unsafe; namespace Es.JobSystem.Sample._01 { public class JobSystemSample01 : MonoBehaviour { struct JobA : IJob { [WriteOnly] public NativeArray<int> rand; public void Execute() { var random = new System.Random(); for(int i = 0; i < rand.Length; ++i) rand[i] = random.Next(0, 100); } } public void Update() { var rand = new NativeArray<int>(300000, Allocator.Temp); var job = new JobA() { rand = rand }; Profiler.BeginSample(">> Schedule"); var jobHandle = job.Schedule(); Profiler.EndSample(); JobHandle.ScheduleBatchedJobs(); jobHandle.Complete(); var sum = 0; var tmp = new int[rand.Length]; rand.CopyTo(tmp); Profiler.BeginSample(">> Access"); for(int i = 0; i < rand.Length; ++i) sum += rand[i]; Profiler.EndSample(); Debug.Log(sum); sum = 0; Profiler.BeginSample(">> Access Copy"); for(int i = 0; i < rand.Length; ++i) sum += tmp[i]; Profiler.EndSample(); Debug.Log(sum); unsafe { sum = 0; var ptr = (int*)rand.GetUnsafePtr(); Profiler.BeginSample(">> Access Unsafe Pointer"); for(int i = 0; i < rand.Length; ++i) sum += *(ptr + i); Profiler.EndSample(); Debug.Log(sum); } rand.Dispose(); } } }
上記コードをIL2CPP環境でScript Debuggingをfalseにし、StandaloneでビルドしてProfilerで測定した結果、以下のようになりました。
小さくて見辛いですが、NativeArrayへのアクセス速度はインデクサーを用いた一般的なアクセスが一番高速でした。
また、以下はScripting BackendをMonoにし、先ほどと同様ビルド後に測定した結果です。
アクセス速度はインデクサーが一番遅く、コピーした配列へのアクセスとポインタでのアクセスの方が速いという結果でした。
現状は ENABLE_IL2CPP
で要素へのアクセス方法を変更するのが良いかもしれません。
因みにIL2CPPでのNativeArrayに関するパフォーマンスについてはJacksonDunstan.comにとても詳しく書かれています。
IJobParallelForTransformについて
IJobParallelForTransform
を使う際には色々気をつけるべきことがあります。
まずはTransformAccessArray
内のTransformが親子関係にあるかどうかでの違いについて。
using UnityEngine; using Unity.Collections; using Unity.Jobs; using Unity.Burst; using UnityEngine.Profiling; using UnityEngine.Jobs; using System.Threading; using Unity.Collections.LowLevel.Unsafe; using Unity.Jobs.LowLevel.Unsafe; namespace Es.JobSystem.Sample._01 { public class JobSystemSample01 : MonoBehaviour { struct JobA : IJobParallelForTransform { public void Execute(int index, TransformAccess transform) { transform.rotation *= Quaternion.Euler(1,1,1); } } const int Count = 1000; TransformAccessArray access; void Start() { if(access.isCreated) access.Dispose(); access = new TransformAccessArray(Count); for(int i = 0; i < Count; ++i) { var obj = GameObject.CreatePrimitive(PrimitiveType.Cube); access.Add(obj.transform); } } void OnDestroy() { access.Dispose(); } public void Update() { var job = new JobA(); var handle = job.Schedule(access); handle.Complete(); } } }
using UnityEngine; using Unity.Collections; using Unity.Jobs; using Unity.Burst; using UnityEngine.Profiling; using UnityEngine.Jobs; using System.Threading; using Unity.Collections.LowLevel.Unsafe; using Unity.Jobs.LowLevel.Unsafe; namespace Es.JobSystem.Sample._01 { public class JobSystemSample01 : MonoBehaviour { struct JobA : IJobParallelForTransform { public void Execute(int index, TransformAccess transform) { transform.rotation *= Quaternion.Euler(1,1,1); } } const int Count = 1000; TransformAccessArray access; void Start() { if(access.isCreated) access.Dispose(); access = new TransformAccessArray(Count); Transform buf = null; for(int i = 0; i < Count; ++i) { var obj = GameObject.CreatePrimitive(PrimitiveType.Cube); obj.transform.SetParent(buf); buf = obj.transform; access.Add(obj.transform); } } void OnDestroy() { access.Dispose(); } public void Update() { var job = new JobA(); var handle = job.Schedule(access); handle.Complete(); } } }
WorkerThreadの使われ方に注目してください。 親子関係がある場合、子は親のTransformに依存することになるので、1つのThreadしか使われません。関係がない場合は複数のThreadで処理してくれています。 Editorでの実行結果のみ載せていますが、ビルドしても同様の使われ方になります。
また、親子階層がめちゃんこ深いので、負荷も爆上がりしています。
因みに兄弟でも1つのThreadしか使われないようでした。
using UnityEngine; using Unity.Collections; using Unity.Jobs; using Unity.Burst; using UnityEngine.Profiling; using UnityEngine.Jobs; using System.Threading; using Unity.Collections.LowLevel.Unsafe; using Unity.Jobs.LowLevel.Unsafe; namespace Es.JobSystem.Sample._01 { public class JobSystemSample01 : MonoBehaviour { struct JobA : IJobParallelForTransform { public void Execute(int index, TransformAccess transform) { transform.rotation *= Quaternion.Euler(1,1,1); } } const int Count = 1000; TransformAccessArray access; void Start() { var parent = GameObject.CreatePrimitive(PrimitiveType.Cube); if(access.isCreated) access.Dispose(); access = new TransformAccessArray(Count); for(int i = 0; i < Count; ++i) { var obj = GameObject.CreatePrimitive(PrimitiveType.Cube); obj.transform.SetParent(parent.transform); access.Add(obj.transform); } } void OnDestroy() { access.Dispose(); } public void Update() { var job = new JobA(); var handle = job.Schedule(access); handle.Complete(); } } }
兄弟の場合でも、親子関係同様で1つのThreadしか使われません。 ただ、親子関係に比べると負荷は大分マシです。
Transform変更処理の負荷は階層構造が複雑であればあるほど重くなります。 なるべくシンプルな構造にし、深くネストしないことが大事です。
ちなみにIJobParallelForTransform
なJobを複数扱う場合についてもメモしておきます。
まずは親子関係がなく、全てSceneのルートオブジェクトの場合
using UnityEngine; using Unity.Collections; using Unity.Jobs; using Unity.Burst; using UnityEngine.Profiling; using UnityEngine.Jobs; using System.Threading; using Unity.Collections.LowLevel.Unsafe; using Unity.Jobs.LowLevel.Unsafe; namespace Es.JobSystem.Sample._01 { public class JobSystemSample01 : MonoBehaviour { struct JobA : IJobParallelForTransform { public void Execute(int index, TransformAccess transform) { transform.rotation *= Quaternion.Euler(1,1,1); } } const int Count = 1000; TransformAccessArray access1; TransformAccessArray access2; void Start() { if(access1.isCreated) access1.Dispose(); if(access2.isCreated) access2.Dispose(); access1 = new TransformAccessArray(Count); access2 = new TransformAccessArray(Count); for(int i = 0; i < Count; ++i) { var obj1 = GameObject.CreatePrimitive(PrimitiveType.Cube); access1.Add(obj1.transform); var obj2 = GameObject.CreatePrimitive(PrimitiveType.Cube); access2.Add(obj2.transform); } } void OnDestroy() { access1.Dispose(); access2.Dispose(); } public void Update() { var job1 = new JobA(); var handle1 = job1.Schedule(access1); var job2 = new JobA(); var handle2 = job2.Schedule(access2); JobHandle.ScheduleBatchedJobs(); Thread.Sleep(5); handle1.Complete(); handle2.Complete(); } } }
普通にいい感じですね。 次は親子関係がある場合です。
using UnityEngine; using Unity.Collections; using Unity.Jobs; using Unity.Burst; using UnityEngine.Profiling; using UnityEngine.Jobs; using System.Threading; using Unity.Collections.LowLevel.Unsafe; using Unity.Jobs.LowLevel.Unsafe; namespace Es.JobSystem.Sample._01 { public class JobSystemSample01 : MonoBehaviour { struct JobA : IJobParallelForTransform { public void Execute(int index, TransformAccess transform) { transform.rotation *= Quaternion.Euler(1,1,1); } } const int Count = 1000; TransformAccessArray access1; TransformAccessArray access2; void Start() { if(access1.isCreated) access1.Dispose(); if(access2.isCreated) access2.Dispose(); access1 = new TransformAccessArray(Count); access2 = new TransformAccessArray(Count); Transform buf = null; for(int i = 0; i < Count; ++i) { var obj1 = GameObject.CreatePrimitive(PrimitiveType.Cube); access1.Add(obj1.transform); obj1.transform.SetParent(buf); buf = obj1.transform; var obj2 = GameObject.CreatePrimitive(PrimitiveType.Cube); access2.Add(obj2.transform); obj2.transform.SetParent(buf); buf = obj2.transform; } } void OnDestroy() { access1.Dispose(); access2.Dispose(); } public void Update() { var job1 = new JobA(); var handle1 = job1.Schedule(access1); var job2 = new JobA(); var handle2 = job2.Schedule(access2); JobHandle.ScheduleBatchedJobs(); Thread.Sleep(5); handle1.Complete(); handle2.Complete(); } } }
Jobが分割されてはいますが、Transformへのアクセスが直列になります。 具体的には、1つめのJob実行中は関連するTransformへのAccessがブロックされるため、2つのJobが並列に実行されません。
あと親子関係が複雑で激重です。
次は兄弟関係がある場合です。
using UnityEngine; using Unity.Collections; using Unity.Jobs; using Unity.Burst; using UnityEngine.Profiling; using UnityEngine.Jobs; using System.Threading; using Unity.Collections.LowLevel.Unsafe; using Unity.Jobs.LowLevel.Unsafe; namespace Es.JobSystem.Sample._01 { public class JobSystemSample01 : MonoBehaviour { struct JobA : IJobParallelForTransform { public void Execute(int index, TransformAccess transform) { transform.rotation *= Quaternion.Euler(1,1,1); } } const int Count = 1000; TransformAccessArray access1; TransformAccessArray access2; void Start() { var parent = GameObject.CreatePrimitive(PrimitiveType.Cube); if(access1.isCreated) access1.Dispose(); if(access2.isCreated) access2.Dispose(); access1 = new TransformAccessArray(Count); access2 = new TransformAccessArray(Count); for(int i = 0; i < Count; ++i) { var obj1 = GameObject.CreatePrimitive(PrimitiveType.Cube); obj1.transform.SetParent(parent.transform); access1.Add(obj1.transform); var obj2 = GameObject.CreatePrimitive(PrimitiveType.Cube); obj2.transform.SetParent(parent.transform); access2.Add(obj2.transform); } } void OnDestroy() { access1.Dispose(); access2.Dispose(); } public void Update() { var job1 = new JobA(); var handle1 = job1.Schedule(access1); var job2 = new JobA(); var handle2 = job2.Schedule(access2); JobHandle.ScheduleBatchedJobs(); Thread.Sleep(5); handle1.Complete(); handle2.Complete(); } } }
これも同様ですね。 では、そもそも系譜の違う2つのJobにした場合はどうなるでしょうか。
using UnityEngine; using Unity.Collections; using Unity.Jobs; using Unity.Burst; using UnityEngine.Profiling; using UnityEngine.Jobs; using System.Threading; using Unity.Collections.LowLevel.Unsafe; using Unity.Jobs.LowLevel.Unsafe; namespace Es.JobSystem.Sample._01 { public class JobSystemSample01 : MonoBehaviour { struct JobA : IJobParallelForTransform { public void Execute(int index, TransformAccess transform) { transform.rotation *= Quaternion.Euler(1,1,1); } } const int Count = 1000; TransformAccessArray access1; TransformAccessArray access2; void Start() { var parent1 = GameObject.CreatePrimitive(PrimitiveType.Cube); var parent2 = GameObject.CreatePrimitive(PrimitiveType.Cube); if(access1.isCreated) access1.Dispose(); if(access2.isCreated) access2.Dispose(); access1 = new TransformAccessArray(Count); access2 = new TransformAccessArray(Count); for(int i = 0; i < Count; ++i) { var obj1 = GameObject.CreatePrimitive(PrimitiveType.Cube); obj1.transform.SetParent(parent1.transform); access1.Add(obj1.transform); var obj2 = GameObject.CreatePrimitive(PrimitiveType.Cube); obj2.transform.SetParent(parent2.transform); access2.Add(obj2.transform); } } void OnDestroy() { access1.Dispose(); access2.Dispose(); } public void Update() { var job1 = new JobA(); var handle1 = job1.Schedule(access1); var job2 = new JobA(); var handle2 = job2.Schedule(access2); JobHandle.ScheduleBatchedJobs(); Thread.Sleep(5); handle1.Complete(); handle2.Complete(); } } }
TransformAccessArrayに登録されているTransformの関係が疎であれば並列化できています。
一言でまとめるとTransformAccessArray
に登録するTransformの階層構造に注意することが大切です。
ローカル座標の更新とグローバル座標の更新 今回の例では、TransformAccess.rotation
に対して回転計算を行い更新していました。TransformAccess.localRotation
に対して更新を行なった場合には、親子関係が複雑であっても今回の例ほど負荷が高くなりません。 Transformが保持しているのはローカル座標です。 グローバル座標で値の更新を行う場合はオブジェクトの親のグローバル座標を求め、その値から自身の新しいローカル座標を計算する作業が必要になります。 Transformの更新では、可能な場合はローカル座標を更新するようにしましょう。
複数のIJobParallelForTransformを扱う際の罠 uSpringBone開発中に、複数のIJobParallelForTransformでシーンルートオブジェクトのTransformを更新しようとすると時々上記GIFのようにScheduleに非常に時間がかかる現象に遭遇しました(ビルド後の実行結果です)。 原因が究明出来てないのですが、ScheduleするJobを1つにまとめることで回避出来ます。 かなり厄介なので、IJobParallelForTransformを扱う際には注意が必要かもしれません。
NativeContainerへのポインタを使う
Jobで複数のNativeContainerを扱いたいけれど、その数が動的に変化するケースがあります。
そういったケースに遭遇した場合、NativeContainerへのポインタを取得して、ポインタをNativeContainerに詰めてJobへの入力としてやるのが楽です。
uSpringBoneでは複数のJobで計算処理を実行後、計算結果が格納されている複数のNativeArrayへのポインタをTransform更新用の1つのJobに渡して更新処理を行っています。
[BurstCompile] struct ApplyTransformJob : IJobParallelForTransform { [ReadOnly] public NativeArray<IntPtr> boneHeadPtrArray; [ReadOnly] public NativeArray<int> boneLengthArray; public unsafe void Execute(int index, TransformAccess transform) { var ptr = GetDataPtr(index); transform.position = ptr -> grobalPosition; transform.rotation = ptr -> grobalRotation; } private unsafe BoneData* GetDataPtr(int currentIndex) { var headPtrIndex = 0; var elemPtrIndex = currentIndex; for(int i = 0; i < boneLengthArray.Length; ++i) { headPtrIndex = i; elemPtrIndex = currentIndex; currentIndex = currentIndex - boneLengthArray[i]; if(currentIndex < 0) break; } var head = (BoneData*)boneHeadPtrArray[headPtrIndex]; var elem = (BoneData*)(head + elemPtrIndex); return elem; } }
boneHeadPtrArray
は連結している各ボーンの先頭のボーンデータへのポインタが入っています(ボーンデータには計算後の位置・回転情報が入っています)。
boneLengthArray
は連結しているボーンの連結数です。
この2つの情報からGetDataPtr()
で、現在変更しようとしているTransformAccess
に対応するボーンデータを取得し、その情報を使ってTransformを書き換えます。
以下の記事も参考に。
Scheduleのタイミング
こちらでも書いてますが、Jobはできる限りなるべく早くScheduleしてFlushしたほうがいいです(ただ、JobをFlushするのにもコストがかかるので、1つのJobをScheduleする度にFlushすべきではないです。用法・用量を守って正しく使用しましょう)。 他の処理実行中にWorkerThreadが計算してくれます。
Unityの各種イベント関数のはじめに実行したい場合、ScriptExecutionOrder
を設定すると良いです。
設定が面倒であれば、こういったものを利用しましょう。
Control Unity's Script Execution Order by code · GitHub
uSpringBoneでは、JobのScheduleを管理するクラスに上記コードを適用して、他のUpdate処理よりも前にScheduleをFlushさせるようにしています。
具体的には以下のようなコードになっています。
namespace Es.uSpringBone { // 他のスクリプトに記述されたイベント関数よりも前に実行させる [ScriptExecutionOrder(-32000)] public class SpringBoneJobScheduler : MonoBehaviour { /******** 省略 *********/ private void Update() { // 必要最低限のJobをSchedule foreach (var chain in chains) chain.ScheduleJob(); // Flush JobHandle.ScheduleBatchedJobs(); } /******** 省略 *********/
PlayerLoop
で云々も出来そうですが、特に理由がなければこちらは多用しないほうが良さそうです。
さいごに
JobSystemを利用する上で一番大事なのは、その設計です。 少ないJobで最大限の効果を発揮し、MainThreadにかかる負荷を少しでも減らすよう心がけましょう。
ECSとJobSystem 基礎
はじめに
やる気がある。全部Uniteのせい。
今回はECS(Entity Component System)とJobSystemについて色々触ってみたので、基礎部分のメモを残しておきます。
サンプルのプロジェクトは以下から見れます。
どの程度自分の解釈が正しいのかちょっと怪しい部分もあるので、今後も色々と検証も行っていきます。その段階で間違いとか新たな発見とかがあったらその都度記事を更新します。
あと、今回の内容は非同期処理について多少知見があると理解が早いです。 なんか4年前くらいに書いた資料が発掘されたので、興味がある方は見てみてください。 後ろの方(スライド92枚目あたり)に非同期処理についての何かが書いてあります。
ECSとJobSystemを使うメリット
そもそも、ECSやJobSystemはどんな時に役立ってくれるのでしょうか。 これからECSとJobSystemそれぞれ、または両方利用する場合のについてメリットについて見ていきます。
今関わってるプロダクトやこれから関わるプロダクトでECSやJobSystemの恩恵が殆ど感じられないようなケースもあるかもしれません。これらのメリットがあまり享受できなそうだと感じたら、無理に使う必要はありません。
ただ、ECSとJobSystemを使いこなす事が出来れば、今までのUnityでは実現が難しかったことが出来るようになります。 具体的には「大量のGameObjectをシーンに配置してそれぞれを動かしたり何かしら処理をさせたりする」みたいな事が高速に処理出来るようになります。 加えて、メモリ効率も格段に良くなります。
既存プロダクトの最適化でも役に立つケースがあるかもしれませんし、今後より便利になっていく機能だと思うので、今のうちに概要だけでも知っておくのが良さそうです。
メモリ効率を良くする(使用量/パフォーマンス)
GameObjectをシーンに配置するとどのくらいのメモリを喰うか、意識したことはありますか? それぞれのComponentはどうでしょうか?
これらのリソースがアプリケーションでどのくらいのメモリを確保するかは、実行している環境によって変わってきます。
これらを詳細にチェックするには実際の環境での実行時にメモリをプロファイルする必要がありますが、Unityエディタ上でもProfilerウィンドウから参考数値程度のものであれば確認することが出来ます(エディタで表示されるメモリ使用量は一般的に実機で実行しているときよりも大きくなります)。
例えば、ParticleSystemを持つGameObjectを大量生成した場合、エディタ上ではこうなります。
500個くらい生成してProfilerを確認した結果です。勿論実機ではもっと軽量になりますし、そもそもこんなに生成しないと思いますが... ParticleSystem結構重たいなっていうのはちょっとした発見。
Unityではオブジェクトにコンポーネントとしてデータをもたせることが出来ますが、このデータの多くは冗長で、実際には使われないようなものが多く含まれます。
ECSはDOA(Data Oriented Approach : データ中心設計)のため、このようなムダなメモリの確保を限りなく無くすことが出来ます。
また、データはハードウェアにとって扱いやすいよう連続的にメモリに配置され、キャッシュ効率の良いメモリアクセスが実現できます。
つまり、ECSは「大量のデータを効率よく処理する」ことに長けています。 「大量のGameObjectやComponentを扱う必要がありそう...」と感じたら「ECSを利用してGameObjectや無駄なComponent を作らず、必要なデータだけを定義して処理することができないか」を考えましょう。
処理の並列化
一般に、マルチスレッドでコードを書く際に注意しなければならないのが、データへの同時アクセスです。これは意図しないタイミングでの値の読み書きにより、期待した動作と異なるような結果を招いたり、あるいはデッドロックを発生させたりします。 これを回避するために多数の同期用データや処理を足すと、コードが煩雑になるだけでなく、あるThreadが他のThreadの完了待ちで長時間待機状態になってしまう...というような事も少なくありません。 結果、パフォーマンスがあまり改善しなかったり、デバッグが困難であったりと、様々な問題を抱えています。
JobSystemはUnityEngineと上手い具合にやり取りするマルチスレッドコードを簡単に書くことができるように設計された機能であり、UnityEngineが内部で利用するThreadを効率よく使いまわすことが出来ます。また、扱えるデータに制約を加えることで、MainThreadの共有リソースへの同時アクセスが発生しにくいような仕組みになっており、加えてデバッグも容易になっていたりします。複数のCPUコアを効率よく使うことで、アプリケーションの様々なロジックを高速に完了させることが出来、適切な箇所に適用することでかなり大きな恩恵が得られます。
そして、ECSは並列処理ととても相性の良いアーキテクチャです。 ECSで扱うデータは、シンプルな値がメモリ上に連続して並んでいるような格好になります。 このデータのそれぞれに並列で何か処理を行いたい場合「入力されたデータを処理してその結果を出力する関数」をマルチスレッドで走らせれば良いという、とても単純な設計を行えば良くなります。
まとめ
ざっくり纏めると、以下のようなメリットがあります。
- メモリ使用量が減る
- メモリレイアウトが良くなりキャッシュ効率が上がる
- 並列化が容易
使い所としては
- 大量のデータを扱う必要がある場合
- 処理の並列化を行いたい場合
といった感じでしょうか。
JobSystem
JobSystemについて基本的なところメモしておきます。 以下のサンプルを参考にさせていただきました。
JobSystemとは何か
JobSystemはUnityEngineと上手い具合にやり取りするマルチスレッドコードを簡単に書くことができるように設計された機能です。
JobSystemの重要な機能は、ユーザーの書いたコードとUnityEngineが内部的に使用しているネイティブ実装のJobSystemを統合することです。 これは、ユーザーが書いたコードとUnityEngineがJobSystem用に生成されたWorkerThreadを使う事を意味します。
JobSystem用に生成されたWorkerThreadを共有することによって、ユーザーがThreadの生成や管理を行う必要がなくなり、更に「CPUの論理コア数より多くのスレッドが生成されるのを防ぐ」ことが出来ます。
これは、コンテキストスイッチの発生を防ぐことに繋がります。
コンテキストスイッチは、 「処理実行中のスレッドの状態を保存して中断し、別途必要になった処理を行うために別のスレッドに切り替えて作業を行い、その後で最初のスレッドを再構成して処理を続ける」プロセスです。
コンテキストスイッチはリソースを大量に消費するため、可能な限り避けることが重要になります。 因みにUnityEngineの生成するWorkerThreadはコンテキストスイッチを避けるために、論理CPUコアと同等のThread数になるよう生成されます(MainThreadと合わせて論理コア数と同数になるっぽいです)。
JobSystemではUnityEngineが用意した WorkerThreadで実行可能なJobと呼ばれるものを作成します。 Jobは、メソッド呼び出しの振る舞いと同様にパラメータを受け取り、 データを操作します。Jobは小さく、1つの特定のタスクを実行するように作る必要があります。
Jobは継続タスク(async/await)のような従属性をサポートします。 つまり、AとBというJobがあり、BはAの終了後に実行させないといけないといったようなケースをサポートしています。
また、JobSystemはマルチスレッドプログラミングを行う上で常に問題となる「データ参照の競合」が発生しないよう、 操作する必要があるデータのコピーを作成します。
コピーするデータはBlittableデータ型 (マネージコードとネイティブコードの間で渡されたときに変換を必要としないデータ型)のみで、JobSystemではこれに該当する型にしかアクセス出来ないという制約があります。
マネージコードからネイティブコードへのデータの受け渡し方法ですが、JobSystemはScheduleメソッドを呼び出すことでBlittable型を内部的にmemcpy関数でコピーし、受け渡します。
コピーされたデータはネイティブメモリに格納され、Jobに定義されたExecuteメソッドがこの値を使ってWorkerThread上で処理を実行します。 当然ですが、このコピーされた値をWorkerThreadで変更したとしても、MainThread上の値には何の影響もありません。
では、WorkerThreadで処理した後の値を受け取るにはどうしたらいいでしょうか。これは
NativeContainer属性が付加されたコンテナを使うことで実現可能です。
例えば、NativeContainer
属性の付加されているNativeArray
というコンテナを使うと、Jobはそのデータに対してコピーを行わず、メインスレッド上の共有データにアクセスすることができます。
この共有データを使った処理が複数のJobで行われて競合した場合、例外が送出されます。
Unityが用意してくれているNativeContainer
属性の付加されている型は
- NativeArray
- NativeList
- NativeHashMap
- NativeQueue
など、様々なものがあります。これが全てではありません。
JobSystemのサンプル
以下のコードはUnityマニュアル のサンプルコードをちょこっと弄ったものです。
velocity
とdeltaTime
からposition
を計算するJobを作成し、実行しています(計算後にログを出力するだけで、ゲーム的な動きがあるサンプルではありません)。
using UnityEngine; using Unity.Collections; using Unity.Jobs; namespace Es.JobSystem.Sample._01 { public class JobSystemSample01 : MonoBehaviour { // Jobを作る際、Jobでアクセスされる全てのデータをJob内に宣言します。 // 宣言が可能なのはNativeContainer及びBlittable型のみです。 struct VelocityJob : IJob { // 読み取り専用という付加情報を与えることで複数のJobが並列にデータにアクセスできるようになります。 [ReadOnly] public NativeArray<Vector3> velocity; // デフォルトでは、コンテナは読み書きが可能です(つまり、MainThreadで結果を取り出すことができます)。 public NativeArray<Vector3> position; // Jobには一般的にフレームの概念がないため、deltaTimeをJobにコピーする必要があります。 // MainThreadは同じフレームまたは次のフレームでJobを待機しますが、Jobは // WorkerThreadで独立して処理が実行されます。 public float deltaTime; // Jobが実行するコードです。 public void Execute() { for (var i = 0; i < position.Length; i++) position[i] = position[i] + velocity[i] * deltaTime; } } public void Update() { // NativeArrayはNativeContainer属性が付加されているので // MainThreadとWorkerThreadでデータを安全に共有することができます。 // また、使い終えたらDisposeする必要があります。 var position = new NativeArray<Vector3>(100000, Allocator.Persistent); var velocity = new NativeArray<Vector3>(100000, Allocator.Persistent); for (var i = 0; i < velocity.Length; i++) velocity[i] = new Vector3(0, 10, 0); // Jobの初期化処理です。 var job = new VelocityJob() { deltaTime = Time.deltaTime, position = position, velocity = velocity }; // Jobをスケジューリングし、後でJobの完了を待つことができるJobHandleを返します。 JobHandle jobHandle = job.Schedule(); // メインスレッドで何か計算している最中にJobを動かしておきたい場合は以下のメソッドを呼ぶ JobHandle.ScheduleBatchedJobs(); // ...... // 何かMainThreadで行っておきたい処理 // MainThreadで10[ms]かかる重い処理を想定 // ...... System.Threading.Thread.Sleep(10); // Jobが完了したことを確認します(完了してなければ完了まで待ちます) // Schedule実行後、すぐにCompleteを呼び出すことはお勧めできません。 // 並列処理の恩恵を受けることがほぼできなくなるためです。 // フレームの早い段階でJobをScheduleし、他の処理を行った後でCompleteを呼び出すのが最適です jobHandle.Complete(); Debug.Log(job.position[0]); position.Dispose(); velocity.Dispose(); } } }
Jobを使うにはIJobインターフェースを実装した構造体を定義します。
もしJob側では読み取りにしか利用しないデータの場合にはReadOnly
属性で修飾してあげましょう。こうすることで複数のJobで並列してデータにアクセスできるようになります
(デフォルトでは読み書き両方できるデータになります)。
IJobを定義した構造体を作ると、Unityが用意した以下のように定義されているSchedule
拡張メソッドが利用可能になる仕組みです。
public static JobHandle Schedule<T>(this T jobData, JobHandle dependsOn = default(JobHandle)) where T : struct, IJob;
このSchedule
を呼び出すことで、JobがJobSystemの管理するQueue(JobQueue)にEnqueueされます。
Schedule
の戻り値はJobHandleです。
JobはSchedule
メソッドのパラメーターにJobHandle
を指定して、特定のJob実行後に継続して他のJobを実行させるようにできます。また、JobHandle.CombineDependenciesを使うことで、複数のJobHandle
を纏めることができます。この纏めた結果のJobHandle
をSchedule
のパラメーターとして利用する場合、纏めた全てのJobの完了後にSchedule
されたJobが実行されます。
Schedule
をしても、実際にはJobは実行されません。Jobを開始するには、バッチ(仕事を一定数ごとに分割したもの)をflushする必要があります。これはComplete
を呼び出すと行われます。しかし、
Schedule
後直ぐにComplete
を呼び出すと、MainThreadがその段階でJobの完了待ちをしてしまうため、並列化の恩恵が薄れてしまいます。また、Jobがすぐに完了待ちを行うようなコードになっている場合、この勿体無い待ち時間をなんとか潰すために、MainThreadでもJobが実行されます(これの判断はJobSystemが勝手にしてくれます)。
これを解決するには、
Schedule
後にJobHandle.ScheduleBatchedJobs
メソッドを呼び出します。このメソッドを呼び出すことでバッチがflushされ、Jobが開始されます。あとはサンプルのように、Jobの結果を待つタイミングでComplete
を呼び出します。
上記はサンプルコードの
JobHandle.ScheduleBatchedJobs
をコメントアウトして実行したときの結果です。 無駄な待ち時間が発生するため、MainThreadでJobが実行されています。半々くらいの頻度でWorkerThreadで処理を行ってくれようとするんですが、結局MainThreadでは待ちが発生するので、どちらにせよ並列化の恩恵は受けられません。
Schedule
したら、後はCompleteやJobHandle.CompleteAllでJobの完了を待ちます。
サンプルコードで使っているNativeArrayはNativeContainer
属性が付加されたコンテナです。
NativeContainer
属性はジョブデバッグシステムが競合状態を確実に検出可能であることや、Thread間での安全な値の受け渡しが可能であるということを示すための属性です。なので、(この属性を付加された構造体の実装がちゃんとしていれば)MainThreadから安全に値にアクセスできます。NativeArray
は固定長の配列で、生成時には配列のサイズとメモリの割り当て、解放について指定するAllocatorを渡します。
MainThreadから安全に値にアクセスできると書きましたが、競合した場合は「例外が出てくれる。ログにも出力される」的な意味で安全と言っています。 もし独自で
NativeContainer
属性を付加したコンテナを自作しても、実装がちゃんとしてなければクラッシュする可能性があります。 これに関してはNativeContainer
のドキュメントで詳細が見れます。
Allocatorについて
- Allocator.Temp
- メモリ確保が最も高速です。これは1フレーム以下のアロケーションでの使用を目的としており、スレッドセーフではありません。この方法でメモリを確保した場合、関数呼び出しから戻る前にDisposeメソッドを呼び出す必要があります。
- Allocator.TempJob
- Allocator.Tempよりメモリ確保が低速ですが、Allocator.Persistentより高速です。これは、4フレーム以下の寿命を持つ場合に利用出来、スレッドセーフです。ほとんどの短期ジョブはこのNativeContainer割り当てタイプを使用します。4フレーム経過前にDisposeしないとメモリリークします。
- Allocator.Persistent
- メモリ確保が最も遅いですが、アプリケーションの存続期間中存続します。mallocへの直接呼び出しのラッパーです。より長いJobがこのNativeContainer割り当てタイプを使用することがあります。使い終わったらDisposeします。
さて、これを動かしてProfilerで確認すると、VelocityJob
のExecute
がJobSystemの管理するWorkerThreadで動いているのが確認できます。
並列化Job
先ほどのサンプルでは、MainThreadから切り離したい処理をJobとして登録し、JobSystem上のWorkerThreadで実行されるようにしました。
次はこのJobを並列化してしまいます。先ほどのサンプルでは、Execute
内でfor文を使って、position
を計算していました。
データだけが異なる同じ演算を繰り返している部分なので、このExecute
の中も並列で計算してもらう方がよさそうです。
これを実現するために、IJobParallelForが用意されています。IJob
の代わりにこちらを実装するようにします。
using UnityEngine; using Unity.Collections; using Unity.Jobs; namespace Es.JobSystem.Sample._02 { public class JobSystemSample02 : MonoBehaviour { // Jobの並列化のためにIJobParallelForを実装するよう変更 struct VelocityJob : IJobParallelFor { [ReadOnly] public NativeArray<Vector3> velocity; public NativeArray<Vector3> position; public float deltaTime; // 並列アクセスのためにインデックスを受け取って処理を行うExecuteを実装 public void Execute(int i) { position[i] = position[i] + velocity[i] * deltaTime; } } public void Update() { var position = new NativeArray<Vector3>(100000, Allocator.Persistent); var velocity = new NativeArray<Vector3>(100000, Allocator.Persistent); for (var i = 0; i < velocity.Length; i++) velocity[i] = new Vector3(0, 10, 0); var job = new VelocityJob() { deltaTime = Time.deltaTime, position = position, velocity = velocity }; // 並列実行のJobをスケジュールします。 // 最初のパラメータは、各反復が何回実行されるかです。 // 2番目のパラメータは、内部でのループ分割数(バッチ数)です。 JobHandle jobHandle = job.Schedule(position.Length, 128); // メインスレッドで何か計算している最中にJobを動かしておきたい場合は以下のメソッドを呼ぶ JobHandle.ScheduleBatchedJobs(); // ...... // 何かMainThreadで行っておきたい処理 // MainThreadで10[ms]かかる重い処理を想定 // ...... System.Threading.Thread.Sleep(10); jobHandle.Complete(); Debug.Log(job.position[0]); position.Dispose(); velocity.Dispose(); } } }
上記はUnityマニュアルのサンプルコードです。
サンプルの変更点は
IJob
の代わりにIJobParallelFor
を実装Execute
が引数付きになり、インデックスが渡ってくるのでそれを使うように実装を変更(今回は配列のインデックスとして利用)Schedule
Executeメソッド実行回数(今回は配列の長さ分)、内部でのループ分割数(バッチ数)を指定するように変更
たったこれだけです。
IJobParallelFor
では指定されたバッチ数以上のチャンクに作業を分割し、適切な数のJobをスケジュールします。
複数のJobが複数のWorkerThreadで実行されるようになるため、サンプルのようなケースではとても有効です。
バッチ数に1に近い値がくるほど、スレッド間での作業の分散がより均一になります。 ただし、作業が細かく分割されすぎるとオーバーヘッドがあるので、バッチ数を増やす方がよい場合もあります。1から始まり、パフォーマンスの向上が得られる間バッチ数を動的に増やすことは有効な戦略です。
さて、こちらもProfilerで確認すると、JobSystemのWorkerThreadで処理を行っていることが確認できます。
先程のIJob
を実装したJobのProfilerと比較すると、IJobParallelFor
が複数のWorkerThreadを使って処理を行っていることがわかると思います。
JobSystemを使う上での注意
JobSystemを利用する上で、以下のことに気をつける必要があります。
- Jobから外部データにアクセスしないこと
- 計算を安全に行うために、Job内部で安全に利用できる型には制約がある(Blittable型とNativeContainer)
- この安全性を享受するためには、JobSystemの処理では、この制約を受けた変数のみを使う必要がある
- Job外部のデータを参照して利用した場合、安全性が担保できなくなる可能性がある
- 最悪Unityがクラッシュする
- 今後のバージョンのUnityでは、静的解析によってJobから外部データへのアクセスが禁止される可能性がある
- このため、これに該当するようなコードを書いた場合、将来のUnityでは動かなくなる可能性がある
- Jobを開始するには、Scheduleされたバッチをflushする必要があることに注意する
Complete
は呼び出した際にJobが開始されてなければflushして実行し、完了を待つJobHandle.ScheduleBatchedJobs
を使えばComplete
以前にJobを開始しておくことができる- Jobを
Schedule
したら、なるべくJobHandle.ScheduleBatchedJobs
してその後Complete
を呼び出す
NativeArray
の要素を変更する際に注意する- 常に
Complete
を呼ぶことComplete
を呼ぶことで、WorkerThreadに委譲していたNativeContainer
の所有権がMainThreadに返されるComplete
はJobデバッガの状態も更新する(更新されないままだと、デバッガはメモリリークしたと判断し、警告を出す)
ECS
続いてECSについて。
みんな大好きテラシュールさんがめちゃくちゃわかりやすく、参考にさせていただきました。
- 【Unity】Unity 2018のEntity Component System(通称ECS)について(1) - テラシュールブログ
- 【Unity】Unity 2018のEntity Component System(通称ECS)について(2) - テラシュールブログ
ECSの概念的な事とかは長くなるので書かないことにします。 先ほどの参考ページや、以下を参照してください。
ECSを利用するサンプルコードと、それの解説のみ書いていくことにします。
上記で紹介したテラシュールさんでも言われていますが、本家ECSとUnityのECSだと用語が微妙に紛らわしいです。 本記事内では本家ECSの用語を使っていきます。つまり
- Data
- 何かしらの情報
- Entity
- Dataの集まり
- System
- Entityに対して行う処理
- Group
- Systemが要求するDataの纏まり
といった意味合いで解釈してください。
ECSを使うサンプル
using Unity.Collections; using Unity.Entities; using Unity.Mathematics; using Unity.Transforms; using UnityEngine; namespace Es.Ecs.Sample._01 { // 独自のDataを定義する場合、IComponentDataかISharedComponentDataを実装します。 // IComponentDataは、座標情報などのEntityごとに異なるデータに適しています。 // ISharedComponentDataは、多くのEntityに共通するものがある場合に適しています。 public struct SpeedData : ISharedComponentData { public float Value; public SpeedData(float value) { Value = value; } } // Group(Systemに渡されるEntityの纏まり。つまり要求されるデータの配列のようなもの)を定義。 // IComponentDataかISharedComponentDataを実装したDataがSystemに要求されるデータになります。 // Lengthには要求するDataを持つEntityの数が格納されます。 public struct SampleGroup { // ComponentDataArrayはNativeContainer属性が付加されているので // Thread間でデータを共有できます。 public ComponentDataArray<Position> postion; public ComponentDataArray<Rotation> rotation; // SharedComponentDataArrayはReadOnlyを指定しないとエラーになります。 // SharedComponentDataArrayはEntity間で共通の値であり、NativeContainerではないため、 // 値の代入行為が不適切であるからです。 // SharedComponentDataArrayは、Systemで計算に使う値を格納する用途で使います。 [ReadOnly] public SharedComponentDataArray<SpeedData> speed; public int Length; } // ComponentSystemを継承したクラスを作ることで // GroupがEntityの持つ型と一致する場合に処理を実行するSystemを作ることができる。 public class SampleSystem : ComponentSystem { // Inject属性で要求するグループを指定する // (Systemに特定のDataへの依存性を注入する) [Inject] private SampleGroup sampleGroup; float deltaTime; // Systemが毎フレーム呼び出す処理 protected override void OnUpdate() { deltaTime = Time.deltaTime; for (int i = 0; i < sampleGroup.Length; i++) { // 落下させる var newPos = sampleGroup.postion[i]; newPos.Value.y -= sampleGroup.speed[i].Value * deltaTime; sampleGroup.postion[i] = newPos; // 回転させる var newRot = sampleGroup.rotation[i]; newRot.Value = math.mul(math.normalize(newRot.Value), math.axisAngle(math.up(), sampleGroup.speed[i].Value * deltaTime)); sampleGroup.rotation[i] = newRot; } } } // ECSを利用するサンプルクラス。 // JobSystemを利用していないため、MainThreadで動く。 // このサンプルでは、大量のMeshの移動と回転を行い、描画する。 public class EcsSample01 : MonoBehaviour { public Mesh mesh; public Material material; public int createEntityPerFrame = 100; private EntityManager entityManager; private EntityArchetype archetype; [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.AfterSceneLoad)] private void Start() { // Entityの管理者を取得 entityManager = World.Active.GetOrCreateManager<EntityManager>(); // アーキタイプ(EntityがもつDataタイプの配列)の登録 archetype = entityManager.CreateArchetype( typeof(Position), // Unity.Transformでデフォルトで定義してくれている「位置」を表すData typeof(Rotation), // Unity.Transformでデフォルトで定義してくれている「回転」を表すData typeof(SpeedData) // 独自定義した「微小な値」を表すData ); } private void Update() { // Spaceキーが押さていたらMeshを生成 if (Input.GetKey(KeyCode.Space)) { for (int i = 0; i < createEntityPerFrame; i++) { // 管理者にEntityの生成と管理をお願いする var entity = entityManager.CreateEntity(archetype); // 生成したEntityに対して、Dataを登録してもらう entityManager.SetComponentData(entity, new Position { Value = new float3(Random.Range(-20, 20), 20, Random.Range(-20, 20)) }); entityManager.SetComponentData(entity, new Rotation { Value = Quaternion.Euler(0, Random.Range(0, 180), 90) }); entityManager.SetSharedComponentData(entity, new SpeedData(10)); } } //=================================================================================================/ // HACK: // 本来であれば Mesh / Position / Rotation / Material を持つEntityを // 描画するようなSystemを作るべきですが、サンプルコードが冗長になるためここに描画処理を書いてあります。 //=================================================================================================/ // DrawMeshで描画を行う // エンティティの Position / Rotation を取得しつつメッシュを描画 var entities = entityManager.GetAllEntities(); foreach (var entity in entities) { var position = entityManager.GetComponentData<Position>(entity); var rotation = entityManager.GetComponentData<Rotation>(entity); Graphics.DrawMesh(mesh, position.Value, rotation.Value, material, 0); } // GetAllEntitiesで取得したNativeArrayは明示的に破棄する。 // また、GetAllEntityではAllocatorを指定できるが、デフォルトのTempだと // フレームをまたいで生存しているとメモリリークするので注意。 entities.Dispose(); } } }
上記はSpaceキーを押していたら「位置・回転」情報を持つEntityを生成し、SystemがそのEntityに対して「位置・回転情報の更新」を行うサンプルです。
ECSとは直接関係なく蛇足ですが、更新を行なった「位置・回転」情報を使ってDrawMeshでMeshを描画しています(特定のDataを持つEntityの場合に描画を行うSystemを作って任せるようにしたほうがいいと思いますが、サンプルコードが長くなるので今回は割愛)。
実行するとこんな感じになります。
コードの解説ですが、ECSの考え方が掴めていればあとはUnityでそれをどう実装していけばいいのかを把握するだけでほぼ終わりです。ただし、多少気を付けなければならない部分もあるので、踏み抜かないよう注意していきましょう。
Dataの定義
サンプルのSpeedData
の定義がこれにあたります。
public struct SpeedData : ISharedComponentData { public float Value; public SpeedData(float value) { Value = value; } }
Dataを定義する場合は
IComponentData
ISharedComponentData
のどちらかを実装した構造体を定義します。
IComponentData
は、座標情報などのEntityごとに異なるDataの実装に適しています。
Entityごとに異なる値になるので、Systemで読み書きが可能です。
ISharedComponentData
は、多くのEntityに共通するものがある場合に適しています。
値が同じものは各Entityで共通のDataインスタンスが利用されるようになります。
Groupの定義
サンプルのSampleGroup
がGroupの定義です。
public struct SampleGroup { public ComponentDataArray<Position> position; public ComponentDataArray<Rotation> rotation; [ReadOnly] public SharedComponentDataArray<SpeedData> speed; public int Length; }
IComponentData
ISharedComponentData
のどちらかが実装されたDataのコンテナを格納する構造体を定義します。 コンテナには
ComponentDataArray
SharedComponentDataArray
が利用できます。
SharedComponentDataArray
はEntity間で共有される値で、Systemが勝手に変更を行うことはできません。コンテナの定義の際に[ReadOnly]
属性を付加し忘れるとエラーが出ます。
因みにComponentDataArray
はNativeContainer
です。SharedComponentDataArray
はNativeContainer
ではありません。
ComponentDataArray
がNativeContainer
であることはJobSystemを利用する際に結構役立つ知識なので覚えておきましょう。
Systemの定義
SampleSystem
がSystemの定義部分です。
public class SampleSystem : ComponentSystem { [Inject] private SampleGroup sampleGroup; float deltaTime; // Systemが毎フレーム呼び出す処理 protected override void OnUpdate() { // ......Systemの処理...... } }
ComponentSystem
を実装し、Systemが要求するEntityのコンテナ実装(つまりGroup)に対して[Inject]
属性を付加します。
OnUpdate
はComponentSystem
の抽象メソッドで、これがSystemの行う処理になります。
後述しますが、JobSystemで並列に処理を実行するSystemを定義したい場合JobComponentSystem
を実装します。
Entityの生成
まずEntityを管理するManagerのインスタンスを生成します。
entityManager = World.Active.GetOrCreateManager<EntityManager>();
次に、EntityがもつDataタイプを先ほどのManagerに渡してEntityを作ってもらいます。
archetype = entityManager.CreateArchetype( typeof(Position), typeof(Rotation), typeof(SpeedData) ); ... var entity = entityManager.CreateEntity(archetype);
生成されたEntityに対してDataを登録すれば終わりです。 Entityは生成・登録を行なったManagerによって管理されます。
entityManager.SetComponentData(entity, new Position { Value = new float3(Random.Range(-20, 20), 20, Random.Range(-20, 20)) }); entityManager.SetComponentData(entity, new Rotation { Value = Quaternion.Euler(0, Random.Range(0, 180), 90) }); entityManager.SetSharedComponentData(entity, new SpeedData(10));
ECSで処理の並列化
ECSの利点は色々あるのですが、そのうちの1つが「データと処理が完全に分離される」点です。 この特徴は、Systemで行われる処理を非同期にするのにとても都合が良いです。
つまり、ECSは非同期処理を行うJobSystemと相性が良く、大量のデータを扱う場合には大きなパフォーマンス向上に繋がる可能性があります。
以下の画像は、先ほどのサンプルを実行し、Profilerで確認したものです。
Systemの処理が全てMainThreadで実行されているため、WorkerThreadが遊んでいます(使ってないので当然ですが)。 これはちょっと勿体無いですね。
以降では、Systemの処理をWorkerThreadで動かすようなサンプルを見ていきます。
JobSystem + ECS
ECSとJobSystemを使う例を見ていきます。 先ほどのECSのサンプルコードを改造してSystemの処理をJob化し、WorkerThreadで動作するようにしています。
using Unity.Collections; using Unity.Entities; using Unity.Jobs; using Unity.Mathematics; using Unity.Transforms; using UnityEngine; namespace Es.EcsJobSystem.Sample._01 { public struct SpeedData : ISharedComponentData { public float Value; public SpeedData(float value) { Value = value; } } public struct SampleGroup { public ComponentDataArray<Position> position; public ComponentDataArray<Rotation> rotation; [ReadOnly] public SharedComponentDataArray<SpeedData> speed; public int Length; } // 移動と回転処理を行うJobを定義。 // IJobProcessComponentDataを実装することで、Genericパラメータに指定したDataを // 対象とするJobを定義することができる。 // Job内で宣言が可能なのはNativeContainer及びBlittable型のみなことに注意 struct MoveRotateJob : IJobParallelFor { public ComponentDataArray<Position> position; public ComponentDataArray<Rotation> rotation; public SharedComponentDataArray<SpeedData> speed; public float deltaTime; public void Execute(int i) { var newPos = position[i]; newPos.Value.y -= speed[i].Value * deltaTime; position[i] = newPos; var newRot = rotation[i]; newRot.Value = math.mul(math.normalize(newRot.Value), math.axisAngle(math.up(), speed[i].Value * deltaTime)); rotation[i] = newRot; } } // JobComponentSystemは抽象クラス。 // IJobProcessComponentDataを利用するとInjectが不要になったりと // スマートに書けるようになるが、本サンプルでは先ほどのJobSystem // サンプルベースで見ることができるように愚直にSystemをJob化する public class SampleSystem : JobComponentSystem { [Inject] private SampleGroup sampleGroup; // SystemではJobを生成し、ScheduleしてJobHandleを返す protected override JobHandle OnUpdate(JobHandle inputDeps) { var job = new MoveRotateJob() { position = sampleGroup.position, rotation = sampleGroup.rotation, speed = sampleGroup.speed, deltaTime = Time.deltaTime }; var handle = job.Schedule(sampleGroup.Length, 32, inputDeps); return handle; } } // ECS + JobSystemを利用するサンプルクラス。 public class EcsJobSystemSample01 : MonoBehaviour { public Mesh mesh; public Material material; public int createEntityPerFrame = 100; private EntityManager entityManager; private EntityArchetype archetype; [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.AfterSceneLoad)] private void Start() { entityManager = World.Active.GetOrCreateManager<EntityManager>(); archetype = entityManager.CreateArchetype( typeof(Position), typeof(Rotation), typeof(SpeedData) ); } private void Update() { if (Input.GetKey(KeyCode.Space)) { for (int i = 0; i < createEntityPerFrame; i++) { var entity = entityManager.CreateEntity(archetype); entityManager.SetComponentData(entity, new Position { Value = new float3(Random.Range(-20, 20), 20, Random.Range(-20, 20)) }); entityManager.SetComponentData(entity, new Rotation { Value = Quaternion.Euler(0, Random.Range(0, 180), 90) }); entityManager.SetSharedComponentData(entity, new SpeedData(10)); } } var entities = entityManager.GetAllEntities(); foreach (var entity in entities) { var position = entityManager.GetComponentData<Position>(entity); var rotation = entityManager.GetComponentData<Rotation>(entity); Graphics.DrawMesh(mesh, position.Value, rotation.Value, material, 0); } entities.Dispose(); } } }
1つ目のECSサンプルと比較して、変更箇所は以下の通りです。
IJobParallelFor
を実装したMoveRotateJob
というJobが定義された- このJobには、1つ目のサンプルでSystemのOnUpdateが実行していた処理が移植されている
JobComponentSystem
を実装したSystemが定義された- Systemは、1つ目のサンプルでは
ComponentSystem
が実装されていた JobComponentSystem
のOnUpdate
は引数および戻り値がJobHandle
になるOnUpdate
の引数inputDeps
は、SystemにDataへの依存性注入を行うJobをSchedule
して返されたJobHandle
- なので、
inputDeps
を任意のJobのSchedule
に渡すことで、依存性注入後にJobの実行を行うことができる - 戻り値は
Schedule
したJobが返すJobHandle
- Systemは、1つ目のサンプルでは
ECSのみのサンプルとあまり大きな違いはなく、Systemの処理をJobSystemで行わせるようにしただけです。特に難しくは無いと思います。
因みに、パフォーマンスはこんな感じです。
このサンプルだとMainThreadがUpdate
の最後に記述した描画のための処理で圧迫されてしまっているのがちょっと気になりますが、とりあえず気にしないでください。
今重要なのは複数のWorkerThreadでJobが実行できているということです。
MainThreadのみで実行していた時に比べると、「Update開始からSystemの処理が終わるまでの時間」が大体17[ms]から10[ms]まで短縮されました。
両サンプルの計測時には、Spaceキーを押している間生成を行うのではなく、一度に10000回Entityを生成し、3秒後の結果を表示しています。
因みにJobにComputeJobOptimization
属性を付加してBurstコンパイラに最適化してもらうようにすると、もっと速くなります(今はEditor上でのみBurstコンパイラの恩恵が受けられると聞いたような聞かないような...どうでしたっけ...)。
以下はJobにComputeJobOptimization
属性を付加して同じように測定した結果です。
WorkerThreadの処理が速くなったことが確認できます。
ECS + JobSystemを良い感じに書く構成
今まで載せてきたサンプルコードではあえて、それぞれの定義をバラバラにしていました。
実践で使う場合、以下のような感じで構造分けするのがよさそうです (先ほどのECS+JobSystemのサンプルをちょっと手直しして描画もSystemが行うよう変更してあります)。
Data定義
using Unity.Entities; namespace Es.EcsJobSystem.Sample._04.Data { public struct Speed : IComponentData { public float Value; public Speed(float value) { Value = value; } } }
using Unity.Entities; using UnityEngine; namespace Es.EcsJobSystem.Sample._04.Data { public struct DrawMesh : ISharedComponentData { public Mesh mesh; public Material material; public DrawMesh(Mesh mesh, Material material) { this.mesh = mesh; this.material = material; } } }
System(JobSystem) + Group
using Unity.Entities; using Unity.Transforms; using Unity.Jobs; using Unity.Mathematics; using UnityEngine; using Es.EcsJobSystem.Sample._04.Data; namespace Es.EcsJobSystem.Sample._04.System { public class MoveRotateSystem : JobComponentSystem { public struct MoveRotateGroup { public ComponentDataArray<Position> position; public ComponentDataArray<Rotation> rotation; public ComponentDataArray<Speed> speed; public int Length; } public struct MoveRotateJob : IJobParallelFor { public MoveRotateGroup moveRotateGroup; public float deltaTime; public void Execute(int i) { var pos = moveRotateGroup.position[i]; pos.Value.y -= moveRotateGroup.speed[i].Value * deltaTime; moveRotateGroup.position[i] = pos; var rot = moveRotateGroup.rotation[i]; rot.Value = math.mul(math.normalize(rot.Value), math.axisAngle(math.up(), moveRotateGroup.speed[i].Value * deltaTime)); moveRotateGroup.rotation[i] = rot; } } [Inject] private MoveRotateGroup moveRotateGroup; protected override JobHandle OnUpdate(JobHandle inputDeps) { var job = new MoveRotateJob() { moveRotateGroup = moveRotateGroup, deltaTime = Time.deltaTime }; return job.Schedule(moveRotateGroup.Length, 32, inputDeps); } } }
using Unity.Entities; using Unity.Transforms; using Unity.Jobs; using Unity.Mathematics; using UnityEngine; using Unity.Collections; using Es.EcsJobSystem.Sample._04.Data; namespace Es.EcsJobSystem.Sample._04.System { [UpdateAfter(typeof(MoveRotateSystem))] public class DrawMeshSystem : ComponentSystem { public struct DrawMeshGroup { [ReadOnly] public SharedComponentDataArray<DrawMesh> drawMesh; public ComponentDataArray<Position> position; public ComponentDataArray<Rotation> rotation; public int Length; } [Inject] DrawMeshGroup drawMeshGroup; protected override void OnUpdate() { for(int i = 0; i < drawMeshGroup.Length; ++i) { Graphics.DrawMesh(drawMeshGroup.drawMesh[i].mesh, drawMeshGroup.position[i].Value, drawMeshGroup.rotation[i].Value, drawMeshGroup.drawMesh[i].material, 0 ); } } } }
Entity生成
using Unity.Collections; using Unity.Entities; using Unity.Jobs; using Unity.Mathematics; using Unity.Transforms; using UnityEngine; using Es.EcsJobSystem.Sample._04.Data; namespace Es.EcsJobSystem.Sample._04 { public class EcsJobSystemSample04 : MonoBehaviour { public Mesh mesh; public Material material; public int createEntityPerFrame = 100; private EntityManager entityManager; private EntityArchetype archetype; [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.AfterSceneLoad)] private void Start() { entityManager = World.Active.GetOrCreateManager<EntityManager>(); archetype = entityManager.CreateArchetype( typeof(Position), typeof(Rotation), typeof(Speed), typeof(DrawMesh) ); } private void Update() { if (Input.GetKey(KeyCode.Space)) { for (int i = 0; i < createEntityPerFrame; i++) { var entity = entityManager.CreateEntity(archetype); entityManager.SetComponentData(entity, new Position { Value = new float3(Random.Range(-20, 20), 20, Random.Range(-20, 20)) }); entityManager.SetComponentData(entity, new Rotation { Value = Quaternion.Euler(0, Random.Range(0, 180), 90) }); entityManager.SetComponentData(entity, new Speed(Random.Range(5, 20))); entityManager.SetSharedComponentData(entity, new DrawMesh(mesh, material)); } } } } }
ダメと言われてもやってみた
ちょっと話を戻して、先程のMainThreadでの描画処理の負荷が高かったサンプルについて、もうちょっとなんとかならないか考えます。
サンプルだと、MainThreadの処理中にWorkerThreadが遊んでムズムズしますね。
今回のサンプルでMainThreadのUpdate処理負荷が高い理由は
var entities = entityManager.GetAllEntities(); foreach (var entity in entities) { var position = entityManager.GetComponentData<Position>(entity); var rotation = entityManager.GetComponentData<Rotation>(entity); Graphics.DrawMesh(mesh, position.Value, rotation.Value, material, 0); } entities.Dispose();
この部分です。全てのEntityを取得して、それぞれのEntityからDataを取得し描画する部分です。この部分を少しでもなんとかしたい...。
Graphics.DrawMesh
はMainThread以外から呼ぶとUnityが怒ります。
なので、素直に並列化ってわけにはいきません。
そこで試しに、全てのEntityからDataを取得する部分のみをWorkerThreadで動かすようにJobを作ってみました。
using Unity.Collections; using Unity.Entities; using Unity.Jobs; using Unity.Mathematics; using Unity.Transforms; using UnityEngine; namespace Es.EcsJobSystem.Sample._03 { public struct SpeedData : ISharedComponentData { public float Value; public SpeedData(float value) { Value = value; } } public struct SampleGroup { public ComponentDataArray<Position> position; public ComponentDataArray<Rotation> rotation; [ReadOnly] public SharedComponentDataArray<SpeedData> speed; public int Length; } struct MoveRotateJob : IJobParallelFor { public SampleGroup sampleGroup; public float deltaTime; public void Execute(int i) { var newPos = sampleGroup.position[i]; newPos.Value.y -= sampleGroup.speed[i].Value * deltaTime; sampleGroup.position[i] = newPos; var newRot = sampleGroup.rotation[i]; newRot.Value = math.mul(math.normalize(newRot.Value), math.axisAngle(math.up(), sampleGroup.speed[i].Value * deltaTime)); sampleGroup.rotation[i] = newRot; } } // Entityからデータを得る作業を並列化するためのJob struct GetDataJob : IJobParallelFor { public NativeArray<Position> position; public NativeArray<Rotation> rotation; [ReadOnly] public NativeArray<Entity> entity; public void Execute(int i) { //! 静的データへのアクセス。 //! 通常時に実行はできたが、Burstコンパイラで最適化をかけたら実行時エラーが出た。 var entityManager = World.Active.GetOrCreateManager<EntityManager>(); position[i] = entityManager.GetComponentData<Position>(entity[i]); rotation[i] = entityManager.GetComponentData<Rotation>(entity[i]); } } public class SampleSystem : JobComponentSystem { [Inject] private SampleGroup sampleGroup; protected override JobHandle OnUpdate(JobHandle inputDeps) { var job = new MoveRotateJob() { sampleGroup = sampleGroup, deltaTime = Time.deltaTime }; var handle = job.Schedule(sampleGroup.Length, 32, inputDeps); return handle; } } public class EcsJobSystemSample03 : MonoBehaviour { public Mesh mesh; public Material material; public int createEntityPerFrame = 100; private EntityManager entityManager; private EntityArchetype archetype; [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.AfterSceneLoad)] private void Start() { entityManager = World.Active.GetOrCreateManager<EntityManager>(); archetype = entityManager.CreateArchetype( typeof(Position), typeof(Rotation), typeof(SpeedData) ); } private void Update() { if (Input.GetKey(KeyCode.Space)) { for (int i = 0; i < createEntityPerFrame; i++) { var entity = entityManager.CreateEntity(archetype); entityManager.SetComponentData(entity, new Position { Value = new float3(Random.Range(-20, 20), 20, Random.Range(-20, 20)) }); entityManager.SetComponentData(entity, new Rotation { Value = Quaternion.Euler(0, Random.Range(0, 180), 90) }); entityManager.SetSharedComponentData(entity, new SpeedData(10)); } } var entities = entityManager.GetAllEntities(); var job = new GetDataJob() { position = new NativeArray<Position>(entities.Length, Allocator.Temp), rotation = new NativeArray<Rotation>(entities.Length, Allocator.Temp), entity = entities }; var jobHandle = job.Schedule(entities.Length, 32); jobHandle.Complete(); for (int i = 0; i < entities.Length; ++i) Graphics.DrawMesh(mesh, job.position[i].Value, job.rotation[i].Value, material, 0); job.position.Dispose(); job.rotation.Dispose(); entities.Dispose(); } } }
こんな感じになるんですが、JobのExecute
に注目してください。
試しにJobから
World.Active.GetOrCreateManager<EntityManager>();
を呼び出してみました。 「JobSystemを使う上での注意」で書いた、やっちゃいけない奴です。 参考にしないでください。
でもとりあえず、今の段階では普通に動きます。 Profilerで確認したところ、目論見通り多少マシな感じになりました。
マジか。
因みにこのサンプルではJobにComputeJobOptimization
属性を付加すると実行時にCompiler exceptionが発生します。将来的にも使えなくなりそうなので、くれぐれも参考にしないで下さい。
さいごに
まだまだ理解不足な部分も多いですが、楽しかったのでもっと深く色々触ってみようと思います。
SRPもやらなきゃ。