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
As mentioned in the issue #37, a recent addition to Wasmtime makes it possible to share host functions between all instances without adding them over and over again to each instance linker. This should greatly reduce instance creation time.
To be able to use this, we first need to figure out how to bind state/context to each instance. Currently we capture the state in a closure and add this closure as a host function for the instance. If we are going to have only global host functions, we need to do some work to fetch the state during each invocation of the host function.
As the RFC explains, we will need to switch to using the Store::set and Store::get methods together with the Caller structure to get the store for each instance, like Wasmtime's WASI implementation. Generally, this is a good approach as we always maintain one Store per instance in Lunatic, but a big obstacle for us here is the way that the uptown_funk macro works.
Store::set/get allows us to only set one context per Store/Instance. With uptown_funk we allow you to define different states belonging to a group of function. This means that we need to put all the individual states inside a common structure and during the macro generation assign unique IDs to each state structure, so that the functions can fetch the specific state belonging to them.
I misunderstood this API at first. Store::set/get works on a per type basis and should be a great fit for uptown_funk.
At this point I'm not sure what the performance implications are if we need to each time look up a state in something like a hash map for host functions that use state. I will run a few benchmarks to see if the cost of doing this is too hight.
Ideally, on each macro invocation we would assign an incremented id and be able to generate a tuple containing the state to minimise lookup speed. But as Rust macros can't keep state between invocation, this is currently not possible.
The text was updated successfully, but these errors were encountered:
As mentioned in the issue #37, a recent addition to Wasmtime makes it possible to share host functions between all instances without adding them over and over again to each instance linker. This should greatly reduce instance creation time.
To be able to use this, we first need to figure out how to bind state/context to each instance. Currently we capture the state in a closure and add this closure as a host function for the instance. If we are going to have only global host functions, we need to do some work to fetch the state during each invocation of the host function.
As the RFC explains, we will need to switch to using the
Store::set
andStore::get
methods together with the Caller structure to get the store for each instance, like Wasmtime's WASI implementation. Generally, this is a good approach as we always maintain one Store per instance in Lunatic, but a big obstacle for us here is the way that theuptown_funk
macro works.Store::set/get
allows us to only set one context per Store/Instance. Withuptown_funk
we allow you to define different states belonging to a group of function. This means that we need to put all the individual states inside a common structure and during the macro generation assign unique IDs to each state structure, so that the functions can fetch the specific state belonging to them.At this point I'm not sure what the performance implications are if we need to each time look up a state in something like a hash map for host functions that use state. I will run a few benchmarks to see if the cost of doing this is too hight.
Ideally, on each macro invocation we would assign an incremented id and be able to generate a tuple containing the state to minimise lookup speed. But as Rust macros can't keep state between invocation, this is currently not possible.
The text was updated successfully, but these errors were encountered: