あんまり厳密な解析じゃないけど。
ちなみに測定環境は、
- 型式:Acer AspireRevo R3610
- CPU:Atom330 / 1.6GHz / 64Bit
- メモリー:4GB
という、環境。
CPUに関しては、性能の悪さに定評のあるAtom。
この環境で開発もやっているから、Android用のコンパイルには物凄く時間が掛かります。
ですが、ベンチマーク用としては妥当です。
グラフィック(GPU)性能がちょっと良すぎる点がアレですが。
まず、VG-Engine(グラフィックのみ)でプロセスを起動した場合、CPU使用率は約5%前後。
で、VG-Sound(と、命名したオリジナルPSG音源エミュレータ)で、6ch同時に発音した状態で測定したところ、CPU使用率は概ね約7~8%前後。
ちょっとだけ、上がってしまいました。
ですが、この程度であれば、Android上でもサクサク動けます。(多分)
かなり、性能面には気をつけました。主に、
- パイプラインハザードの防止
- 浮動小数点は使わない
前者は単純に分岐回数を可能な限り少なくするだけ。
(ループ値は論理積を使うなど)
後者は、本当に性能upに寄与するか、ケースバイケース。
例えば、エンベロープの計算に百分率が必須ですが、百分率を整数のみで計算する場合、
- 割られる数×100 ÷ 割る数 = p(100%なら100)
- n×p÷100 = nのp%の値
※ここでは説明をし易くするために百分率といってますが、 実際は128分率とか64分率などで計算するのが一般的
FPUが高性能な場合、全ての数値を浮動小数点数で計算すれば、結果的には浮動小数点数のみで計算した方が命令の実行ステップが少ない分、高速になる可能性があります。ただ、実数は精度が悪い(表現できない数が多い)ので、「全てを浮動小数点数で」という部分がネック。音の場合、波形データは整数(16bitの2の補数)だから、FPUが早くても整数・実数間の変換がボトルネックになるし、パイプラインハザードは極力実装レベルでも防いでいるからステップ数はあまり問題にならない筈だ・・・
ということを悶々と考えた結果、実数を排除するのがベストと判断。
(単純に、実数がキライだというのもあります)
結果、Windowsではそこそこ良い性能結果だったので、読みは当ったんだろうと、思っておきます。
Androidでも同じ結果になるかは、定かではないですが。
0 件のコメント:
コメントを投稿
注: コメントを投稿できるのは、このブログのメンバーだけです。