[wasm] Outline exception throws in the interp and ifdef out unreachable opcodes #79239
Conversation
kg
added
arch-wasm
ghost
assigned 
|
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
kg
force-pushed
the
outline-interp-throw
branch
from
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
IROPDEFcategory 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.