Always record only one iteration per process

.github/workflows/benchmarks.yml

@@ -76,8 +76,7 @@ jobs:
         cargo run benchmark \
         --engine=artifacts/wasmtime-main/libengine.so \
         --engine-flags "-Wgc -Wfunction-references -Wexceptions" \
-        --processes=4 \
-        --iterations-per-process=1 \
+        --iters=4 \
         -- "${PARTITION_SUITE}"
 
   check:

.github/workflows/sightglass.yml

@@ -11,8 +11,6 @@ env:
   CARGO_TERM_COLOR: always
   RUST_LOG: info
 
-  REVISION: "v49.0.2"
-
 jobs:
   format-and-clippy:
     runs-on: ubuntu-latest
@@ -30,6 +28,9 @@ jobs:
     strategy:
       matrix:
         os: [ubuntu-latest, macos-latest, windows-latest]
+    env:
+      # Wasmtime commit to build for testing.
+      REVISION: "239274b0b5e96755a3d3009b7b3659b3b0f6f8cb"
     steps:
     - uses: actions/checkout@v4
     - run: rustup update
@@ -45,8 +46,6 @@ jobs:
     - name: Build Wasmtime engine
       if: steps.wasmtime-cache.outputs.cache-hit != 'true'
       working-directory: ./engines/wasmtime
-      env:
-        REVISION: ${{ env.REVISION }}
       run: |
            rustc build.rs
            ./build

Cargo.toml

@@ -34,7 +34,6 @@ exclude = [
     "benchmarks/shootout-xblabla20",
     "benchmarks/shootout-xchacha20",
     "benchmarks/tract-onnx-image-classification",
-    "engines/native/libengine",
 ]
 
 # Always build Wasmtime and Cranelift in release mode to avoid slow Wasm

README.md

@@ -95,8 +95,8 @@ You can always see all subcommands and options via
 cargo run -- help
 ```
 
-There are flags to control how many different processes we spawn and take
-measurements from, how many iterations we perform for each process, etc...
+There are flags to control how many iterations of each benchmark we measure
+(each in its own process), etc...
 
 That said, here are a couple of typical usage scenarios.
 

benchmarks/README.md

@@ -180,28 +180,3 @@ whose bodies are empty on Wasm cannot be scaled up.
 
 `noop` executes 0 instructions by design and is intended for measuring harness
 overhead.
-
-## Compatibility Requirements for Native Execution
-
-Sightglass can also measure the performance of a subset of benchmarks compiled
-to native code (i.e., not WebAssembly). To compile these benchmarks without
-changing their source code, this involves a delicate interface with the [native
-engine] with some additional requirements beyond the [Minimal Technical
-Requirements] noted above:
-
-[native engine]: ../engines/native
-[Minimal Technical Requirements]: #minimal-technical-requirements
-
-* Generate an ELF shared library linked to the [native engine] shared library to
-  provide definitions for `bench_start` and `bench_end`.
-
-* Rename the `main` function to `native_entry`. For C- and C++-based source this
-  can be done with a simple define directive passed to `cc` (e.g.,
-  `-Dmain=native_entry`).
-
-* Provide reproducible builds via a `Dockerfile.native` file (see
-  [`build-native.sh`](./build-native.sh)).
-
-Note that support for native execution is optional: adding a WebAssembly
-benchmark does not imply the need to support its native equivalent — CI
-will not fail if it is not included.