You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Wasm does not differentiate between imported and internal function calls and uses the same Wasm bytecode for both cases. This is fine since both cases can be handled using the same bytecode given the Wasm encoding. However, for an interpreter such as wasmi it might be beneficial to differentiate between both cases at translation time so that those checks do not need to be performed during execution time of the bytecode.
In fact we were aware of this optimization for a long time, however, wasmi's execution model was a bit weird with respect to calls so that this optimization would have very likely yielded no benefits to us. However, with the very recent refactoring of the internal wasmi execution engine this might have changed and we should definitely experiment with differentiating between calls to imported functions and calls to Wasm module internal functions.
The big advantage here is that usually calls to Wasm module internal functions are more common and at the same time more efficient. By introducing a new wasmi bytecode to represent Wasm module internal function calls we can get rid of several checks during execution time.
For this we will require the following wasmi bytecode instructions:
CallImported: Very similar to the Call instruction today but can only call imported host or Wasm functions.
CallInternal: Can only call functions internal to the Wasm module.
CallIndirect: No changes since indirect calls cannot be optimized by this technique.
ReturnCallImported: Same as CallImported but as tail call.
ReturnCallInternal: Same as CallInternal but as tail call.
ReturnCallIndirect: No changes since indirect calls cannot be optimized by this technique.
The text was updated successfully, but these errors were encountered:
Wasm does not differentiate between imported and internal function calls and uses the same Wasm bytecode for both cases. This is fine since both cases can be handled using the same bytecode given the Wasm encoding. However, for an interpreter such as
wasmi
it might be beneficial to differentiate between both cases at translation time so that those checks do not need to be performed during execution time of the bytecode.In fact we were aware of this optimization for a long time, however,
wasmi
's execution model was a bit weird with respect to calls so that this optimization would have very likely yielded no benefits to us. However, with the very recent refactoring of the internalwasmi
execution engine this might have changed and we should definitely experiment with differentiating between calls to imported functions and calls to Wasm module internal functions.The big advantage here is that usually calls to Wasm module internal functions are more common and at the same time more efficient. By introducing a new
wasmi
bytecode to represent Wasm module internal function calls we can get rid of several checks during execution time.For this we will require the following
wasmi
bytecode instructions:CallImported
: Very similar to theCall
instruction today but can only call imported host or Wasm functions.CallInternal
: Can only call functions internal to the Wasm module.CallIndirect
: No changes since indirect calls cannot be optimized by this technique.ReturnCallImported
: Same asCallImported
but as tail call.ReturnCallInternal
: Same asCallInternal
but as tail call.ReturnCallIndirect
: No changes since indirect calls cannot be optimized by this technique.The text was updated successfully, but these errors were encountered: