Alchemy too slow…?

by syoyo

LLVM を使って C のプログラムを Flash で動かせるようにした Alchemy がリリースされ、
Alchemy はパフォーマンスが必要なプログラムに向くということで、
ベンチマークを取ってみました.

ベンチマークに使ったのは AmbientOcclusion レンダラの C 版.
(これを今後は AO ベンチマークと呼ぶ事にしよう)

http://lucille.svn.sourceforge.net/viewvc/lucille/angelina/proce55ing/c_reference/


C(gcc4.4 -O3) : 2.6 secs
Alchemy       : 480 secs(8 分)

(参考: 前回のパフォーマンス比較)

う、遅すぎ…
AS3 版 AO の結果よりもさらに 8 倍も遅い…

Alchemy 版は、以下の手順でコンパイルして速度を計りました.


$ alc-on
$ gcc -O3 ao.c
$ time ./a.exe
/Users/syoyo/src/flex_sdk_3.2/bin/adl _sb_19448/app.xml 2> /tmp/adl.trace & echo $!
...

遅さの原因はどこに

Alchemy の gcc を使い、gcc -O2 -c として中間の LLVM ビットコードオブジェクトでコンパイルを止め、
llc -march=c として C に変換して普通の gcc でコンパイル実行したら、
普通のネイティブ(通常の gcc)と同じくらいの早さだったので、
中間言語の時点では大きな速度低下になるような要因はないようです.
(不思議なスタブ関数がいっぱい挿入されるとか)

なので、やはり AVM の性能や、LLVM 中間言語 -> AVM トランスレータあたりに速度低下の原因があると思います.
関数呼び出しのオーバヘッドが大きいとか、JIT が利いていないとか、サンドボクシングでポインタ経由のメモリアクセスにいろいろチェックが入っているとか、なのかもしれません.

Shark で Alchemy で生成したバイナリをプロファイリングしてみましたが、
シンボル情報がないのか JIT 生成された関数なのか、
時間を占める上位関数はアドレス情報しかありませんでしたので、
なにをやっているところが時間がかかっているのかよくわかりません.

ただ、時間を占めている関数のアセンブラを見ると分岐と call ばかりの命令列でしたので、
たぶんやはりスタブ関数呼び出しとかサンドボクシングのチェックとか、インタプリタ実行とか、そこらへんなのかなぁと.

Advertisements