-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
[wasm] Outline exception throws in the interp and ifdef out unreachable opcodes #79239
Conversation
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsIn my testing it improves performance if we outline exception throwing logic and don't include cases for unreachable opcodes. Based on a dump of the resulting dotnet.wasm module, this makes interp_exec_method ~3kb smaller and reduces the nesting depth by a bit as well. According to my local browser-bench runs this makes the interpreter much faster for some workloads - I saw a consistent 1ms speed-up on some of the JSON test cases. My assumption is that interp_exec_method is big enough and complex enough that we are falling off performance cliffs and this somehow gets us back up one of the cliffs.
|
Tagging subscribers to this area: @BrzVlad Issue DetailsIn my testing it improves performance if we outline exception throwing logic and don't include cases for unreachable opcodes. Based on a dump of the resulting dotnet.wasm module, this makes interp_exec_method ~3kb smaller and reduces the nesting depth by a bit as well. According to my local browser-bench runs this makes the interpreter much faster for some workloads - I saw a consistent 1ms speed-up on some of the JSON test cases. My assumption is that interp_exec_method is big enough and complex enough that we are falling off performance cliffs and this somehow gets us back up one of the cliffs.
|
…m version of the mono interpreter for better performance
…y opcodes respectively
…targets for them Just use preproc if for the wasm only opcodes
94905c9
to
f8b6c42
Compare
… included when it is used
In my testing it improves performance if we outline exception throwing logic and don't include cases for unreachable opcodes. Based on a dump of the resulting dotnet.wasm module, this makes interp_exec_method ~3kb smaller and reduces the nesting depth by a bit as well.
According to my local browser-bench runs this makes the interpreter much faster for some workloads - I saw a consistent 1ms speed-up on some of the JSON test cases. My assumption is that interp_exec_method is big enough and complex enough that we are falling off performance cliffs and this somehow gets us back up one of the cliffs.
For unreachable opcodes the solution used here is to define a new
IROPDEF
category for opcodes that are meant for internal use and not meant to be executed - they all get moved to the end of the list and don't need cases defined or entries in the computed goto table, which makes interp_exec_method a bit smaller as well.There are other opcodes that would benefit from this but I found that changing them caused weird test failures, so we can do that later.