Skip to content
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

Closed
daichifukui opened this issue May 23, 2024 · 2 comments · Fixed by #4739
Closed

Low real-time performance with simple test #4738

daichifukui opened this issue May 23, 2024 · 2 comments · Fixed by #4739

Comments

@daichifukui
Copy link
Contributor

Overview
We are experiencing low real-time performance with simple test using the latest version of the Wasmer runtime.

Conditions

$ wasmer -vV
wasmer 4.3.0 (320a38a 2024-05-22)
binary: wasmer-cli
commit-hash: 320a38a92c155e4e5a58133101c5d74b093cee58
commit-date: 2024-05-22
host: x86_64-unknown-linux-gnu
compiler: singlepass,cranelift

$ rustc -vV
rustc 1.74.1 (a28077b28 2023-12-04)
binary: rustc
commit-hash: a28077b28a02b92985b3a3faecf92813155f1ea1
commit-date: 2023-12-04
host: x86_64-unknown-linux-gnu
release: 1.74.1
LLVM version: 17.0.4

$ cargo wasi --version
cargo-wasi 0.1.28 (e811d4889b 2023-06-12)

Steps to reproduce

$ cat src/main.rs
use std::{thread, time};
use std::time::{Instant};

fn main() {
    let duration = time::Duration::from_millis(1*1000);

    for _ in 0u32.. 10 {
        let start = Instant::now();
        thread::sleep(duration);
        let elapsed_time = start.elapsed();
        println!("Time elapsed is: {:?}", elapsed_time);
    }
}

$ cargo wasi build --release

$ wasmer run target/wasm32-wasi/release/rust_sleep.wasm
Time elapsed is: 1.002046917s
Time elapsed is: 1.001874295s
Time elapsed is: 1.002168553s
Time elapsed is: 1.001467564s
Time elapsed is: 1.002140849s
Time elapsed is: 1.002196984s
Time elapsed is: 1.000833738s
Time elapsed is: 1.00150038s
Time elapsed is: 1.001016372s
Time elapsed is: 1.001904711s

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.

$ wasmer run target/wasm32-wasi/release/rust_sleep.wasm
Time elapsed is: 1.002046917s
Time elapsed is: 1.001874295s
Time elapsed is: 1.002168553s
Time elapsed is: 1.001467564s
Time elapsed is: 1.002140849s
Time elapsed is: 1.002196984s
Time elapsed is: 1.000833738s
Time elapsed is: 1.00150038s
Time elapsed is: 1.001016372s
Time elapsed is: 1.001904711s

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.

@syrusakbary
Copy link
Member

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

daichifukui added a commit to daichifukui/wasmer that referenced this issue May 23, 2024
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]>
daichifukui added a commit to daichifukui/wasmer that referenced this issue May 23, 2024
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]>
@daichifukui
Copy link
Contributor Author

daichifukui commented May 23, 2024

Hi @syrusakbary

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

Thanks for the quick and prompt reply.

I've created #4739 for this issue.
Hopefully the maintainers will review the changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants