What kind of performance should I expect running Emscripten generated code? Cos' mine is AWFUL!

[Gareth Morgan]

I am experimenting with using Emscripten generated code in my Javascript application. The results are pretty disappointing performance-wize. I am seeing 40x slower on Chrome 49.0.2623.110 (compiling with emcc -o3) versus a release build on visual studio.

I have a fairly straight forward marching squares based geometry generation function, running in a plain EXE complied with visual studio in release mode, the function call takes around 2.5ms (as reported by QueryPerformanceCounter), the identical function run in my javascript appliction takes 90-100ms (measured by Date().getMilliseconds()). I have verified the time scales roughly with the size of the problem, so it's not just setup/JIT cost.

My compile line is this;

emcc DCEL.cpp MS.cpp Blob.cpp -o html/Blob.js -O3 -s EXPORTED_FUNCTIONS="['_Blobify','_Init']"

 

I realize there is no native code support on this version of Chrome, but is this expected? Am I missing an optimization step?

[Charles Vaughn]

Can you share code, or at least the output JS? there's a lot of factors that will cause Emscripten built JS to perform poorly.

[Gareth Morgan]

Code here:

https://www.dropbox.com/s/ft2dzlpkjfbav32/html.zip?dl=0

Ashara.js is the calling JS file, Blob.js is the generated file.

I actually verified this only happens on Chrome, Firefox seems better (8ms).

[Charles Vaughn]

So your Blob.cpp is llvm bitcode, not sure if that's what you wanted, but in anycase, I believe you're seeing somewhat expected behavior from Chrome. Basically, the JIT is coming into play, Firefox uses asm.js specific AOT, so it'll give best runtime perf at possibly some startup cost. As far as Chrome, the turbofan optimizer just kind of takes asm.js as a hint about the type of optimizations it can do, but the first time you run that function, it's running interpreted. I bumped up the program memory size, and ran the blobify method 10 times, this was the resulting times:

Blobifying took 85ms

Ashara.js:211 Blobifying took 56ms

Ashara.js:211 Blobifying took 26ms

Ashara.js:211 Blobifying took 18ms

Ashara.js:211 Blobifying took 12ms

2Ashara.js:211 Blobifying took 8ms

Ashara.js:211 Blobifying took 9ms

Ashara.js:211 Blobifying took 8ms

Ashara.js:211 Blobifying took 7ms

[Floh]

I'm usually seeing less then 2x slower performance than native on average for code both in Firefox and Chrome (e.g. this voxel demo does a lot of stuff CPU work, both floating point and integer when producing new voxel mesh chunks, and the performance is at least in the same ballpark across all browsers and native versions: http://floooh.github.io/voxel-test/)

First thing I'd try is to run the code on Firefox, since this does AOT compile which guarantees that the code isn't 'de-optimized' during runtime.

If you get any warnings about large functions during linking, look into emscripten's outlining feature which breaks large function bodies into smaller ones (large functions may confuse JIT JS engines)

Next try traditional profiling, compile with optimization and the --profile option (this keeps function names readable), and run the code through the Javascript profiler in browser dev-tools, this should give you a good idea where most time is spent.

I'm not sure about the state of 64-bit integer support in emscripten, but if your code is doing a lot of 64-bit integer stuff, this might be worth looking into.

Also, if your code is doing WebGL stuff there are a number of additional things that can go wrong where WebGL has different performance behaviour than desktop, but from reading your description I guess that's not the case.

Finally, it is possible that your code triggers a bug in the Chrome Javascript engine, that's why it is important to test on as many different browsers, platforms and browser versions as possible.

Hope this helps,
-Floh.

[Gareth Morgan]

Thanks for the suggestions.  Running a few warmup passes does seem to improve things, but I am still about 3-4x slower than Firefox.

--
You received this message because you are subscribed to a topic in the Google Groups "emscripten-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/emscripten-discuss/Gj8zKC_F1KY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to emscripten-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Charles Vaughn]

Since Chrome takes a different approach to handling asm.is, you're always going to see some pretty big variance. For general investigation, I've found the allow-natives option to be helpful as that surfaces control over the JS optimizer. You can see more about that here: https://github.com/petkaantonov/bluebird/wiki/Optimization-killers