前のパートでスケジューラが何をするかについて少し解説しました。今回は、スケジューラーがどのように動作し、ワークフローを最適化するためにはどのように使用すればいいかについて詳しく見ていきましょう。具体的には、スケジューラは、TOPネットワークで作成されたコマンドを受け取り、実行環境を作成し、それらのコマンドをバックグラウンドで別々のプロセスとして実行します。
これはTOPsで利用可能なさまざまなスケジューラに対しても当てはまります。また、ユーザーは多くの異なるスケジューラを作成することも可能であり、これらの異なるスケジューラはネットワークのスケジュール方法における異なるプロファイルとして機能させることができます。たとえば、テストを行っている場合や、小さなTOPネットワークを持っている場合は、目的によって異なるローカルスケジュールを使用することができます。
もしも本番環境で使用する場合、HQやDeadlineのようなスケジューラを使用することが望ましいかもしれません。このシリーズでは私たちはローカルスケジューラを使用します。これはローカルマシン向けのスケジューラです。ただし、この章で学んだ概念は、使用するすべてのスケジューラに一般的に適用できます。
下の図には、最初の「COOK」から始まり、ワークアイテムが実行される終点までのプロセスのフローチャートがあります。これは、TOPネットワークをクックする際に、裏側で実際に行われていることを視覚的に表したものです。
また、独自スケジューラを作成したり、よりカスタマイズした操作を行いたい場合にも、このフローチャートは素晴らしい参考資料となります。これは、SideFXのウェブサイトから直接引用しました。もし他に質問がある場合や他の情報を求める場合は、この章ではカバーできないほどの多くの情報がドキュメントにありますので、そちらを参照してください。
ローカルスケジューラを使用する場合、ワークアイテムを実行する際にオーバーヘッドを減らす方法を考えることが重要です。プロセスの起動やワークのスケジュールなどがオーバーヘッドを引き起こす要因となります。これは、TOPネットワークで利用可能なスロットの数に依存します。
スロットとは、TOPネットワークが同時に実行できるジョブの最大数と考えることができます。スロットの数を設定することは、主に自身のマシンの性能や行う作業の種類に依存します。作業がマルチスレッドであるか、利用可能なコア数はいくつあるかなどが考慮されます。
これらの要素は、使用するスロットの数を決定する際に重要な役割を果たします。また、TOPネットワークを最適化するための他の方法として、エラーレスポンスの導入やカスタム環境変数の設定などがあります。これらはすべて、ローカルスケジューラ内で行うことができる作業です。スロットの数だけでなく、各TOPノード内のプロセスも最適化することができます。
TOPノード、例えばROP FetchやROP Geometryなどは、ジオメトリのキャッシュを扱います。これらの連番ジオメトリやバッチと一緒に作業することを考える必要があります。シミュレーションをキャッシュしたい場合、通常はこれらのフレームを1つのプロセスにまとめて、バックグラウンドでHoudiniのセッションが実行されるようにしたいと思います。これにより、シミュレーション全体のキャッシュが行われます。
ジオメトリに時間の依存性がない場合、マルチスレッドでジョブが実行されているかどうか、フレーム数はいくつあるかなどを考慮し、それに応じてフレームをバッチ処理する必要があります。これにより、同時に必要なプロセスが過剰でも不足でもないようにします。
スロットやフレームのバッチ処理などの概念は現時点では混乱するかもしれませんが、これらは心に留めておく必要のある重要な概念です。設定を理想的な状態にするためには、試行錯誤が必要かもしれません。しかし、TOPsはこれらのパラメータを設定するための非常に簡単なツールを提供していますので、最初のテストで正確な設定をする必要はありません。