【ゲームAI考察 #2】ゲームAIで考える非同期/マルチスレッド処理

はじめに+概要

今回の記事の目的は以下の通りです。

• ゲームAIの実装を例に非同期orマルチスレッド処理の使いどころを探る。
• 非同期処理、マルチスレッド処理について「なんとなく」じゃない理解をする。

あと、タイトルに #2 とあるのは下の記事の続きというテイでこの文章を書いているからです。
ご興味ありましたら#1も読んでみてください。

【ゲームAI考察 #1】汎用ゲームAIから条件分岐を徹底排除！！

【今回の検証について】

この記事で行う検証について説明します。
もし一言で表すなら次のような感じになるでしょうか。

「非同期orマルチスレッド処理を組み込むことで、ゲームAIのパフォーマンスを向上できるか検証」

さらに言うと通常の同期処理との比較の過程で、非同期/マルチスレッド処理について理解を深められたらいいなという感じでもあります。

【なぜAIを題材にするのか？】

それは ゲームAIに「待ち」の処理があるからです。
たとえばですが、アクションゲームの敵キャラがn秒に一回行動を切り替えるための判断をする、と考えてください。
この時、何度も「n秒待つ」という作業が繰り返されています。
それが私の言う「待ち」です。

そして検証前のあやふやな理解ですが、非同期処理orマルチスレッド処理は次のような場合に使うものであるという認識でした。
そのため時間待ちの処理でこの検証をすると決めました。

非同期処理

時間がかかる処理をするとき、その処理の完了を待たないのが非同期処理。

また、cpuがいい感じに実行して処理の完了時にドンピシャで結果を返してくれる（はず）。

なのでメインループで毎フレーム繰り返すより負荷が軽い。（はず）

マルチスレッド処理

ある処理をメインスレッド以外で実行することでCPUをフル稼働！

また、cpuがいい感じのタイミングでたまにスレッドを切り替えて実行する。（はず）

なのでメインループで毎フレーム繰り返すより負荷が軽い（はず）。

これが正しければ当然、同期処理より大幅に負荷が軽減できているはずですね。
早速調べていきましょう。

検証実施

【使用するもの】

Unity（ver 6000.0.35f1）

C#でコーディングできるゲームエンジンです。

今回の検証では実際に同期、非同期、マルチスレッドのそれぞれで時間待ちを実装したゲームAIを動かしてみます。

Unitask

非同期、マルチスレッド処理に使用するライブラリです。

こちらはCygames社のライブラリで、かなりお手軽に非同期処理やマルチスレッド処理を書けます。

これに関しては別にリンクを追記します。

Profile Analyzer

Unityのパッケージで、Profilerというデバッグ用機能で取得したログを詳細に分析できます。

今回の検証ではこのツールを使用してそれぞれのAIのパフォーマンスを比較します。

追記
Unitaskのリンク
ユーザー名：Cysharp様によるUnitaskのリポジトリ（記事投稿日の時点でMITライセンス）

Profile Analyzerの使用にあたって参考にさせていただいた記事
@mao_様の記事『【Unity】CPU Profilerの結果を分析できる「Profile Analyzer」が便利という話』

【検証の概要】

細かい検証の内容は次の項目で説明しますが、ここでは最低限の前提をお伝えします。
つまり面倒なら次の項目は読まなくてもいいということ（代わりにここは読んでいただけると……）。

• 実行環境は固定60フレーム。
  　→Profilerの仕様上可変フレームレートでのパフォ－マンスの比較が難しいため。
• オブジェクト生成・破棄の影響を除くために200フレーム目から1400フレーム目までを切り出して比較。
• 実行環境は2Dゲームのプロジェクト。
• 検証に使用するゲームAIは二秒に一回移動方向（左右）を変えるだけの単純なもの。
  　→この二秒に一回、の時間待ち処理を非同期/マルチスレッドに置き換える。
• 同期、非同期（2パターン）、マルチスレッド、の四種類のAIを用意。
• 以下の画像のようなAI付きオブジェクトのprefabを1000個生成して、30秒間動かした結果でパフォーマンスを比較。

オブジェクト

