Low real-time performance with simple test

[daichifukui]

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]

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]

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.