それなりには作られている

今は、Mirror-DTCの次バージョンの開発フェーズで、数日前に書いた様に、4k解像度のPCを操作する場合、性能がイマイチ足りないので、向上させようか、と、現行版のコードを見ているのだが、それなりには作られている。

作者製ソフトの場合、まずは、性能が命、みたいな、MasterReversiの開発から入ったので、マルチスレッド動作だとか、SIMD命令の使用は、当たり前に行ってきている。

なので、現行版の性能を向上させようとする場合、単に、マルチスレッド化しました！ だとか、SIMD命令を使う様にしました！ なんて単純な事では、性能向上はできなかったりする。

しかしまあ、MasterReversiのリバーシエンジンと比べれば、その他ソフトの場合、それなりに甘い作りにはなっているので、MasterReversiのように、1割の性能を向上させるために、数ヶ月の開発期間を要しました！ なんて事にはならない様な気がする。

逆に言えば、甘い作りにしてあるのは、開発期間が異常に長くなってしまうのを避ける為、つまり、開発が楽になる様に！ という事なので、その状況から、更に性能を向上させようとすると、当然、大変な開発が必要になる。

と、言う事で、現状は、どこまで真面目に作ってあるのかなあ、というのを現行版のコードを見ながら確認していたのだが、今日の表題にした様に、それなりには、作られている感じだ。

つまり、それなりに性能が出る様な作りになっているので、更に、性能を上げようとすると大変な気がしないでもないのだが、現行版では、主要処理のマルチスレッド動作については、8スレッドを上限にしてあった。

これは、数年前までは、巷の普通に購入できるPCのCPUは、高性能タイプでも4コア8スレッド！ といのが普通だったし、作者的にも、そんなCPUが搭載されたPC/Macしか所有していなかったので、スレッド数をより多くしても手持ち環境で性能確認は出来なかったし、巷で、そんな多スレッド動作で恩恵を受ける人も少なかった筈だからだ。

しかし、今では、12コア20スレッドのCore i7-12700を搭載した仕事用iiyama PCと、8コア16スレッドのRyzen 9 5900HXを搭載したMINISFORUM のミニPCを所有しているので、少なくとも、16スレッドくらいまでは、実機で性能確認できる様になった訳だ。

と、言う事なので、次バージョンでは、前述のマルチスレッドの上限を8スレッドから、少なくとも16スレッドには上げる予定なので、それだけで、高性能な多コアCPU環境では、マルチスレッド性能は上がるかもしれないのだが、Mirror-DTCサーバーというのは、何度か書いてきた様に、縁の下の力持ち！ になる訳だ。

つまり、Mirror-DTCサーバーがCPUの性能を使い切ってしまったら、何のために、リモート操作しているかわからなくなる訳なのだが、数日前に書いた様に、Mirror-DTCの場合、ユーザーが、画面の転送レートだとかを設定できるので、Mirror-DTCサーバーのCPU使用率が高すぎる！ と、感じた場合には、フレームレートを落としたりして、CPUリソースを本来使いたいソフトに回せたりはする。

また、次バージョンでは、CPU Affinity機能も搭載するし、上記の上限とは別に、ユーザー設定で、利用するスレッド数を制限できる様にもする予定なので、ソフト的なスレッド数の上限は、普通は、そこまで使う事はないだろう、みたいにしておいても問題はないかなあ、という感じだ。

と、言う事で、次バージョンのMirror-DTCでは、マルチスレッド動作時に使用するCPUコア数の上限を上げるので、多コアの高性能CPU環境では、現行版よりも、処理性能は向上する事になる筈だ。

上記の変更については、作業は簡単で、変更後の動作検証に少し時間をかける程度で済む筈なのだが、問題は、多分、マルチスレッド化していない処理をどうするか、という事になる。

具体的には、Mirror-DTCでは、AGM動画形式と似た様な形式で、画面映像のエンコード/デコードを行っているので、DCT/IDCTの様な変換処理はマルチスレッド化してあるのだが、それらのデータをコード化する処理については、シリアル動作になっているので、この処理のマルチスレッド化を行うかどうかが問題になる訳だ。

AGM形式動画の場合、普通はデコード性能は問題にならないので、エンコード性能を向上させるために、コード化処理についても、マルチスレッド化した。

もっとも、シリアル動作をマルチスレッド化するのは大変なので、複数フレームのエンコードを同時動作させる事で、複数のシリアル動作のコード化処理が同時にスレッド数分動作する格好にした。

その結果として、エンコード性能は、それ以前よりも向上したのだが、Mirror-DTCの場合、リアルタイム動作になる訳なので、複数フレームのエンコードを同時に行う！ なんて事にしたら、複数フレームを貯める必要が出てくるので、遅延が発生する格好になってしまう。

なので、Mirror-DTCの場合、シリアル処理をマルチスレッド化させる場合には、シリアル処理自体をマルチスレッド化できる様に改変する必要が出てくるので、大変になってくる。

更に、現行版のコードを見ていると、サーバーについては、シリアル処理の内容を二段階に分け、1段階目はマルチスレッド動作させている。

つまり、既に、シリアル処理のマルチスレッド化についても、手を付けている感じなので、この状態から、更に、高速化を行おうとすると、それなりに大変な改変が必要になりそうだ。

そして、それだけの努力をしたとしても、性能向上は数割もあれば良い所！ の筈なので、どうしたモノかなあ、と、今日の時点では思っている。