Stream: git-wasmtime

Topic: wasmtime / issue #3414 Poor performance compiling deeply ...


view this post on Zulip Wasmtime GitHub notifications bot (Oct 04 2021 at 18:53):

alexcrichton opened issue #3414:

This was found recently via a fuzz-generated test case, but it appears that Wasmtime has relatively poor performance compiling functions that have deeply nested blocks with little actual branching in them.

This wasm file: bar.wasm.gz currently takes ~10ms to compile:

$ time ./target/release/wasmtime compile --disable-cache ./bar.wasm
./target/release/wasmtime compile --disable-cache ./bar.wasm  0.02s user 0.02s system 254% cpu 0.016 total

Execution with fuzzing is 20-30x slower than normal execution, and the original file that this came from had ~100 copies of this function. Fuzzing also disables parallel compilation, which means that it's a 2000-3000x slowdown from the measurement here, which accounts for the roughly 30s the original module takes to compile with fuzzing enabled, leading to the timeout.

This is probably a case that will be helped by the new register allocator (eventually), but I suspect there's a lot of low-hanging fruit for improving this codegen as well.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 04 2021 at 18:53):

alexcrichton labeled issue #3414:

This was found recently via a fuzz-generated test case, but it appears that Wasmtime has relatively poor performance compiling functions that have deeply nested blocks with little actual branching in them.

This wasm file: bar.wasm.gz currently takes ~10ms to compile:

$ time ./target/release/wasmtime compile --disable-cache ./bar.wasm
./target/release/wasmtime compile --disable-cache ./bar.wasm  0.02s user 0.02s system 254% cpu 0.016 total

Execution with fuzzing is 20-30x slower than normal execution, and the original file that this came from had ~100 copies of this function. Fuzzing also disables parallel compilation, which means that it's a 2000-3000x slowdown from the measurement here, which accounts for the roughly 30s the original module takes to compile with fuzzing enabled, leading to the timeout.

This is probably a case that will be helped by the new register allocator (eventually), but I suspect there's a lot of low-hanging fruit for improving this codegen as well.

view this post on Zulip Wasmtime GitHub notifications bot (Nov 12 2021 at 04:07):

jlb6740 labeled issue #3414:

This was found recently via a fuzz-generated test case, but it appears that Wasmtime has relatively poor performance compiling functions that have deeply nested blocks with little actual branching in them.

This wasm file: bar.wasm.gz currently takes ~10ms to compile:

$ time ./target/release/wasmtime compile --disable-cache ./bar.wasm
./target/release/wasmtime compile --disable-cache ./bar.wasm  0.02s user 0.02s system 254% cpu 0.016 total

Execution with fuzzing is 20-30x slower than normal execution, and the original file that this came from had ~100 copies of this function. Fuzzing also disables parallel compilation, which means that it's a 2000-3000x slowdown from the measurement here, which accounts for the roughly 30s the original module takes to compile with fuzzing enabled, leading to the timeout.

This is probably a case that will be helped by the new register allocator (eventually), but I suspect there's a lot of low-hanging fruit for improving this codegen as well.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 31 2022 at 17:01):

alexcrichton labeled issue #3414:

This was found recently via a fuzz-generated test case, but it appears that Wasmtime has relatively poor performance compiling functions that have deeply nested blocks with little actual branching in them.

This wasm file: bar.wasm.gz currently takes ~10ms to compile:

$ time ./target/release/wasmtime compile --disable-cache ./bar.wasm
./target/release/wasmtime compile --disable-cache ./bar.wasm  0.02s user 0.02s system 254% cpu 0.016 total

Execution with fuzzing is 20-30x slower than normal execution, and the original file that this came from had ~100 copies of this function. Fuzzing also disables parallel compilation, which means that it's a 2000-3000x slowdown from the measurement here, which accounts for the roughly 30s the original module takes to compile with fuzzing enabled, leading to the timeout.

This is probably a case that will be helped by the new register allocator (eventually), but I suspect there's a lot of low-hanging fruit for improving this codegen as well.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 26 2022 at 15:00):

alexcrichton commented on issue #3414:

I'm going to close this given the discussion on https://github.com/bytecodealliance/wasmtime/issues/4060, these sorts of outliers are expected and eventually we'll want to tweak fuzzers to not generate these patterns of code.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 26 2022 at 15:00):

alexcrichton closed issue #3414:

This was found recently via a fuzz-generated test case, but it appears that Wasmtime has relatively poor performance compiling functions that have deeply nested blocks with little actual branching in them.

This wasm file: bar.wasm.gz currently takes ~10ms to compile:

$ time ./target/release/wasmtime compile --disable-cache ./bar.wasm
./target/release/wasmtime compile --disable-cache ./bar.wasm  0.02s user 0.02s system 254% cpu 0.016 total

Execution with fuzzing is 20-30x slower than normal execution, and the original file that this came from had ~100 copies of this function. Fuzzing also disables parallel compilation, which means that it's a 2000-3000x slowdown from the measurement here, which accounts for the roughly 30s the original module takes to compile with fuzzing enabled, leading to the timeout.

This is probably a case that will be helped by the new register allocator (eventually), but I suspect there's a lot of low-hanging fruit for improving this codegen as well.


Last updated: Dec 23 2024 at 13:07 UTC