チューニング方針 - Scheme VM を書く

論文を読んだので方針を決めたいところ。

読んで学んだのが「無視できないディスパッチのコスト」を考慮しなければいけないということ。
threaded コードは既に実施済みなので、命令の合成が効果的が高そうであるということがよく分かった。
少なくとも論文の実験ではかなり効果が出ているので実績もある。
という前提を踏まえて考える。

今の目的は「0.0.1のリリースまでに現時点での想定される用途に対して十分速いインタプリタを実現する（かけられるコストも現実的な線で）」こと。
なので

などは 0.0.1 リリース後に行う。

十分速いってのは

あたりを考えています。

それの実現に向かってやっていることが2つある。

短いベンチマーク比較においてあと一歩 Gauche に及ばないところがあり、それを改善したい。
ただしそればかりやるとそのベンチマークに特化した最適化になってしまう恐れがある。
一方で本当に短いコードなのでコードレベルでの比較がしやすく VM の弱点を見つける格好の題材でもある。

もっと大きなコードも通してみるのも良いのだけど個人的には、それらの短いコードたちが Gauche と同程度になるまで突き詰めるのもありかなとも思う。
だめだ発散してきた。

無理やりまとめると以下の順序で進めるのはどうでしょうか？＞Gakuさん

ループ内処理で短く、軽くできる部分がないかもう一度検討
今ある合成命令などを基本命令以外を削除しつつ計測
- 命令セットを最小限にした場合の計測をすべきだと思う
短いコードに対して頻出命令を合成命令にするのをためしつつ効果を計測
- 1つ計測すればその方針が正しいかどうか分かるはず。
- 有望そうであれば合成命令の構築の仕組み作りをして、いろいろなコード片を投げ込んで統計をとる
- 頻出の命令を合成する