Can confirm.
A multithreaded (2-threads) asm.js app of mine, built with the latest emscripten, is extremely slow on 62 (and 63), while it's totally fine on 61.

I've tried disabling the automatic asm.js->wasm conversion through chrome://flags/#enable-asm-webassembly but that didn't help.

Okay so I did some digging (ie manually bisecting v62 chromium snapshots), and here's what I found so far:

rev 493418 is working fine
https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Mac/493418/
v8_revision_git: 56e70c0758431ee16c2beec7e47a2d3d0c8322d0

rev 493432 is broken
https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Mac/493432/
v8_revision_git: 452f86d592afdd6bebaf067bcf5edc783485d61c

Assuming the bug is in v8, the diff would be https://chromium.googlesource.com/v8/v8/+log/56e70c07..452f86d5
That would lead to https://chromium.googlesource.com/v8/v8/+/961a2c885d82502e7c90915883443435d27762d0

This seems to be already fixed on V8 tip-of-tree and the underlying asm.js source validates successfully. I'll investigate what the fix was and see if there is something we can merge back.

mstarzinger@ does that mean that emscripten creates invalidate asm.js and thus wefall back to the JS interpreter?

Unable to provide the bisect details from TE's end as the issue is not observed on the signed builds. Please find the screenshot attached.

Observations on Beta builds are as below:
Ubuntu 14.04 Beta #62.0.3202.45 - Average FPS is 70.84.
Mac 10.12.6 Beta #62.0.3202.52 - Average FPS is 80.87
Windows 10 Beta #62.0.3202.52 - Average FPS is 6.34

Note: 
1. Issue is not observed on the latest Canary #63.0.3238.0.
2. Removing the 'Needs-Bisect' label as the issue is already assigned.

Thanks!

Deleted: 771563.png 157 KB

	771563.png 157 KB View Download

@pnangunoori@chromium.org :

For me, the latest official ("Version 62.0.3202.52 (Official Build) beta (64-bit)") still shows the issue.
In fact, the latest chromium v64 (as of https://chromium.googlesource.com/chromium/src/+/ef23a427a2e7329a301f51fc9d9c1347b028332d) also shows it.

It'd be pointless for me to give you a link to my test page since it's an emulator and would require you to have a ROM (which I can't share), but I'm sure a lot of other publicly testable things are broken... :(

Isn't my comment #3 above helping related to bisecting?

I noticed that version 62 became official version of Chrome. So now I have:

chrome://version/
"
Google Chrome	62.0.3202.62 (Oficjalna wersja) (64-bitowa) (cohort: 62_62_win)
Wersja	9da914b118cb0d10d715ccc4ad20575a0305a304-refs/branch-heads/3202@{#700}
"

On that version I don't have performance issues. On the same computer I have also installed Chrome 62 beta:

chrome://version
"
Google Chrome	62.0.3202.62 (Oficjalna wersja) beta (64-bitowa) (cohort: Beta)
Wersja	9da914b118cb0d10d715ccc4ad20575a0305a304-refs/branch-heads/3202@{#700}
"
This version has performance issues.

Could you help me to understand why exactly the same version of chrome is working ok in official release and has problems in beta build?

+bradnelson

Is this a finch anomaly?

FWIW, I have just tried the latest official stable "Version 62.0.3202.62 (Official Build) (64-bit)" on a linux machine, and I still have the performance issues of the beta.

Could you please try to explicitly Enable and Disable the asm.js validator via the entry in about:Flags? See screenshot.

Yeah I tried that already (see comment 3), tried it again now just in case, but with both enabled and disabled, the performance is very bad, so it's unrelated to what that does. (However, as expected, the "Invalid member of stdlib" warning messages go away when in Disabled - the flag itself isn't broken).

In case I wasn't clear enough, the Chromium builds before https://chromium.googlesource.com/v8/v8/+/961a2c885d82502e7c90915883443435d27762d0 were working fine. mstarzinger said something got fixed in ToT but I'm not sure if it's been merged back since (apprently not?)

If you are getting this "Invalid member of stdlib" message, it means that your module is not validating, and it is going through the normal JS pipeline.

Does your module verify without problems on Firefox?

Sorry, it was not clear to me that you already tried this out in C3#. You can try to run it with the latest Canary to verify if it is fixed on ToT or not.

@titzer@chromium.org : correct. The issue is that the script itself hasn't changed (wasn't validating before either), yet it was running at full/normal speed on v61.
On Firefox, the performance is good, although I have this warning: "TypeError: asm.js type error: asm.js Atomics only enabled in wasm test mode". I can try on Safari as well if needed.
Note: my script uses Atomics and SharedArrayBuffers.

@hablich@chromium.org : will do soon. I tried it again on latest dev channel, still not good. 10 days ago I tried on a v64 and it was good either but I'll try again.

(I meant "was not good either", on v64, sorry)

Unfortunately our asm.js validator cannot help on invalid asm.js code, so this is not really an asm.js problem. Atomics and shared array buffer are future features that are farther out on our time horizon, and it is not clear if we will optimize them for asm.js before WASM.

FWIW the regression is caused by V8's overall switch to Ignition/TurboFan. You might consider manually removing the "use asm" annotation, since that might still impact our optimization heuristics.

(note that I closed this bug since it is not really an Emscripten/asm.js issue). The performance issue around atomics would/should manifest in other scenarios. Feel free to file another issue for a smaller testcase.