See https://bugs.chromium.org/p/v8/issues/detail?id=4203 - you need to enable chrome://flags/#enable-asm-webassembly

I've enabled the flag and tried again.
I got the same results as before ~50MiB/s.

I'm getting: 
Invalid asm.js: Invalid type after new. In ed2k.js:36
Probably because I'm not passing window for the stdlib parameter (ed2k.js:260).
I get the same error/warning in Firefox but I can't pass the window function since the asm code is started in a web worker.

Well, only valid asm.js code is converted to wasm so there's probably nothing Chrome can do here. 

On the other hand, this feature is a work-in-progress so it may be buggy.

Sorry I accidentally deleted the plunker.
New one: https://plnkr.co/edit/nkqEeBMR3VIrZDLnAZ25?p=preview

I did some more testing:
If I pass self instead of null in ed2k.js:260 which is probably more correct and prefix the Uint32Array and Uint8Array types with stdlib in the asm code,
the console doesn't report "Invalid asm.js: Invalid type after new." anymore but "Invalid asm.js: Invalid number of arguments when creating heap view.", which is a few lines down from the previous error.
But instead of continuing (albeit slowly compared to FF) it stops executing there.
The constructor should exists going by http://html5index.org/Typed%20Arrays%20-%20Uint32Array.html

Anyway there should be a way to write valid asm.js code in a web-worker while using the UintXXArray types.
Otherwise the two features can't be used in combination.

Unfortunately it is not possible with asm.js to create heap views (i.e. with the UIntXXXArray) that don't start a offset zero and span the full size of the underlying array buffer. Only the single argument constructor is allowed. The is specified here (look for "A global heap view is of the following form"):

http://asmjs.org/spec/latest/#global-variable-type-annotations

Even if this would be fixed somehow, the code contains other JavaScript idioms that are just not part of asm.js which would cause subsequent validation failures. Taking a first glance I could spot the following:

- Parameter "state" and "data" are not primitive data types, both seem to be heap views.
- Missing type annotation for parameters (e.g. the "length" of "hashCore") and local variables.

In short, the provided code is not valid asm.js code (neither in Chrome nor in other browsers). That being said, I can see the performance difference described above. Might still be interesting for the JavaScript proper pipeline.