Stream: git-wasmtime

Topic: wasmtime / Issue #2737 CoreMark 1.0 WASI build freezes

view this post on Zulip Wasmtime GitHub notifications bot (Mar 18 2021 at 15:24):

vshymanskyy opened Issue #2737:

Test Case

coremark.wasm.zip

Steps to Reproduce

curl https://wasmtime.dev/install.sh -sSf | bash
# wasmtime 0.25.0
wasmtime run coremark.wasm
# (freezes)

Expected Results

$wasmer coremark.wasm
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 333589297
Total time (secs): 17.513458
Iterations/Sec   : 6280.883934
Iterations       : 110000
Compiler version : Clang 11.0.0 (https://github.com/llvm/llvm-project 176249bd6732a8044d457092ed932768724a6f06)
Compiler flags   : -O3
Memory location  : STATIC
seedcrc          : 0xe9f5
[0]crclist       : 0xe714
[0]crcmatrix     : 0x1fd7
[0]crcstate      : 0x8e3a
[0]crcfinal      : 0x33ff
Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 6280.883934 / Clang 11.0.0 (https://github.com/llvm/llvm-project 176249bd6732a8044d457092ed932768724a6f06) -O3    / STATIC

Actual Results

Wasmtime freezes

Versions and Environment

Wasmtime version or commit: 0.25.0

Operating system: Ubuntu 20.04

Architecture: x86_64

view this post on Zulip Wasmtime GitHub notifications bot (Mar 18 2021 at 15:24):

vshymanskyy labeled Issue #2737:

Test Case

coremark.wasm.zip

Steps to Reproduce

curl https://wasmtime.dev/install.sh -sSf | bash
# wasmtime 0.25.0
wasmtime run coremark.wasm
# (freezes)

Expected Results

$wasmer coremark.wasm
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 333589297
Total time (secs): 17.513458
Iterations/Sec   : 6280.883934
Iterations       : 110000
Compiler version : Clang 11.0.0 (https://github.com/llvm/llvm-project 176249bd6732a8044d457092ed932768724a6f06)
Compiler flags   : -O3
Memory location  : STATIC
seedcrc          : 0xe9f5
[0]crclist       : 0xe714
[0]crcmatrix     : 0x1fd7
[0]crcstate      : 0x8e3a
[0]crcfinal      : 0x33ff
Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 6280.883934 / Clang 11.0.0 (https://github.com/llvm/llvm-project 176249bd6732a8044d457092ed932768724a6f06) -O3    / STATIC

Actual Results

Wasmtime freezes

Versions and Environment

Wasmtime version or commit: 0.25.0

Operating system: Ubuntu 20.04

Architecture: x86_64

view this post on Zulip Wasmtime GitHub notifications bot (Mar 18 2021 at 15:49):

alexcrichton commented on Issue #2737:

Thanks for the report! I believe the freezing behavior is due to the wasm file itself rather than wasmtime. Using RUST_LOG=trace I can see that a number of calls to wasi are being made, notably:

 TRACE tracing::span                                             > -- wiggle abi
 TRACE wasi_common::snapshots::preview_1::wasi_snapshot_preview1 > wiggle abi; module="wasi_snapshot_preview1" function="clock_time_get"
 TRACE tracing::span::active                                     > -> wiggle abi
 TRACE wasi_common::snapshots::preview_1::wasi_snapshot_preview1 > id=ProcessCputimeId precision=0
 TRACE wasi_common::snapshots::preview_1::wasi_snapshot_preview1 > result=Err(process and thread clocks are not supported

Caused by:
    Badf: Bad file descriptor)
 DEBUG wasi_common::snapshots::preview_1                         > Error: process and thread clocks are not supported

Caused by:
    Badf: Bad file descriptor
 TRACE tracing::span::active                                     > <- wiggle abi

It looks like the module is calling the clock_res_get API with the ProcessCputimeId clock id is not supported right now. In that sense I don't think that the wasm module is handling the error reported by wasmtime.

There's also the separate issue, however, of the need to implement this part of the WASI API as well.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 18 2021 at 15:56):

sunfishcode commented on Issue #2737:

For background, ProcessCputimeId has been removed from WASI ephemeral, as many implementations don't have a one-to-one relationship between processes and instances.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 18 2021 at 16:05):

vshymanskyy commented on Issue #2737:

It's an ordinary C app, compiled using wasi-sdk 12.0 and clang 11.0.0, and is targeting wasi_snapshot_preview1.
Do you suggest this is wasi-sdk issue?

view this post on Zulip Wasmtime GitHub notifications bot (Mar 18 2021 at 16:14):

pchickey commented on Issue #2737:

wasi-sdk's libc (WebAssembly/wasi-libc) is faithfully translating the application's desire to measure process cpu time to the WASI layer, but WASI cannot support that measurement. So, even if the libc could proactively return the same error that wasmtime is providing here, the application needs to change to not need this sort of measurement.

If you are trying to measure performance of Wasmtime or WebAssembly code in general, @fitzgen and others have been doing related work, some starting points to look at are https://github.com/bytecodealliance/rfcs/pull/4 and https://github.com/bytecodealliance/sightglass

view this post on Zulip Wasmtime GitHub notifications bot (Mar 18 2021 at 18:15):

sunfishcode commented on Issue #2737:

It's a good point that wasi-libc's clock, times, and getrusage implicitly make use of the process and thread clocks. I'll think about whether there's something better we can do for these.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 22 2021 at 16:46):

sunfishcode commented on Issue #2737:

I've now submitted https://github.com/WebAssembly/wasi-libc/pull/241 to propose a way to fix WASI libc to avoid using the PROCES_CPUTIME clock implicitly.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 25 2021 at 21:18):

alexcrichton commented on Issue #2737:

I'm going to close this since I think the behavior is correct today (returning an error it's not implemented), it's probably going to be correct into tomorrow (this is removed from the next version of wasi), and the upstream wasi-libc has now been fixed to avoid using these clocks.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 25 2021 at 21:18):

alexcrichton closed Issue #2737:

Test Case

coremark.wasm.zip

Steps to Reproduce

curl https://wasmtime.dev/install.sh -sSf | bash
# wasmtime 0.25.0
wasmtime run coremark.wasm
# (freezes)

Expected Results

$wasmer coremark.wasm
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 333589297
Total time (secs): 17.513458
Iterations/Sec   : 6280.883934
Iterations       : 110000
Compiler version : Clang 11.0.0 (https://github.com/llvm/llvm-project 176249bd6732a8044d457092ed932768724a6f06)
Compiler flags   : -O3
Memory location  : STATIC
seedcrc          : 0xe9f5
[0]crclist       : 0xe714
[0]crcmatrix     : 0x1fd7
[0]crcstate      : 0x8e3a
[0]crcfinal      : 0x33ff
Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 6280.883934 / Clang 11.0.0 (https://github.com/llvm/llvm-project 176249bd6732a8044d457092ed932768724a6f06) -O3    / STATIC

Actual Results

Wasmtime freezes

Versions and Environment

Wasmtime version or commit: 0.25.0

Operating system: Ubuntu 20.04

Architecture: x86_64

view this post on Zulip Wasmtime GitHub notifications bot (Mar 25 2021 at 21:47):

vshymanskyy commented on Issue #2737:

I agree.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 25 2021 at 21:47):

vshymanskyy edited a comment on Issue #2737:

I agree. Thanks everyone!

Last updated: Dec 23 2024 at 12:05 UTC