Asm.js Chess Battle
dev.windows.com
dev.windows.com
That seems like a strange test. They aren't testing JS against ASM, or even compiled-to-vanilla-JS vs compiled-to-ASM. Both versions are compiled to ASM (complete with all strange annotations like num|0), only one has the asm optimizations disabled. I don't know enough about asm to know if their annotations are slower than vanilla JS in unoptimized engines, but I suspect they might be.
I was also surprised that asm still won in Chrome - I thought Chrome optimized for asm-like code without checking for the "use asm" flag.
The opposite is true, for the most part. JS engines, even without asm.js optimizations, utilize the fact that the | operator emits a 32-bit integer (per the JS semantics), so it helps their type inference.
(The engine needs to be good enough to get rid of the actual 0 value in the |0 coercions, but JS engines have been that good for several years now anyhow.)
> I was also surprised that asm still won in Chrome - I thought Chrome optimized for asm-like code without checking for the "use asm" flag.
Chrome detects "use asm", and enables TurboFan on such code. All JS engines today detect "use asm", except for JavaScriptCore.
This was very infuriating. The server seemed to be under load and took several minutes to load. I was not going to wait for it load again to retry the simulation.
$('#chess__board-message').click(function() { var m = new ChessDemo.Match(); m.$boardOverlay.hide(); m.startNextTurn(); });So White sacrifices (loses?) a pawn for no compensation on move 2. Not really sure what this says in respect of the experiment in general, but it does smell a little.
Also; Showing the dark squares would be a massive usability advance! And it would be nice if they respected some simple and fundamental chess conventions (for example presenting the moves in the way I did in my comment above - move numbers increment after whole moves not half moves)
There is a move history, but you have to expand it.
Though in this case, I think it's almost certainly a blunder, that line does not appear to be a well known opening.
It's not a serious opening though, it looks frivolous - could be played in simultaneous games, or in bullet chess for its surprise value etc.
If you optimize the opening book to include serious games only, you're unlikely to come across this line. http://www.chessgames.com/perl/explorer?node=98&move=2&moves...
Given the insame amount of opening theory research humanity has done by now, if e4 on the third move here was even remotely close to a clever sacrifice, chess community would have noted it by now.
Without one, they have only a second to come up with an opening, so it's no surprise if the result is weird.
More specifically, Firefox and Edge detect "use asm" and run an asm.js type-checker, while Chrome detects "use asm" and runs TurboFan.
I played 4 times on Safari with varying settings and it always converged into 50%/50% play ending in a draw.
Whereas in Firefox or Chrome sometimes even after 10-15 turns, the asm.js version had 98-100% chance of winning.
When you push it up to 1000ms per move, since the difference between 15 moves ahead and 16 moves ahead is so large, both engines end up making 15 moves ahead and win / lose about half the time, even though asm.js is visiting more nodes.
That's funny.