スポンサーリンク

T.Ishii's Software Library

HTML5 レトロ風ゲーム館

無料ブログはココログ

« 一筋縄では行かない | トップページ | スマートTVなのかも »

色々作って試した

今日は、AG-ムービーカッターのJNIに入れる画像拡大ルーチンを色々な形式で作ってみたのだが、32Bit環境では、MMX命令を使うのが一番軽くなり、64Bit環境では、64Bit長の変数を使ったCPU命令が一番軽くなった。SSE2命令はどちらでも重くは無いが大して軽くもない。

今の所、一番軽いのは、64Bit環境用に、64Bit長の変数を使ってCPU命令のみでコードを書いた場合で、ある動画の再生時に、CPU負荷は7%程度になる。

で、32Bit環境では、MMX命令を使った場合が一番軽いのだが、その場合には、同じ動画を再生した時の負荷は9%程度になる。

SSE2命令を使った場合、64/32Bit環境の双方でCPU使用率は11%になるため、上記よりは劣るのだが、32Bit環境で、64Bit環境用のCPU命令を使ったコードを動かすと、CPU使用率は14%程度になって、再生フレーム数も低下しているため、これよりはずっと軽い事になる。

と、いう事で、32/64Bit環境の双方で使えるコードという意味では、SSE2命令を使ったモノが優秀なのだが、上記のように、32Bit環境ではMMX命令に、64Bit環境ではCPU命令に負けてしまっている。

なので、どの道、32/64Bit環境ではJNI用のライブラリは別々に作らなければならないため、画像の拡大処理用には、SSE2命令の出番は無さそうだ。

では、何故、SSE2命令を使ったコードが大して軽くないのか、というと、SSE2命令を使っていないコードでは、メモリフェッチに関してかなりの最適化を行えているのに対し、SSE2命令を使った場合には、その辺の最適化が困難なため、行えていないからだろう。

また、そもそも、SSE2命令というのは、同時命令実行数が少ないのかもしれない。少なくとも、64Bit環境では、SSE2命令を使った方が記述されているコード量は少ないのだが、同様の処理をCPU命令でやった方が速い感じだ。

64Bit環境では、CPU命令を使った場合が最高速になっているのだが、同様のコードはJavaでも書ける。なので、JNIを使った場合とJavaのみで動作させた場合も比べてみたのだが、JNIを使った方が1割程度は軽かった。

その理由は、多分、JNIルーチンでは、メモリフェッチを8バイト単位で行えているからだろう。Javaの場合、データはintの配列に入っているため、4バイト単位でしか読み込めない。

ちなみに、今日、Windows8のRelease Preview版が公開されたので、バイナリのダウンロードだけはしたのだが、まだ、インストールはしてみていない。

ネットの情報を見ていると、Consumer Preview版に対して、あまり大きな変化は無いようなので、後回しにしてあるのだが、多分、数日中にはVirtualBoxで仮想マシンにインストールしてみる事になる筈だ。

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

AmuseGraphics

AmuseGraphics

(2013/12/07追加)

« 一筋縄では行かない | トップページ | スマートTVなのかも »

トラックバック


この記事へのトラックバック一覧です: 色々作って試した:

« 一筋縄では行かない | トップページ | スマートTVなのかも »

2020年4月
      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    

広告

プライバシーポリシー

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

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

    収集された情報がGoogleによってどの様に使用されるか、収集される情報をユーザーが管理する方法については、以下のリンクを参照下さい。

    ポリシーと規約 - Google