-
Notifications
You must be signed in to change notification settings - Fork 824
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
Low real-time performance with simple test #4738
Comments
Thanks for opening the issue @daichifukui, we'll investigate the timings and assess how we can speedup things further. As you mention, there seems to be ample room for improvement. We'll post here the results as we make progress on it |
A WasiEnv now has a flag that signifies if it's allowed to block the current thread and the flag is expected to be referenced when the current thread can be blocked for optimising the performance. In addition, the flag is set true when wasm modules are invoked via the CLI. wasmer-wasix uses a tokio runtime for many things according to wasmerio#4299, but tokio does not always bring the best performance in Wasmer as described in wasmerio#4738, hence this update. Signed-off-by: Daichi Fukui <[email protected]>
Allow different sleep form of poll_oneoff, which just sleeps for relative time using std::thread::sleep. That form of poll_oneoff is only available if there is only one subscription and it is allowed to block the current thread, contributing to more consistent sleep times. This update would help improve the real-time performance of wasmer. Closes: wasmerio#4738 Signed-off-by: Daichi Fukui <[email protected]>
Hi @syrusakbary
Thanks for the quick and prompt reply. I've created #4739 for this issue. |
Overview
We are experiencing low real-time performance with simple test using the latest version of the Wasmer runtime.
Conditions
Steps to reproduce
Time elapsed should be as close to 1 second as possible since the duration is set 1000 milliseconds.
However, the actual time elapsed is longer than that and sometimes takes more than 2-millisecond-long latency.
Expected behaviour
The latency is expected to vary in microseconds.
In other words, the latency should be constantly less than 1 millisecond.
Actual behaviour
The latency sometimes takes more than 2 millisecond.
In addition, the latency varies from less than 1 milli second to more than 2 milliseconds, showing non-consistent result.
Additional context
In the background, we have a plan to use Wasmer on top of a industrial controller system.
We believe that using a WASM runtime would make applications for such a controller system more portable and scalable.
This is because WASM uses a CPU-agnostic binary format and consumes less computing resource than a container runtime.
As timing is critical in controller systems, we would like to have better real-time performance with WASM runtimes.
Wasmer supports WASIX, which allows us to use some POSIX interfaces for WASM, so we will be able to build a legacy application using POSIX for WASM with lower cost.
From a different point of view, WAMR is designed as a lightweight standalone WASM runtime and can be used for a controller system, but it primarily implements an interpreter, so this could potentially lead to slower execution times compared to a JIT compiler like Wasmer.
The text was updated successfully, but these errors were encountered: