934048 - web-worker slower for asm code

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[mbirukou]

Attachment: Comparison.tar.gz

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131028112446

Steps to reproduce:

Attached file contains html, which uses scripts with both js, and asm code, generated by emscripten. Both do encryption routines.
Runs in web-worker just recently were substatially slower than those in UI event loop for both js and asm. But with current v25 (on Ubuntu x64) js code runs just percents slower in web worker, while asm code is three times slower.
This is not the case in Google Chrome, so I file this bug.
Also note that there was a similar report, but for simple js test code, and that run fine for me, while both js and asm were slower in web-worker.

Comment 1

[mbirukou]

Actually, even js code is slower. Its just that 623 in web-worker vs 280 milliseconds in UI loop for 1MB encryption (on 3GHz system). So, both js and asm in contained file run slower in a web worker.

Comment 2

[mbirukou]

I should detail, that ecma-nacl code is what I referred to as just js, while js-nacl is emscripten-produced asm.js

Comment 3

[Ben Turner (not reading bugmail, use the needinfo flag!)]

I don't know if this is really a worker thing... Maybe some JIT flag we're not setting? Tentatively moving to JS so that the more knowledgeable folks can weigh in or investigate.

Comment 4

[Luke Wagner [:luke]]

The attached code does not validate as asm.js.  For one thing, it doesn't include "use asm" anywhere that I can see.  asm.js generation is the default in Emscripten nowadays; perhaps you could try rebuilding with a recent pull of Emscripten?

This means that both the "asm.js" and "normals JS" are using the normal Ion JIT heuristics.  Why is the asm.js slower in workers?  I suspect it is due to bug 927516: since we don't use background compilation in workers, we use a lower threshold for scripts that are judged too big to compile.  If there are some big functions in the asm.js, they may be getting stuck in our slower baseline JIT.

If you generate validating asm.js, then all these heuristics are bypassed and you should see the same perf in workers as on the main thread. To confirm you have validating asm.js, look for a success/failure warning in the JS console.  E.g., see http://kripken.github.com/ammo.js/examples/new/ammo.html for asm.js in a worker.

Comment 5

[Alon Zakai (:azakai)]

The code looks like it was optimized with closure compiler. Closure compiler is unaware of asm.js, so its output is not going to be valid asm.js.

Emscripten will not run closure on asm.js output for that reason. How did you generate this code? (What emcc command, what other stuff - did you run closure manually?)

Comment 6

[Luke Wagner [:luke]]

Note: Emscripten has its own minifier that does respect "use asm" and is much much faster than Closure.

Comment 7

[mbirukou]

But even regular code (ecma-nacl) gets slower, take a look at numbers in the test. May be the Emscripten thingy is not relevant here.

Comment 8

[Luke Wagner [:luke]]

(In reply to mbirukou from comment #7)
Yes, that is in line with what I was saying in comment 4: non-asm.js-validating code may run slower in workers because of bug bug 927516.

Comment 9

[(mostly gone) XtC4UaLL [:xtc4uall]]

Still an Issue with Bug 927516 fixed?