※本ページの記事は「後編」となります。前編記事はこちら

予想通り、⑤BuildModel～⑦BuildTextureの部分でCPUノードを追加した場合に大きな変化が見られました。同一ノードのみで実施の場合は前回同様に処理時間は横並びですが、CPUノードに処理をさせた事で差が発生しました。⑤BuildModelと⑦BuildTextureに関しては処理時間が短くなり、逆に⑥BuildUVに関しては長くなっています。

ここで改めて今回のクラスタノードとCPUノードのCPUを比較します。

クラスタノード側の方が単独コアの動作速度は速く、CPUノード側の方がコア数が多いといった関係になります。ここから、⑤BuildModel 及び ⑦BuildTexture時間はコア数が有効に働く処理であり、⑥ BuildUVは単独コアの動作速度が重要であるということが推測されます。

また、④BuildDenseCloudの処理時間については、4ノード(クラスタ4台)の結果よりも時間がかかっています。これはGPU処理よりも処理速度が遅いCPUにCPUノードが増えた分だけ処理が分散されてしまい、GPU搭載のクラスタノードは処理が終わっていても、CPU側の処理が終わらず、その処理が終了するのを待ってしまっていた結果と推測されます。実際にはこの処理はログ上では複数の処理に分割され (今回の検証においては106～108 程度)、処理が終わったら次の処理...と渡されていくため、分割された最後の処理が終わるタイミングによっては逆に処理時間は速くなる可能性も考えられます。
なお今回のクラスタノードは同一のCPU/GPU構成ですが、異なるCPUやGPUでの構築をされた場合、速度の遅いCPUやGPUなどがこの処理でボトルネックになる可能性があるということが考えられます。

最後に、「処理内容について」の項目で挙げました、Build Meshの処理をUltra Highで実施しなかった理由については『実施できなかったため』となります。1クラスタあたり40GBのメモリでは今回のデータを処理するのには足りず、処理が進みませんでした。

潤沢にメモリをもっているCPUノード構成 (768GB)の場合はUltra Highでも処理が可能でしたので、Build Meshに関してはノード1台に処理が集中してしまう関係上、その1台に十分なメモリが必要であると推測されます。

まとめ

以上、クラスタを利用したMetashapeの処理速度の検証結果となります。

前編・後編を通してのここまでのデータを元に検討しますと、④BuildDenseCloud処理まではクラスタ構成が有利ですが、それ以降の処理についてはあまり効果的ではないと言えそうです。

また、上記でも触れております通り、Build Meshなどの処理は結局の所、 1台のCPUで処理をする必要があり、その1台に十分なメモリ容量も必要となってきます。クラスタ構成を検討する場合でも、全体の処理として考えた場合に、メモリが足りない事により必要としている処理ができないという可能性がございますので、少なくとも1台は十分なメモリを積んだPCを用意していただくのがよろしいかと思います。

単独クロックの速いCPUを選択しても、搭載できるメモリ容量には上限がありますので、メモリ搭載量の面で見れば、Xeonシステムのほうが有利となります。そのため、単純に単独クロックが速いCPUがお勧めとも言い切れないところがあります。
※今回検証に使用したCPU (Core i9 9900K)は64GBまでのメモリに対応となります (2019年4月時点。将来のRevでは128GBに対応が予定されています)。

現状でMetashapeクラスタ構成を検討する場合、通常は個別で利用しているMetashapeを、大規模な処理が必要な場合に一時的にクラスタとして利用する使い方や、④BuildDenseCloud処理までの作業を行わせるサーバーファームとしての運用等が考えられます。

なお、今回の検証では速度計測をメインにおいておりましたので、すべて1ジョブのみで実施をしておりましたが、当然複数のジョブを実行することも可能です。この場合、処理がBuild Meshに入った時点で、計算している1台のマシン以外がフリーになった場合には次のジョブが走り始めますので、複数のジョブを投げて短時間で処理をさせるという用途でもクラスタ構成は有効であると思われます。

■ 2019年7月11日追記  : こちらの検証に利用したクラスタノードPCを事例として公開しました

クラスタ1台での処理速度が少し遅いのが目につきますが、クラスタの結果を見た限りでは 台数に応じて速度が速くなっています。ただ、GPUの枚数による差が少なく見え、果たしてクラスタ構成処理の効果があるのか...？という疑問がでてきます。

この分布から判断しますと前半の ①MatchPhotos～④BuildDenseCloud までの処理速度は、ある程度GPUやクラスタ台数のスケールを反映していますが、⑤BuildModel～⑦BuildTexture までについてはクラスタ台数によっての速度はあまり変わらないという結果になりました。
なお実際の検証時には計測中の負荷を確認していたのですが、⑤BuildModel～⑦BuildTexture のあたりの処理はすべて1台のクラスタノードでのみ実施されており、他のクラスタノードでは処理がされていないという状況が確認できました。

 
そしてもう一つ気になる点として、それぞれのフェーズにかかる時間にも注目する必要があります。
今回の計測では⑤BuildModel～⑦BuildTexture の時間が今回テストしたトータル処理時間の50%以上をしめています。

ここで最初に示した ①MatchPhotos～⑦BuildTexture までの一通りの処理時間を計算した結果のグラフを再度確認していただきたいのですが、本来であればGPUを2枚搭載したかなりのハイスペックであるはずの比較用単体システム(紺色のグラフ)ですが、実際には同じくGPU2枚のクラスタシステム2台(水色のグラフ)での処理よりも時間がかかっているという結果が出ていました。この原因を考えた場合に、比較用単体システムとクラスタシステムとの間でのGPU枚数以外のスペック差が、トータル処理時間の50％を占める⑤BuildModel～⑦BuildTexture の処理において、大きく影響しているのではないかと推察されました。

それを前提にスペック比較したところ、CPUにその要因があるように見受けられました。
改めて2つのCPUを比較して見てみます。

クラスタ側のTB (Turbo boost)が 5.0GHzで動作するのに対して、単体システム側はTB 4.50GHzでの動作となっています。つまり⑤BuildModel～⑦BuildTexture については、CPUの単独クロックが処理速度に対して特に有効となるという推測が成り立ちます。

では⑤BuildModel～⑦BuildTextureを、今回の例より十分に多いコア数優先の処理 にした場合にどうなるのか...？という疑問が発生します。
この疑問については近日公開いたします"「Metashape」のクラスタ構成での処理速度測定と傾向検証 (後編)"でのオルソ画像処理の一連のバッチ処理の検証結果と共にご報告します。

■ 2019年6月28日追記  : 後編記事を公開しました！

■ 2019年7月11日追記  : こちらの検証に利用したクラスタノードPCを事例として公開しました