Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/dunnock/wabench
Yeat another WASM benchmark (WASI) - http://wabench.com:8080
https://github.com/dunnock/wabench
npm rollup stdweb typescript wasi wasm-pack webpack yew
Last synced: 15 days ago
JSON representation
Yeat another WASM benchmark (WASI) - http://wabench.com:8080
- Host: GitHub
- URL: https://github.com/dunnock/wabench
- Owner: dunnock
- Created: 2019-10-09T21:00:11.000Z (about 5 years ago)
- Default Branch: master
- Last Pushed: 2023-01-07T11:25:34.000Z (almost 2 years ago)
- Last Synced: 2024-10-04T16:56:48.147Z (about 1 month ago)
- Topics: npm, rollup, stdweb, typescript, wasi, wasm-pack, webpack, yew
- Language: Rust
- Homepage:
- Size: 5.68 MB
- Stars: 10
- Watchers: 3
- Forks: 0
- Open Issues: 22
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# Yet another WASM benchmark (including WASI)
## Goal
WASM benchmark which allows to compare CPU intensive code execution on native vs browser WASI vs browser WASM (stdweb), comparing WASM execution in different environments.
## Problem statements
There are many WebAssembly performance results published, though most of those performed on a limited set of devices and/or browsers. Secondary, many benchmarks actually include data initialization time and time taken by context outside of actual benchmarked code. In this project we will focus on measuring pure WebAssembly code execution timings, not including context and data initialization.
## Running locally
Project's workspace structure:
- tests sources and implementations located under `./src`
- main native runner is `./src/main.rs`
- web runner and browser app [./crates/web](https://github.com/dunnock/wabench/tree/master/crates/web)
To run all benchmarks in native target
```
cargo run --release
```
To run all benchmarks in browser see [./crates/web](https://github.com/dunnock/wabench/tree/master/crates/web)
## Trial and error notes
Unoptimized dev build for all targets seems working 10+ times slower, so I focused on release timings.
Building for wasm32-wasi target appeared to be fastest way to go, allowed to run benchmarks from console via `wasmer` and `wavm` and browser using `@wasmer/wasi`. Those benchmarks displayed timings sometimes better than running optimized release build (probably due to memory reallocation in native version).
Using wasm-pack via webpack to compile web application appeared to be the most complicated setup, code resides under `examples/wasm_bindgen` directory. Also I did not manage to setup service worker, since yew workers are natively built with cargo web, hence tests are blocking web page with this setup. Timing appeared 2 times slower than of WASI. This approach seems gives most control of JavaScript application setup.
Using stdweb stack to compile web application appeared to be the quite simple, with `Public` worker in separate thread as well as `Context` initial run time appeared to be 2 times slower than wasm32-wasi, same as wasm-bindgen.
Setting up WASI service worker appered to be the most challenging, primarily from the point of providing communication of binary data between worker and web page:
- polling API is not quite ready yet, thread:sleep is not implemented on some VMs and does not actually return control to JS engine, file polling is not implemented in JS at the moment. Hence implementing event loop is not feasible
- I did not figure out how to pass arrays as function parameters
Most feasible option appeared to be establishing communication via filesystem (thanks to @wasmer/wasmFm and @wasmer/terminal for beautiful idea)
Safari and wasmer/wasi polyfill does not play well together.
## Plan
- [X] Local tests execution
- [X] Compile and run as WASI
- [X] Huge ndarray sum test
- [ ] Fibonacci
- [X] Webapp in subdir web
- [X] Add WASI worker setup for yew to speed up
- [X] Fix bug of running second test: BufferedStdin read on position not supported: 21
- [ ] Setup build.rs: split crates for stdweb and wasi workers, app, deployment/styles
- [X] Fix Safari Instant clock value issue
- [ ] Embed let's encrypt for wabench container
- [ ] Publish results somewhere...?
- [ ] Use [criterion](https://docs.rs/criterion/0.3.0/criterion/) for benchmarking
## Acknowledgements
- cranestation and wasmtime - leading standard and implementation, wasmtime wider wasm support
- wasmer.io - easy to use and quite fast wasm runtime
- wavm - it seems fastest wasm runtime
- yew - elegant web framework, it was easy to build web app (except wasm-pack setup part)