Closed hungryzzz closed 4 months ago
There's indeed something very wrong here. We need to look into this. @ptitSeb this might be the reasoning behind the JavascriptCore difference?
@hungryzzz I build a wasm version from the source using zig to target wasi (binary attached)
I use a simple time
command and I do see a difference when I compare wasmtime 8.0 vs current wasmer version using Cranelift compiler. I will check to see if it's a missing optimisation that provoque that (or maybe add optimisation option to the cli).
flops.zip
So, I have done some more analysis and comparison. Wasmer for now use Cranelift codegen v0.91.1, wich is the version you can find in Wasmtime v4.0.1, while Wasmtime v8.0 use Cranelift v0.95 If I use Wasmtime v4.0.1, I see similar result between Wasmer and Wasmtime (can you confirm this on your side?) So it's just that newer Cranelift have improved it's efficiancy. We will update Cranelift version, but not sure when.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Feel free to reopen the issue if it has been closed by mistake.
Summary
Hi, I run the attached case in different Wasm runtimes(after being compiled by
Emscripten
), and I also find some performance differences betweenwasmer
and other 3 runtimes: the execution time(collected by perf-tool, probe begins when starting to execute the wasm code(inner_module_run
inwasmer
) and end insched:sched_process_exit
) inwasmer
is 3.5x slower than which inwasmtime
.Hardware & OS
Emscripten
Wasm runtime version
Additional details
I find that both
wasmer
andwasmtime
use the cranelift as default compiler. I guess maybe it's related to the different version of cranelift. And then I try to use LLVM as the compiler (wasmer run --llvm
), I get the execution time423130.01us
, which show more relation to the current cranelift in wasmer. So is it convenient to upgrade the version of current cranelift? Or how can I do it?flops-4.txt