スポンサード リンク

T.Ishii's Software Library

HTML5 レトロ風ゲーム館

無料ブログはココログ

« 2倍重いが圧縮率も2倍 | トップページ | その他の変更項目 »

効率よりは馬力

今は、Mirror-DTCの次バージョンを開発中で、AGM-DCT+を使ったストリーミングモードも使える感じになった。なので、仕上げの一環としてエンコード/デコードの性能を向上中なのだが、そのメイン施策はマルチスレッド方式の変更で、効率よりも馬力優先に変更している。

かなり前、Android版AGMPlayerを開発していた頃に、性能が足りないので、マルチスレッド方式を変更した事があったのだが、今回も、その時と同様の変更を行っている。

具体的には、従来のマルチスレッド方式というのは、例えば、4コアCPUでは、フルHD画面に対する処理は、予め、画面を4分割し、それぞれの領域を一つのコアに処理させる、という感じにしてあったのだが、変更版では、画面をより細かく分割し、各コアに、順次、処理させる、という方式にしてある。

何故、上記の様な方式に変更しているのか、というと、特にMirror-DTCの場合、画面変化が無い領域については、エンコードもデコードも行わなくてよい仕組みを入れてあるので、同じ画面領域サイズを処理させたとしても、真面目に処理するコアと殆ど何もしなくても良いコアが発生する事になるからだ。

つまり、現行版の処理ルーチンでは、折角、CPUが4コア持っていても、真面目に仕事をするのは、その中の1,2コアだけ、というケースが多々あったので、全コアが均等に仕事が出来る様に、処理領域をより細かく分け、殆ど何もしなくても良い領域を割り当てられて、即刻暇になってしまったコアにも、更に、次の仕事を与えられる格好にした訳だ。

上記を見ていると、現行版の方式よりも良さそうに感じる筈なのだが、確かに、馬力という点で見れば、より良い方式になる。

何故なら、CPUコアが遊ぶ時間が減る格好になるので、それだけ、総合処理性能は上がるからなのだが、複数スレッドが真面目に仕事をしていると、OSのタスクスイッチングの頻度は上がる筈だし、メモリアクセスなんかも同時に行われるので、CPUキャッシュの効き具合も悪くなったりするケースがある筈だ。

なので、処理時間を気にしなければ、極端な話、マルチスレッド動作よりは、シングルスレッド動作の方が、タスクスイッチングは減少し、CPUキャッシュの効きも良くなる筈なので、より、効率的という事になる。

で、現行版のマルチスレッド方式は、処理が不要な領域が多い場合には、遊ぶコアが多くなるのだが、そもそも、処理が不要な領域が多い場合には、全体の仕事量も減る訳なので、何も全コアを動作させる必要も無い訳だ。

このため、現行版では、処理効率も鑑みて、領域分割をあまり細かくは行っていないのだが、これは、仕事量が減った場合には、遊んでいるコアが出てきても、問題は無かったからだ。

具体的には、現行版では、フルHD-30FPS転送くらいをターゲットにしていたので、仕事量が減って遊ぶコアが出てきても、処理時間的には、30FPS転送に間に合う格好になっていた訳だ。

これに対し、次バージョンでは、ストリーミング圧縮を導入したのだが、これの処理負荷は現行版の映像圧縮よりも2倍程度重い。更に、Desktop Duplication APIの導入により、60FPS転送も現実的になった。

つまり、現行版よりも2倍程度重いストリーミング圧縮を使って、60FPS転送を行おうとすると、現行版の半分の時間で、少なくともエンコード処理については、2倍の仕事をこなさなければならなくなるので、サーバー側には4倍の馬力が必要になる。

なので、CPUコアを遊ばせている余裕は無くなったので、処理効率が少々低下したとしても、全コアが真面目に仕事できる格好に持っていく事にした訳だ。

ちなみに、全コアを真面目に使わなければならない、という事は、処理性能に余裕が無い、という事になる。

つまり、CPU性能が良くない場合には、少なくともストリーミング圧縮を選択した状態でのフルHD-60FPS転送は行えない事も多くなる筈なのだが、マルチスレッド方式を変更したので、全画面動画の再生状況は60FPS転送できなくても、ウインドウ表示の動画再生状況なら、余裕で60FPS転送できるケースも多々出てくる筈だ。

これは何故なのか、というと、例えば、4コアCPU環境で、画面の1/4の領域で動画を再生していた場合、現行版では、実質的には、エンコードは1コアで行われる格好になるケースも多々あったのだが、次バージョンでは、この場合にも、普通は、4コアが使われる。

なので、次バージョンでは、上記の様なケースでの性能向上も見込まれるのだが、実際の所としては、今回の変更は上記の様なケースを想定してのモノだ。

何故なら、全画面動画の再生時には、現行版でも、遊ぶコアは無かった筈だからなのだが、次バージョンでは、現行版でマルチスレッド化していなかった処理もマルチスレッド化している。

特に、現行版では効率を鑑みてシングルスレッド動作にしてあったクライアントについても、マルチスレッド動作に変更したので、現行版では60FPS転送できなかったマシン環境でも、次バージョンなら、60FPS転送できる様になる場合は多いかもしれない。

= この記事に関連する公開中ソフト =

Mirror-DTC

Mirror-DTC

(2016/05/04追記)

« 2倍重いが圧縮率も2倍 | トップページ | その他の変更項目 »

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/534482/63097788

この記事へのトラックバック一覧です: 効率よりは馬力:

« 2倍重いが圧縮率も2倍 | トップページ | その他の変更項目 »

2017年8月
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

広告

プライバシーポリシー

  • 当サイトでは、第三者配信による広告(Google Adsense)サービスを利用しています。

    Google を含む第三者配信事業者は、Cookie を使用して、ユーザーのウェブサイトでの閲覧履歴に基づく広告を配信します。 Google 広告 Cookie を使用することにより、Google や Google のパートナーは当サイトや他のサイトへのアクセス情報に基づく広告をユーザーに表示できます。

    Cookieを無効にする設定およびAdsenseに関する詳細については、以下のリンクを参照下さい。

    広告 - ポリシーと規約 - Google