web-worker slower for asm code

RESOLVED INCOMPLETE

Status

()

Core
JavaScript Engine
RESOLVED INCOMPLETE
5 years ago
8 months ago

People

(Reporter: mbirukou, Unassigned)

Tracking

25 Branch
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [bugday-20131106])

Attachments

(1 attachment)

147.73 KB, application/gzip
Details
(Reporter)

Description

5 years ago
Created attachment 826224 [details]
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.
(Reporter)

Comment 1

5 years ago
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.
(Reporter)

Comment 2

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

Updated

5 years ago
Component: Untriaged → DOM: Workers
Product: Firefox → Core
Whiteboard: [bugday-20131106]
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.
Component: DOM: Workers → JavaScript Engine

Comment 4

5 years ago
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

5 years ago
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

5 years ago
Note: Emscripten has its own minifier that does respect "use asm" and is much much faster than Closure.
(Reporter)

Comment 7

5 years ago
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

5 years ago
(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.
Still an Issue with Bug 927516 fixed?
Flags: needinfo?(mbirukou)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 months ago
Flags: needinfo?(mbirukou)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.