http:/
プロパティのアクセスに関する部分及びJIT。
pathの切り方は違えど、tamarin-ttと比べて本質的に特殊な事をしている感はないなあ。
先生も仰ってますが、map transitionの方が本質かも。
ただ、やるなら汚いかもしれないけどコンストラクタを特別視くらいしてもバチは当たらない気がする *0 。
けど、IC::set_target()は受けるなあ。
今時これはないだろー。
プロセッサ/コンパイラ依存部を広げるに見合ったリターンがあるとは思えんのだけど。
組込分野も狙っているのなら、なおさら普通に関数ポインタでやろうよ *1 。
と、なかなか趣のあるコードで楽しかった。
最後のnativeとの比較が面白いです。javaとの比較も欲しいとこですが、
前向きに考えれば、jsはまだまだ可能性としては100倍以上速くなるってこった!
やったーー!!まだjsエンジン開発者は仕事にあぶれずに済みそうです。めでたし。
しかし、組込み機器でもECMAが重要な要素になってくるとなれば、
jazelleみたいなECMA支援命令付きARMとか出てきても面白いんじゃないかな。
とはいえ、例えばプロパティのアクセスをハード化するとして、
本気で高速にしようと思ったら相当な回路規模になるわけで *2 、
それに見合う効果が本当にあるのか難しいところ。
そこまで頑張るくらいならその面積を全部L1,L2に回せば良かったということになりそうだし。
なんとも最適化しずらい言語だ。
いつもjsを見て思うのは、なんでこんな実行効率の悪い言語が標準になっちまったんだってことだよ。
javaがプリウスとすれば、戦車並みの燃費の悪さだよ、js。
「燃費」あれこれ
http:/
最近のV8エンジンは燃費が良いのね
http:/
ベスト燃費王
http:/
どこを走ったらそんな燃費が…
*0 : というか速さのためなら様々なものを既に犠牲にしている感じなので、やって然るべきでは
*1 : x86以外はまず32bit即値ジャンプなんてできないと思うのだけど、そうなると書き換えアドレスがspから予測不可能になるので、関数ポインタ実装にならざるをえない
*2 : 超強力なキャッシュ回路を想定
*1 : x86以外はまず32bit即値ジャンプなんてできないと思うのだけど、そうなると書き換えアドレスがspから予測不可能になるので、関数ポインタ実装にならざるをえない
*2 : 超強力なキャッシュ回路を想定