生成した様子

また、最後に今回はマルチスレッドの処理のパフォーマンスを見ることから、メインスレッドの負荷に加えてスレッドプールの使用状況も確認したいです。
とはいえ実際に見たところ動いているスレッドが予想以上に多くて困ってしまいました。

（多すぎ…）

そこでマルチスレッド処理の中に Debug.Log($"スレッド名：{Thread.CurrentThread.Name}")を差し込んだところ Thread Pool Workerと言う名前のスレッド だと分かりました。
そちらを確認していきます。

スレッド名

検証の詳細（読み飛ばしてもOK）

【検証の詳細】

ここでは検証の詳細についてコードを絡めながら説明します。
まず同期、非同期（2パターン）、マルチスレッドの四種類のAIが、それぞれどのように時間待ち処理を行っているのかを示します。
正直上手く実装できている自信がないため実装のご指摘をいただけると嬉しいです。

同期処理のAIのコード

一つ目のAIであり、比較の基準となる同期処理のコードは以下です。

同期待ちコード（展開）

SyncAI.cs

using UnityEngine;

public class SyncAI : AsyncTestBase
{

    private void Start()
    {
        base.Initialize();
    }

    /// <summary>
    /// ループ内で判断を行う。
    /// </summary>
    private void Update()
    {
        // 判断をパスしたなら移動判断をする。
        if ( IntervalEndJudge() )
        {
            base.MoveJudgeAct();
        }
    }
}

見た通りカンタンな作りになっています。
処理の内容は次の通りです。

• IntervalEndJudge()メソッドで毎フレーム時間経過をチェック。
• 二秒経過しているようなら base.MoveJudgeAct()メソッドで移動方向（左右）を変更。

ついでにIntervalEndJudge()メソッドの内部は以下のようになっています。

時間チェックメソッド(展開)

AsyncTestBase.cs

    /// <summary>
    /// 判断間隔の待機が完了したかを判定するメソッド。<br></br>
    /// 非同期、同期などのコード間で公平を期すため、同じ処理を使うために関数化。
    /// </summary>
    /// <returns></returns>
    protected bool IntervalEndJudge()
    {
        // テスト継続中(isTestフラグ真)
        // かつ前回の判断実行時間（lastjudgeの値）から設定したインターバル(status.judgeInterval)以上の時間が経過
        // ＝ 判断に必要な待機時間が経過したと判定し真を返す。
        return GameManager.instance.isTest && ((GameManager.instance.NowTime - lastJudge) > status.judgeInterval);

        // ちなみにNowTimeプロパティは Time.time の値と同じ。
        // TimeクラスではC++のDLLを呼んでいるようなので、1フレームに一回、シングルトンで値を取得・更新するだけにしたい意図でプロパティにした。
    }

非同期処理のAIのコード

これまで何度か触れたように、非同期処理のAIは二つ用意してあります。(いずれもUnitaskを使用)
そのうちの片方はIntervalEndJudge()メソッドを利用して時間を判定する AsyncAI.cs です。
IntervalEndJudge()メソッドを利用する意図は、判定に同期処理と共通の関数を利用することで、条件をそろえて公平を期するためです。

非同期1のコード(展開)

AsyncAI.cs

using UnityEngine;
using Cysharp.Threading.Tasks;
using System.Threading;
using System;

public class AsyncAI : AsyncTestBase
{

    /// <summary>
    /// 初期化して非同期判断ループ開始。
    /// </summary>
    void Start()
    {
        // 初期化
        base.Initialize();

        // 非同期ループ開始。
        AsyncJudge().Forget();
    }

    /// <summary>
    /// 非同期の判断メソッド。<br></br>
    /// 指定秒数ごとに行動判断をするループを回し続ける。
    /// </summary>
    /// <returns></returns>
    async UniTaskVoid AsyncJudge()
    {
        // キャンセルトークン取得
        CancellationToken token = GameManager.instance.cToken.Token;

        // キャンセルされるまで続ける。
        // トークンをこんな使い方しているのは、トークンを渡すとcancellationToken.Cancel()が例外を投げるから。
        // ＝ 例外処理をしたくないから。
        // もっといい方法があれば教えてください。
        while ( token.IsCancellationRequested == false )
        {
            // 判断間隔条件が真になるまで待つ。
            // 公平を期するために同期処理と同じ判断処理を使う。
            await UniTask.WaitUntil(() => IntervalEndJudge());

            // 行動判断
            MoveJudgeAct();
        }
    }

}

