Stream: git-wasmtime

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

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.

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.

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.

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.

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.

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: Nov 22 2024 at 16:03 UTC