Live data from Hacker News

Asm.js Chess Battle

dev.windows.com

11–20 of 39 posts

Re: Asm.js Chess Battle

#11

> Refresh page to play again 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.

Seriously. Came here to say this. How hard is it to add a button that says "play another".

FWIW, I put this in console so I could click the banner at the end to start over:

  $('#chess__board-message').click(function() { var m = new ChessDemo.Match(); m.$boardOverlay.hide(); m.startNextTurn(); });

Re: Asm.js Chess Battle

#12
The code they are benchmarking is written in C, then compiled to asm.js (presumably with Emscripten). In one version, they remove the "use asm" header, but the code appears identical.

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.

Re: Asm.js Chess Battle

#13
post #3

Earlier quoted context omitted.

Safari doesn't implement an asm.js backend, presumably?

Nor does Chrome, but I think Chrome takes the `"use asm";` as a hint to use certain optimisations.

Chrome should enable turbo fan with the "use asm"; set. Though the only confirmation of this is saying it's tested in beta. https://code.google.com/p/v8/issues/detail?id=2599#c77

Re: Asm.js Chess Battle

#14
post #9

So does this mean that asm.js is good for longer operations? Because I tried reducing the think time and the engine lost.

I think it rather means that the search time was short enough that neither search tree got deep enough to form advantageous moves. (When I check the detailed output, it seems that the asm.js version visits at least 2x as many nodes as the un-optimized version, independent of Time-per-turn)

Re: Asm.js Chess Battle

#15
Interesting. I slowed a game down to 1000ms per move so I could realistically follow what was going on. The game started 1.Nf3 Nf6 2.e4?

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)

Re: Asm.js Chess Battle

#16

Interesting. I slowed a game down to 1000ms per move so I could realistically follow what was going on. The game started 1.Nf3 Nf6 2.e4? 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 sim…

It's almost certainly playing out of an opening book.

There is a move history, but you have to expand it.

Re: Asm.js Chess Battle

#17

The code they are benchmarking is written in C, then compiled to asm.js (presumably with Emscripten). In one version, they remove the "use asm" header, but the code appears identical. 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 optimizati…

> 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.

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.

Re: Asm.js Chess Battle

#18
post #3

Interestingly, asm.js has an advantage in Firefox and Chrome for me, but not in Safari.

Safari doesn't implement an asm.js backend, presumably?

That's correct, all JS engines except for Safari's detect "use asm".

More specifically, Firefox and Edge detect "use asm" and run an asm.js type-checker, while Chrome detects "use asm" and runs TurboFan.

Re: Asm.js Chess Battle

#19

Interesting. I slowed a game down to 1000ms per move so I could realistically follow what was going on. The game started 1.Nf3 Nf6 2.e4? 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 sim…

It's almost certainly playing out of an opening book. There is a move history, but you have to expand it.

How does playing out of an opening book explain the opening blunder 2. e4?

Re: Asm.js Chess Battle

#20

Earlier quoted context omitted.

Nor does Chrome, but I think Chrome takes the `"use asm";` as a hint to use certain optimisations.

Chrome should enable turbo fan with the "use asm"; set. Though the only confirmation of this is saying it's tested in beta. https://code.google.com/p/v8/issues/detail?id=2599#c77

It's in release Chrome currently.
Post reply on HN