そしてもう一つの非同期処理のAIでは、時間判定に別の処理を使用しています。
すなわちUnitaskの時間待ちで最もポピュラー（多分）な UniTask.WaitForSeconds()メソッドを使用しているということです。
共通の処理にこだわらずに書いた非同期処理のAIになります。
なお、 AsyncAI.csとの違いはAsyncJudge()内部だけ ですのでコードはその部分だけです。

非同期2のコード(展開)

AltAsyncAI.cs

    /// <summary>
    /// 非同期の判断メソッド。<br></br>
    /// 指定秒数ごとに行動判断をするループを回し続ける。
    /// </summary>
    /// <returns></returns>
    async UniTaskVoid AsyncJudge()
    {
        // トークン取得
        CancellationToken token = GameManager.instance.cToken.Token;

        // キャンセルされるまで続ける。
        while ( token.IsCancellationRequested == false )
        {
            // 忖度なしで一番いい？ 処理をつかう
            await UniTask.WaitForSeconds(status.judgeInterval);

            // 行動判断
            MoveJudgeAct();
        }
    }

マルチスレッド処理のAIのコード

最後にマルチスレッド処理のAIのコードを貼ります。
マルチスレッドでは次のように、スレッドを切り替えてから10msごとに時間の判断を行うような処理にしています。
こちらも AsyncAI.csとの違いはAsyncJudge()内部だけ ですのでコードはその部分だけになります。

マルチスレッドAIコード(展開)

