--- tests/sunspider-0.9.1/math-cordic.js 2010-11-17 00:55:29.000000000 -0700
+++ tests/sunspider-0.9.1-deadcode/math-cordic.js 2010-11-17 15:08:43.000000000 -0700
@@ -80,11 +80,15 @@
///// End CORDIC
+function numNumNum() { var I; var num = 10; for (I = 0; I < 10; I++) { num = num + num + num + num + num - num; } }
+
+///// End CORDIC
+
function cordic( runs ) {
var start = new Date();
for ( var i = 0 ; i < runs ; i++ ) {
- cordicsincos();
+ numNumNum();
}
var end = new Date();
Chrome: 19.2ms
IE: 1.0ms
I think this is just fragility, not cheating. I don't know JS super well, but in some languages you might see some rules associated with certain operations and preserving over/under flow exceptions and such.
In any case I think a few things happened here:
1) For whatever reason the "true" statement caused the compiler to think there was a side-effect potential. I suspect the compiler simply didn't know what to do with it, and they hadn't handled 'true;' or 'false;' as standalone statements in their optimizer. I bet if you put 'true;' in the middle of that loop it will break the DCE.
2) The probably don't do liveness analysis. So they can see that a block doesn't change global state, but don't look to see if the proceeding blocks use any of the variables. So if there is any code after a block they assume that they can't DCE that block.
3) '*' and '%' causing problems may be very specific to those operations, and I'm guessing '/' too.
All in all I'd say it is a target incomplete implementation, but not cheating. Based on what I've seen thus far.
Comments
Cheald, could yu run this test:
function numNumNum() { var I; var num = 10; for (I = 0; I < 10; I++) { num = num + num + num + num + num - num; } }
See if that changes the results?
Sure. That does, in fact, optimize well!
Edit: I just published my testing setup here: https://github.com/cheald/SunSpider-deadcode
Curious.I think this is just fragility, not cheating. I don't know JS super well, but in some languages you might see some rules associated with certain operations and preserving over/under flow exceptions and such.
In any case I think a few things happened here:
1) For whatever reason the "true" statement caused the compiler to think there was a side-effect potential. I suspect the compiler simply didn't know what to do with it, and they hadn't handled 'true;' or 'false;' as standalone statements in their optimizer. I bet if you put 'true;' in the middle of that loop it will break the DCE.
2) The probably don't do liveness analysis. So they can see that a block doesn't change global state, but don't look to see if the proceeding blocks use any of the variables. So if there is any code after a block they assume that they can't DCE that block.
3) '*' and '%' causing problems may be very specific to those operations, and I'm guessing '/' too.
All in all I'd say it is a target incomplete implementation, but not cheating. Based on what I've seen thus far.
And also, thanks for doing the run and posting a link to your setup.