Hacker News new | comments | show | ask | jobs | submit login

Kannan, if you want to fix it, the Java diff is:

- return ((double)1)/((i+j)(i+j+1)/((double)2+i+1));

+ return 1.0/((i+j)(i+j+1)/2+i+1);

That gives the same count as the JS. It'd be interesting to know whether Dalvik/ARM has the same performance hit on NaN!


I think the "/2" should be a "/((double)2)", since in C and Java it'll treat the former as a truncated int divide. I do see the issue with the precedence on the 2+i+1, though. Will fix up and re-run.

You're quite right. You can also use 2.0

Fixed up and pushed to repo. If you see anything else that's incorrect, please feel free to let me know either by posting or through mail, and thanks again for pointing that out.

With the changes, the scores didn't change dramatically, and the asm.js version got a bit faster too, actually coming in closer to the native score than before, which is weird. Overall, scores got better across the board by about 8% or so.

The fact that asm.js does better now than it did before somehow suggests to me that there may be an issue in the NDK libc's malloc or free implementation, and that the better scores are simply allowing that issue to have more effect. This is another one of those programs which does a bunch of "biggish" allocs/frees repeatedly.

I'll put the updated charts up with an edit note shortly.

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact