These are chat archives for Constellation/iv

8th
Mar 2014
iseki
@iseki-masaya
Mar 08 2014 05:48

diagramに入るために、呼び出し回数を数えれるように変更しようと思ってるのですが、以下の2つの方法のどちらをとろうか迷ってます。

  • 同じメソッドだった場合、同じインスタンスが呼ばれるようにinstructionを変更する。(SpiderMonkeyのJSScriptみたいな感じです。)
  • instructionの実行部分をindexに辞書を作成し、値に呼び出し回数を設定する。

1つめは、SpiderMonkeyにならってJSScriptのようなものを作成しようと思ったのですが、スコープの問題でrailgunへの変更が必要になり変更箇所が大きくなりそうだなと思ってます。

2つめにすると、既存のコードの変更点は少なそうですがlook upの時間がネックにならないか心配です。
Yusuke Suzuki
@Constellation
Mar 08 2014 10:29

同じメソッドだった場合、同じインスタンスが呼ばれるようにinstructionを変更する。(SpiderMonkeyのJSScriptみたいな感じです。)

これ, 具体的にはどのような感じでしょうか? railgun::Code に記録するのではまずいですか? 自分はそれでいいかと思っていたのですがー.

Yusuke Suzuki
@Constellation
Mar 08 2014 10:45
counter 入れましょうか?
iseki
@iseki-masaya
Mar 08 2014 12:00
勘違いしてるかもしれないですが、railgun::Codeはinstructionの集合(LLVMのModuleのような)になっているのではないのですか?
もしそうなら、メソッドごとにインクリメントして欲しいので、railgun::Codeに持たせてもintなどのプリミティブな型ではなくハッシュのようなデータ構造を持つ必要があると思うのですが...
Yusuke Suzuki
@Constellation
Mar 08 2014 12:45
railgun::Code は 関数一つに対応するので, method の invocation count を持たせるのであれば, railgun::Code に対して買うたんをもたせるのが良いと思うのですが, 違いますか?
あと, counter をいれるとすれば, backward jump を行っている instruction に対して, その instruction の属する railgun::Code の counter を increment することで, hot code の検出ができると思います.
なにかうち勘違いしているかもです.
global の code の execution が railgun::Code から開始しているのは, global の code を表現している railgun::Code を実行しているためで, railgun::Code は children に railgun::Code を持っているという構成になっています.
Yusuke Suzuki
@Constellation
Mar 08 2014 12:53
ちょっと counter 入れます. 例えばですが.
あと, call の最適化もしないと... Call IC 入れて, 関数の呼び出しを記録します (inlining 用)
Yusuke Suzuki
@Constellation
Mar 08 2014 13:12
https://github.com/Constellation/iv/commit/ba961ffc3d6dc2833cc30535b84ae54c492eac2a invocation の counter はこれでよいです. railgun::Code と method は 1 on 1 対応があるので.
iseki
@iseki-masaya
Mar 08 2014 14:40

global の code の execution が railgun::Code から開始しているのは, global の code を表現している railgun::Code を実行しているためで, railgun::Code は children に railgun::Code を持っているという構成になっています.

ここを理解していませんでした。counterの追加ありがとうございます。

この後の処理についてまだ理解していなのですが、counterが閾値を越えるまで型情報を集め、最も使用される型に特化したアセンブラをLLVMで作るという流れであってますか。現状ではintに対応したアセンブラのみを吐き出すようになっているので、他の型に特化したアセンブラも吐き出せるようになるので高速化が期待されるという認識であってますか。

Yusuke Suzuki
@Constellation
Mar 08 2014 14:56
はいそうです. boxing / unboxing の除去, inlining, type specialized code の出力を目指します.
Yusuke Suzuki
@Constellation
Mar 08 2014 18:08
pushed aero-optimize branch. Optimizing Aero regexp runtime to get fine performance on SunSpider & V8.
Yusuke Suzuki
@Constellation
Mar 08 2014 18:14
To get nicer performance, we need to simply JSString implementation
with Cons / Seq Strings.
Current implementation is too complicated and it's not good for performance.