Hello, Concerning your comment: "What we really should do is to recognize that the result is always used as an integer, avoiding deopts when the modulus is non-zero or some kind of overflow happens [...]"
I have a patch doing this optimization in hydrogen when the result is used in bitwise operations. I will upload it soon. Alexandre On Fri, Nov 25, 2011 at 7:50 AM, <[email protected]> wrote: > > Comment #3 on issue 1840 by [email protected]: High num of deopts for > attached production code from game engine > http://code.google.com/p/v8/issues/detail?id=1840 > > Let's clarify things a little bit regarding division: There is nothing wrong > with the JavaScript code, and it doesn't matter whether you use "&-1" or > "|0", although I find the latter more intuitive, but this is probably only a > personal preference. The problem is within v8: The optimizing compiler is > currently a bit naive regarding division when both operands are known to be > integers, expecting the result to be an integer, too, deoptimizing if not. > This is OK for other arithmetic operators, but it practically always fails > for division. Using floating point arithmetic the next time works without > deopts, but it hurts performance. > > What we really should do is to recognize that the result is always used as > an integer, avoiding deopts when the modulus is non-zero or some kind of > overflow happens (this would improve e.g. additions). Recognizing this > syntactically is far too fragile IMHO, so we should come up with something > more clever. > > Another thing: Would it be possible for you to prepare a slightly modified > version of your code, namely a single self-contained JavaScript file > suitable as a benchmark? AFAIK there are no license issues with the PVR > decompression algorithm, but I could be wrong... > > > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
