EntisGLS4s 最新バージョンを公開したかったのですが、色々忙しくて、そうこうしているうちに、書きかけのソースが混ざってきて、公開出来ない状態に。
一応、ARM 用 JIT コンパイラが機能しますので、次のバージョン（いつになるかは不明ですが）で実質上、Android用のアプリを開発できる初めのバージョンになると思います。
因みに、WindowsとAndroid共通で利用できるメニューインターフェースが次バージョンで追加されています。まあ、WindowsとAndroidだとメニューUIの見え方はだいぶ違うわけですが…、プログラム的には同一コードで走りますよ、というものです。
あと、イラストとかも描きたいんですけどねぇ〜、もう本当に時間がない。
とりあえず、ARM用JITコンパイラでSakura2VMの全命令をVFPやNEON命令に変換できるようにしたので、以前にパフォーマンステストに使用した物と同じ物をARMで実行してみました。
4x4行列とベクトルの積を連続的に計算して所要時間から実効FLOPSを求めるものです。
右端の列がC++コンパイラで出力したネイティブバイナリで、その左が同じコードを詞葉コンパイラでコンパイルしたSakura2バイナリ、その左はSakura2VM用の手書きインラインアセンブリコードによるものです。
（※JIT ARMv5 は実際の ARMv5 で実行するとこの10倍ほど遅くなる可能性があります。JIT コンパイラが ARMv5 用コードを出力する場合、浮動小数点命令は関数の呼び出しコードを出力するのですが、ARMv7 の場合その関数が VFP 命令を使用しています）
結果をザックリ見ると、Atom 1.86GHz と ARM 1GHz がおおよそ近い速度となっていますね。C++コンパイラによるネイティブバイナリの結果はだいぶ違いますが。
あと、手元にある唯一の NEON 環境である APQ8055 はどうにも NEON 命令の出来が悪そうですね。
NEON 命令を出力した場合、そうでない場合よりずっと少ない命令数になっているのにそうでない場合より遅いという…。
一つ前の日記でも書きましたが、CPU側が「なんちゃってSIMD」実装になっていたり、特定の命令がパイプライン化されていないために寧ろ遅くなっている感触です。理屈上はこの数倍のパフォーマンスが出ても不思議ではないのですが…。
実機が Android2.2 とか 2.3 なのでいい加減 Android4 も買って新しいCPUで試してみたいところではありますが、そのためだけに買おうと言う気もしないところです…（汗）
長い長〜〜〜い苦悩に満ちたデバッグ作業を超えて、ARM用JITコンパイラがかなり出来上がってきました。
まだ Sakura2VM 用の全 SIMD 命令をネイティブに変換できるわけではありませんが（しかし大半は完了）、色々テストしたりは出来ています。
で、パフォーマンスを調べたのですが…………………orz
いえ、JITコンパイルせず、逐次実行した場合よりは高速に走ります。それは確かです。が、NEONを使用した場合の期待された速度の数分の1しか出ていない…。
詳しく見てみると、どうもいくつかの命令が「なんちゃってSIMD」実行されている（又はパイプライン化されていない）ような気配。（ある特定の命令だけ10〜20クロック掛かっているような感じ）
とりあえずテストしている環境が結構古いCPUなので、なんちゃってSIMDはありえるので無視して進めようかと思います…。
因みに、実行速度はどんな感じかと言えば、逐次実行 1500ms → ARMｖ5用ネイティブ化 600ms → ARMv7用ネイティブ化 150ms → NEON用ネイティブ化 140ms みたいな感じです。
一応、ARMv6からの古いSIMD命令があるので、ARMv7用のJITコンパイルではSIMD命令が使用されるのですが、レジスタ数の都合によるロードストアの頻度やその他の理由による命令密度の差だけで考えても少なくとも3倍、SIMD命令の効果も含め5倍はNEONの方が高速になるだろうはずだったのですが、………この有様です。
因みに上の例の同じ処理のC++コード版をgccでネイティブにコンパイルしたものを実行した場合は60ms程度です。VC++でx86にした物をCore2で実行した場合（クロック比で補正して）20msほどで、SSE2用JITコンパイラで実行した場合も20msほどです。
|
