Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Speed up registerizeHarder variable conflict checking #3371

Merged
merged 7 commits into from Apr 21, 2015

Conversation

aidanhs
Copy link
Contributor

@aidanhs aidanhs commented Apr 20, 2015

Results in a 50% speedup in sqlite compilation!

This PR is based on the observation that vector access is much faster than set/map access. By mapping names to numbers and using a vector we can speed up all conflict setting (first 3 commits). I then mitigate the perf hit to iteration by filtering the vector outside of the loop which would iterate over it (final commit).

All asm3 tests pass, as does test_other. I should probably be noting that I don't have spidermonkey installed so some parts of tests (e.g. actual sqlite execution, though I did check that with nodejs) aren't being run. This obviously also affects the before/after for sqlite below.

Before (after #3368):

~/em/emsdk/emscripten/incoming/tests $ python runner.py asm3.test_sqlite 2>&1 | grep 'test in'
Ran 1 test in 61.199s
~/em/emsdk/emscripten/incoming/tests $ EMCC_DEBUG=1 emcc -O3 --llvm-lto 1 -s EMULATE_FUNCTION_POINTER_CASTS=1 -o out.js python/python.bc 2>&1 | grep 'js opts'
DEBUG    root: emcc step "js opts" took 5.23 seconds
~/em/emsdk/emscripten/incoming/tests $ cd ~/em/BananaBread/cube2/src/web
~/em/BananaBread/cube2/src/web $ (make && time make client server) 2>&1 | grep real
real    0m28.940s

After this pr:

~/em/emsdk/emscripten/incoming/tests $ python runner.py asm3.test_sqlite 2>&1 | grep 'test in'
Ran 1 test in 29.944s
~/em/emsdk/emscripten/incoming/tests $ EMCC_DEBUG=1 emcc -O3 --llvm-lto 1 -s EMULATE_FUNCTION_POINTER_CASTS=1 -o out.js python/python.bc 2>&1 | grep 'js opts'
DEBUG    root: emcc step "js opts" took 3.17 seconds
~/em/emsdk/emscripten/incoming/tests $ cd ~/em/BananaBread/cube2/src/web
~/em/BananaBread/cube2/src/web $ (make && time make client server) 2>&1 | grep real
real    0m18.117s

@kripken
Copy link
Member

kripken commented Apr 21, 2015

I haven't read the patches yet, but the js opts part on sqlite goes from 35.84 seconds to... 5.73 (!). That's much more than a 50% speedup! But it's so big I was kind of worried that something changed in the output for the worse, so I'll ran the benchmark suite on this... and it looks like code speed and size remain the same. Awesome!

Starting to read the patches now.

@aidanhs
Copy link
Contributor Author

aidanhs commented Apr 21, 2015

Yes, my 'flagship measurement' at the top is based on the overall compilation time, just as an interesting demonstration of how much js optimisation was previously dominating compilation time. Bananabread is similarly measuring overall compilation time. Only python drills down to js opts time. If I start putting together more optimisations maybe I'll try and present both the individual and overall speedup for clarity. Though maybe I need to focus elsewhere now :)

I too was very surprised, which is why I ran all of test_other and asm3 and tweaked the sqlite test to run under nodejs on my PC just to check it actually ran. I'll have to add the benchmark suite to my list for validating my changes.

@aidanhs
Copy link
Contributor Author

aidanhs commented Apr 21, 2015

FYI, I've just pushed a tiny followup commit to improve code clarity. It has no performance impact I can measure (possibly a very slight improvement).

@kripken
Copy link
Member

kripken commented Apr 21, 2015

Looks good. I had just a few minor questions.

@kripken
Copy link
Member

kripken commented Apr 21, 2015

Ok, that addressed all my questions, thanks. Merging.

@kripken kripken merged commit 3bc4e10 into emscripten-core:incoming Apr 21, 2015
@aidanhs aidanhs deleted the aphs-optimize-optimizer-3 branch April 22, 2015 00:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants