> Object.prototype.valueOf = function() { alert("IE9 is fast!"); }
こうすると、 a + b; という文はDCEされちゃいそうだが、実際はalertが二回呼ばれる(のでDCEしてはいけない)
> That said, I don't think it's possible to consider IE9's implementation of Dead Code Elimination to be a serious general purpose optimization. It seems clear that it hasn't been tested on anything other than SunSpider.
ieblog (スコア:3, 参考になる)
http://blogs.msdn.com/b/ie/archive/2010/11/17/html5-and-real-world-sit... [msdn.com]
Dead Code Elimination in JavaScript のところにMSの言い分あり。
Re: (スコア:0)
つまり
4. 自動最適化により無意味な演算を検知してスキップしてたのが、「true」や「return」が挿入されたせいでスキップに失敗してベンチマークスコアが低下した。
ということ？
Re: (スコア:0)
まぁ、コレが真実だとすると、理由としては「３」に近いものとも言えるかもですね。
# しかしまぁ、古今東西みんな陰謀論好きねぇ。
Re: (スコア:0)
マイクロソフトは陰謀を企ている程度でよかったじゃないですか。
某企業の、信仰者に仕立て上げるみごとなカルト教団っぷりに比べれば。
Re: (スコア:0)
Re: (スコア:0)
まあ元々というかIE9の前はJavaScriptエンジンには不思議なくらい力を入れてなかったからねえ。重大な戦略ミスだったけど。
Re:ieblog (スコア:1, 興味深い)
COMベースで汎用的に様々なアプリケーションから利用・拡張できるように作られているという点では、かなり力が入ってます。
Re:ieblog (スコア:1, 参考になる)
ところがIE9からはJavascriptだけブラウザ内蔵になりました。
COMベースのJScriptは呼び出しのオーバーヘッドがバカにならなくて、、、
置いてきぼりのVBScriptがかわいそう。
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
まだ正式版でないIE9に何を期待してるのか知りませんが、品質面でまだまだなのは当たり前・・・じゃなきゃとっくに正式版として公開してるでしょう
Re: (スコア:0)
Re:ieblog (スコア:2, 参考になる)
> Object.prototype.valueOf = function() { alert("IE9 is fast!"); }
こうすると、
a + b;
という文はDCEされちゃいそうだが、実際はalertが二回呼ばれる(のでDCEしてはいけない)
> That said, I don't think it's possible to consider IE9's implementation of Dead Code Elimination to be a serious general purpose optimization. It seems clear that it hasn't been tested on anything other than SunSpider.
つまり、IE9の開発者は上記の事実に気がついていなくて、SunSpiderだけでチェックして安心しているという状態のようだ。升しているわけではなさそうだよ。
Re:ieblog (スコア:3, 興味深い)
Dead Code Elimination for Beginners [mozilla.com] (Rob Sayre's Mozilla Blog) の話ですね。
速度向上のために「最適化」と称して仕様違反を犯すのを擁護する気はないのですけれど、一方で「a+b;」という式文をデッドコードとして除去できない言語が広く使われているのは不幸だなあとも思います。本題と関係ありませんけど。
Re:ieblog (スコア:2)
> 一方で「a+b;」という式文をデッドコードとして除去できない言語が
コンパイラならこういうコードを警告の対象にできるけど
インタープリタの場合、どうすべきなんだろう？
Re:ieblog (スコア:1, 参考になる)
> > 一方で「a+b;」という式文をデッドコードとして除去できない言語が
> コンパイラならこういうコードを警告の対象にできるけど
> インタープリタの場合、どうすべきなんだろう？
最初のparse時にvalueOfプロパティが定義されていなくても動的に追加されるかもしれませんし、evalとかECMAScriptの言語仕様上は結びついてないけどsetTimeoutやDOMイベント経由で結びついてるコードパスとか考えると、要するに不可能ってことです。
C++でもoperator+()が定義されていればどんなフリーダムなことでも出来ますが、ある程度は静的解析で何とかなります。
Re:ieblog (スコア:1, 参考になる)
C++でもoperator+()が定義されていればどんなフリーダムなことでも出来ますが
重箱の隅をつつくようですがC++のoperatorは差し替えどころかvirtualが許されていません。
「operator+()が定義されていればどんなフリーダムなことでも」というような特別なものではなく、ただの関数です。
なので、my_add()だろうがoperator+()だろうが、最適化の可能性は平等です。
Re: (スコア:0)
敢えてやるとすれば、初回コンパイル時にvalueofが無ければ最適化されたコードを出しておいて、関係する値のvalueofが更新されたらon-the-flyで再コンパイルするとか。
Re: (スコア:0)
古典的コンパイラでもデッドコードは静的なインライン展開などの結果として出てくることがほとんどだし、
どうしてもというのならJITコンパイラがDCEするのが筋でしょう。
Re: (スコア:0)
function func(a, b) {
var x;
var i = 300;
while (i--) {
x = a + b; // dead store
}
}
静的な解析で x = a + b; がデッドコードの候補になることがわかるから、明示的にチェックするようなコードに変換すると
while (i--) {
if (!(a has valueOf) && !(b has value
Re: (スコア:0)
Objectにセッターやゲッターが設定されていて、それがaやbを更新するような関数である可能性が捨てきれないから、DCEできる条件はより厳しくなるね。