MTAsyncAI.cs

    /// <summary>
    /// マルチスレッドの判断メソッド。<br></br>
    /// スレッドを切り替えてループを回し続ける。
    /// </summary>
    /// <returns></returns>
    async UniTaskVoid AsyncJudge()
    {
        // トークン取得
        CancellationToken token = GameManager.instance.cToken.Token;

        while ( token.IsCancellationRequested == false )
        {
            // プールしたスレッドで時間待ちする。
            // これ以降の処理をスレッドプールへ切り替え。
            await UniTask.SwitchToThreadPool();

            // ちゃんと書けてるかわかりませんがマルチスレッド処理
            while ( IntervalEndJudge() == false )
            {
                // 100ms(0.1)秒ごとに時間を確認
                Thread.Sleep(100);
            }

            // 設定した時間が経過したらメインスレッドに戻す
            await UniTask.SwitchToMainThread();

            // 行動判断
            MoveJudgeAct();
        }

Thread.Sleep()メソッドで100ms（0.1秒）ごとに判断しています。
固定60fの１フレームが0.03秒なので、時間の経過の判断の回数がグッと減ると期待できます。
1フレームごとに判断する同期処理に比べると、IntervalEndJudge()の実行回数は3分の1になるはずです。

検証の補足

今回の検証では主にパフォーマンスを見るのが趣旨です。
しかし、同じくらい大切……というより前提となるべきなのが正確性であると思います。
つまり、1000個のオブジェクトが、30秒間の間、2秒に一回判断をするとして。
IntervalEndJudge()の実行回数は 30 × (1/2) × 1000 で15000回になるべきなのです。
ですが、非同期/マルチスレッド処理を使用した結果正しい間隔で処理が実行されなくなり、2~10秒ごとに判断をするAIができてはまずいです。
そのため、パフォーマンス比較前に一定の正確性が担保されていることを確認しました。

テスト終了時のデータ出力コード(展開)

GameManager.cs

            // 終了処理開始。
            isTest = false;
            cToken.Cancel();

            // テスト用のAsyncTestBase継承オブジェクトを収集。
            AsyncTestBase[] objects = FindObjectsByType<AsyncTestBase>(sortMode: FindObjectsSortMode.None);

            // 基準となる判断回数の期待値を取得。終了時間を判断間隔で割る。
            int baseCount = (int)Mathf.Floor(endTime / objects[0].JudgeInterval);

            // 期待値と実際の判断回数との間の差異を格納する。
            long divide = 0;

            for ( int i = 0; i < objects.Length; i++ )
            {
                // AsyncTestBase継承オブジェクトが持つ実判断回数を使用して期待値との誤差を出す。
                // 期待値 - 実判断回数 を加算し続ける。
                divide += baseCount - objects[i].judgeCount;
            }

            // テスト結果出力ファイルに新しい行を追加して書き出す。
            using ( StreamWriter sw = new StreamWriter(resultPath, true) )
            {
                sw.WriteLine($"テスト区分：{caseType.ToString()}");
                sw.WriteLine($"実行日時：{DateTime.Now.ToString()}");
                sw.WriteLine($"期待値：{baseCount * genNumber}回 に対して実測値：{divide}回 の差異。");
                sw.WriteLine($"平均誤差：{divide / genNumber} オブジェクト数：{genNumber}個");
                sw.WriteLine($"総処理時間：{totalTime}");
                sw.WriteLine(string.Empty);// 空行
            }

            // テスト終了。
            EditorApplication.ExitPlaymode();

このコードにより出力されたデータが以下です。

テスト結果

テスト区分	実行日時	期待値の実行回数	誤差の総計	実際の実行回数	平均誤差（総誤差/オブジェクト数）	オブジェクト数	総処理時間
同期	2025/02/11 1:15:12	15000回	1000回	14000回	1	1000個	1475428260000
非同期	2025/02/11 1:16:18	15000回	1000回	14000回	1	1000個	1474608470000
別処理非同期	2025/02/11 1:17:13	15000回	1000回	14000回	1	1000個	1480289270000
マルチスレッド	2025/02/12 0:54:12	15000回	1000回	14000回	1	1000個	1451073450000

四つのAIで全く同じ誤差でした。
総処理時間列でネタバレしてるのは見なかったことにしてくださいね。
以上から非同期/マルチスレッド処理でも時間待ちには最低限の正確性があり、パフォーマンスの比較が可能な土俵に立っていると判断しました。

結果

ここからは ProfilerAnalyzerを使ってパフォーマンスを見ていきます。
先述の通り比較の範囲はAIの処理以外の影響を除くために200フレーム目から1400フレーム目までです。
が、その前に軽く使い方について触れておきます。（読まなくてもいいです）

【ProfileAnalizerの使い方】

展開で表示

ProfileAnalizerはパッケージマネージャからインストールすることができます。

パッケージマネージャーの表示

そしてこのツールを使うためには、まず通常のProfilerで記録したデータが必要です。

Profilerの記録

この時Deep Profileしておくとメソッドごとの処理負荷を確認出来て便利です。
また、60fpsとはいえ通常は30秒間もの長さの記録を取ることはできません。
こうした検証の際はProfilerのウインドウの右上の ： から Preference に飛び、FrameCountの値を変えて記録可能時間を伸ばしましょう。

設定の流れ
Preferenceに飛ぶ
FrameCountの値を増やす

そうして記録したデータをProfilerに表示したまま、Window->Analysis->ProfileAnalizerでツールを開きます。
そしてPull Dataのボタンを押すと、Profilerに表示されているデータの分析結果が出てきます。

データ表示手順
Profilerにデータを表示したままPull Data
するとデータの分析結果が出てくる

【同期処理のパフォーマンス】

同期処理の結果（クリック：別タブで拡大表示）

上記の画像が同期処理で1000のオブジェクトを30秒動かした結果です。
かなり情報量が多いため整理していきましょう。
まず、このProfileAnalizerというツールでは特定の処理の分析結果だけを抜き出すことが可能ですのでフィルターをかけます。

フィルターには見たい処理の名前を書く Name Filterと排除したい処理の名前を書く Exclude Filterがあります。

フィルター二種

まずはNameFilterに SyncAIというワードを指定しましょう。
このSyncAIとは同期処理AIのコンポーネントの名前です。

インスペクタのコンポーネント

ということで、コンポーネント名でフィルターをかけて表示した結果がこちらになります。

同期処理の結果（フィルター有）

だいぶ見やすくなりましたね。
ではここで表示されているどの情報に着目するか、という点を次は決めたいと思います。
色々と列がありますが、今回は　Median（中央値）とMean（平均値）　の列を基準としたいと思います。
これらは指定した範囲（ここでは200~1400フレーム）の間での、該当の処理の処理時間の中央値と平均値を表示する列です。
すなわち 大体どれくらいの時間で Assembly-CSharp.dll!::SyncAI.Update() が処理されているかを確認できます。

処理時間

処理種別	中央値（Median）	平均値（Mean）
同期処理	0.26 ms	1.09 ms

以降は同じ条件で処理時間を抽出していきます。

【同期 vs 非同期1】

一つ目の非同期処理のAIに対して、コンポーネント名でフィルターをかけた結果が以下です。

非同期処理の結果（フィルター有）

そして同期処理との比較が以下になります。

処理時間比較

処理種別	中央値（Median）	平均値（Mean）
同期処理	0.26 ms	1.09 ms
非同期処理1	0.26 ms	0.27 ms

結果としては、平均値で非同期がかなり優れているように見えます。
ここは非同期の勝利、ということで二個目の非同期の比較に移ります。

【同期 vs 非同期2】

二つ目の非同期処理のAIに対して、コンポーネント名でフィルターをかけた結果が以下です。

非同期処理2の結果（フィルター有）

ない、なにも……。

何故でしょうか？
分かりませんね。
ともかく、こんな時確認すべきは中身の処理です。
そして調べた結果、この非同期処理2で使用している UniTask.WaitForSeconds()では、毎フレームとある処理を呼び出していると判明しました。（掘り下げは後回し）
それは UniTask.dll!::DelayPromise.MoveNext() です。
よってこちらでフィルターをかけると、ちゃんと毎フレームの待機処理の結果を出せました。

非同期処理2の結果（フィルター変更）

そして同期処理との比較が以下になります。

処理時間比較

処理種別	中央値（Median）	平均値（Mean）
同期処理	0.26 ms	1.09 ms
非同期処理2	0.28 ms	1.90 ms

結果としては全体的に同期処理が優れているようです。
奇しくも同期処理1の時と逆転しました。
同じ非同期なのに。
これがどういうことなのかはまた後で考えるとして、最後のマルチスレッドの比較に移りましょう。

【同期 vs マルチスレッド　と 全体のまとめ】

マルチスレッド処理で時間待ち処理を行った結果は以下です。

マルチスレッドの結果（フィルター無）

上記、情報量が多いのはフィルター無しだからです。
ではなぜフィルター無しなのか。

それは どうフィルターしていいのか全く分からなかったからです。
というより、仕様上 Thread.Sleep() でフレームをまたぐため、比較対象となる毎フレーム実行される処理がない？のです。

ですから比較のやり方を変えなければなりません。
具体的に言うと、フレームをまたいで処理を比較できるようになる必要があります。
そのためにはまず、そもそもどんな名前の処理が「待ち」の処理に相当するのかを確認しなければなりません。
この方法は簡単です。
以下のコードをマルチスレッドのAIの時間待機処理に差し込むだけです。

Profiler.BeginSample("Wait Process")

これで待機処理の一部にProfilerで追跡可能な Wait Process という名前がつきました。
この処理を行った上で、Profile Analyzerから通常のProfilerに戻りましょう。

すると以下の結果を確認できます。

Profiler上でWait Processを追跡

Wait Processを発見出来ました。
とはいえ、このマルチスレッド処理全体がイコールでWait Processである、というわけではないはずです。
先述の通り、この名前をつけたのはあくまで一部ですので。
Wait Processを含むツリーを上に登っていくと、メソッド名を含むそれっぽいマーカーを見つけました。
Assembly-CSharp.dll!::<AsyncJudge>d__2.MoveNext()です。

ただぽい、では良くないので色々調べた結果（こちらは最後に参考文献として紹介します）、簡単に言うと次のようなことが起こっていると分かりました。

Asyncメソッドは完了/未完了などの状態を管理するための型（ステートマシンと言います）のオブジェクトを生成する。
そしてそのオブジェクトのMoveNext() メソッド内に非同期メソッドの処理部分が変換される。
よって時間待ちメソッドはAssembly-CSharp.dll!::<AsyncJudge>d__2.MoveNext()で間違いないです。

時間待ち処理の本体

ではこちらのマーカーの処理をどのように他と比較するのかを考えましょう。
パッと思いつくのは、やはり平均値を総時間に変換するやり方でしょうか。
つまり平均値 × 実行回数 = 総実行時間となります。
こうすれば 毎フレーム実行されるが一回の時間が短い処理と 毎フレーム実行されないが一回の時間が長い処理を比較も出来そうですね。
そしてその実行回数はcount列に記載されているので簡単に計算出来そうです。
そして計算した結果は以下の表になります。

総処理時間比較

処理種別	平均時間	実行回数	総処理時間
同期処理	1.09 ms	1201000	1309090 ms
非同期処理1	0.24 ms	1201000	324270 ms
非同期処理2	1.90 ms	1201000	2281900 ms
マルチスレッド処理	548.11 ms	56290	30846920 ms

ダントツで最悪です……。
ただこれがイコールでパフォーマンス最悪、と見ることもできないとは思います。
あくまで処理時間、であり処理負荷ではありませんから。
特に私のコードは以下のように Thread.Sleep()が恐らく処理時間の大半を占めています。

マルチスレッドコード(展開)

MTAsyncAI.cs

    while ( IntervalEndJudge() == false )
    {
      Thread.Sleep(100);
    }

ですから処理時間、という枠を飛び越えて処理負荷を見るにはどうしたらいいのか。
その答えは 総フレーム数の多さ = 処理の軽さという基準です。

というのも、ふと思ったのですがこの検証では全て固定60フレームで30秒間の記録なのに総フレーム数、つまりプロファイラの記録の長さにばらつきがありましたね。
これは60フレームを維持できなかった瞬間があるせいです。
本来なら60(fps) × 30(second) = 1800となるべきところが、処理落ちした分だけ1800から欠けているのです。

ではこの単純明快な基準で再び比較してみましょう。

総処理時間比較

処理種別	フレーム数	順位
同期処理	1656	2位
非同期処理1	1588	3位
非同期処理2	1573	4位
マルチスレッド処理	1668	1位

おおおおお、大逆転！！！
マルチスレッド、同期、非同期2、非同期1の順になってしまいました！！！

それではこれで検証を終わります。
次は分析の時間です。

分析

ここからはなぜこのような結果になったのか、ということを分析していきたいと思います。
まずマルチスレッド処理が一位になった理由ですが、これはなんとなく分かります。
Thread.Sleep(100)により処理回数が大幅に減ったことです。

Sleepの長さによる処理負荷の変化
Sleep(1000)： 1687 フレーム
Sleep(10)： 1654 フレーム
Sleep(1)： 1649 フレーム

試してみた結果、確かにSleepの長さとパフォーマンスには相関関係がありそうです。
しかし Sleep(1)でも非同期処理よりは軽いのを見ると、単純に時間待ちをスレッドプールに分散したことが処理負荷を改善させていそうですね。
ついでにSleep(1000)にまで判断間隔を広げるとかなり誤差が出ることも分かりました。

次になぜ非同期処理が重かったのかを確認します。
これを知るためにはUnitaskの実装を見る必要がありそうです。
そして、また省略してしまい申し訳ないのですが、UniTaskの中身は以下のようになっているようです。

結果を待ち受ける内容をMonoBehaiver.Updateに登録し、毎フレーム結果を確認する。
つまり、やっていることが同期処理と同じなのです。

非同期処理で時間待ち処理をすることは、Updateで毎フレーム時間を確認する処理に、Task関連の余計な負荷を追加しただけだと言えます。

これでは遅くなって当然ですね。
というか、Updateで毎フレーム時間の経過を確認するような処理もある意味では非同期処理と言えないこともない気がしてきました……。
何故なら、時間が経つのを待っていませんからね。

終わりに

この検証を経て、私の非同期/マルチスレッド処理への理解は以下のように変わりました。

非同期処理

時間がかかる処理をするとき、その処理の完了を待たないのが非同期処理。

しかし、cpuがいい感じに実行して処理の完了時を通知してくれる、なんてことはない。

どこかのタイミングで処理の進行をチェックしなければならず、Unitaskの場合はメインループで毎フレーム確認している。

単純に、ある処理の完了を待たずに実行しつつ、その進行を把握したい！という時に使うのが基本。

以下おまけメモ

ステートマシン→コンパイラによってメソッドを状態管理可能な形に変換されたもの。

AsyncMethodBuilder→Asyncメソッドの返り値に準じて選択される、ステートマシンを管理するための構造体。ステートマシンを操作し、その状態をTask型のオブジェクトに反映する。

Taskオブジェクト→結果や状態を格納するオブジェクト。

マルチスレッド処理

ある処理をメインスレッド以外で実行することでCPUをフル稼働！

また、cpuがいい感じのタイミングでたまにスレッドを切り替えて実行する。（本当にこんな感じっぽい）

なのでメインループで毎フレーム繰り返すより負荷が軽い。

しかしスレッドは別のスレッドの処理と同期しないため、マルチスレッド処理が誤差やバグの原因にもなりうる。

それでは、今回はこのくらいで終わります。
感想としては、非同期処理への認識が特に大きく変わりましたね。
次の記事を書くなら、ちょうど気になっているJobシステムでも実験してみたいです。
もし何かいいネタあれば教えてください。

ここまで読んでくださりありがとうございました。
書いたコードや考察に関して、ご指摘があればどんどん教えていただけると嬉しいです！！！

追記：Profile Analyzerで比較用のCompareモードを使用していないのはMean（平均）が見えなくなってしまうからです。ご不明に思われた方いらっしゃいましたら申し訳ありません。

非同期処理に関する参考文献

• Unityの機能をawait可能にしてasync / awaitについて学ぶ
• 非同期メソッド入門 (7) - 内部実装を覗く

おまけ！　～cpuがいい感じのタイミングでたまにスレッドを切り替えて実行する とは？～

私はこの記事を投稿した時、マルチスレッド処理はcpuがいい感じのタイミングでたまにスレッドを切り替えて実行するとのたまいました。
しかしこれは、実際にいどのくらい呼ばれているのかを確認する必要があると思います。

そこで以下のようなコードを書いてマルチスレッド処理の実行回数を記録することにしました。

マルチスレッド処理の回数確認コード(展開)

   // 別スレッドで処理を行う。
   await UniTask.SwitchToThreadPool();

    // ループ一回ごとに long型のmtCounterを加算していく。
    while ( IntervalEndJudge() == false )
    {
      mtCounter++;
    }

   // メインスレッドに戻す
   await UniTask.SwitchToMainThread();

さらにUpdateループの回数も数えて、フレームのループとマルチスレッド処理のループの比率を求めてみます。

マルチスレッドとUpdateの比率確認コード(展開)

.cs

    private void Update()
    {
        frameCounter++;
        Debug.Log($"マルチスレッドは{mtCounter}回、フレームは{frameCounter}フレーム");
        Debug.Log($"マルチスレッドはUpdateの約{mtCounter / frameCounter}倍");
    }

そしてその結果がこれです。
オブジェクトは一つで、60秒実行しました。

Updateループと非同期処理処理の実行頻度

すごい差ですね。
これは想像よりだいぶ多いです。
こうして実際に確かめてわかりましたが、マルチスレッド処理はcpuがいい感じのタイミングでたまにスレッドを切り替えて実行するというのは正確な表現ではなさそうです。
Updateループなどと違い、フレームに縛られることなくずっと実行されていますねこれは。
ゲーム以外の通常のコンソールアプリ、あとは趣味の競技プログラミングでいつも実行しているコードに近い挙動です。

マルチスレッド処理はいつ実行されているの？　という疑問の答えはずっと実行されているで良さそうです。
すごく小さな単位の時間の中で、cpuがいい感じのタイミングでスレッドを切り替えてはいるのでしょうが。