|
Revision tags: dev, v36.0.9, v44.0.1, v43.0.2, v36.0.8, v24.0.8, v44.0.0, v43.0.1, v42.0.2, v36.0.7, v24.0.7, v43.0.0, v42.0.1, v41.0.4, v42.0.0, v40.0.4, v36.0.6, v24.0.6, v41.0.3, v41.0.2, v41.0.1, v36.0.5, v40.0.3, v41.0.0, v36.0.4, v39.0.2, v40.0.2, v40.0.1, v40.0.0, v39.0.1, v39.0.0, v38.0.4, v37.0.3, v36.0.3, v24.0.5, v38.0.3, v38.0.2, v38.0.1, v37.0.2, v37.0.1, v37.0.0, v36.0.2, v36.0.1, v36.0.0, v35.0.0, v24.0.4, v33.0.2, v34.0.2, v34.0.1, v33.0.1, v24.0.3, v32.0.1, v34.0.0, v33.0.0, v32.0.0, v31.0.0, v30.0.2, v30.0.1, v30.0.0, v29.0.1, v29.0.0 |
|
| #
1d1c06f3 |
| 16-Jan-2025 |
Alex Crichton <[email protected]> |
Add basic support for profiling Pulley (#10034)
* Add basic support for profiling Pulley
This commit adds basic support for profiling the Pulley interpreter. This is partially achievable previously
Add basic support for profiling Pulley (#10034)
* Add basic support for profiling Pulley
This commit adds basic support for profiling the Pulley interpreter. This is partially achievable previously through the use of native profilers, but the downside of that approach is that you can find hot instructions but it's not clear in what context the hot instructions are being executed nor what functions are hot. The goal of this profiler is to show pulley bytecode and time spent in bytecode itself to better understand the shape of code around a hot instruction to identify new macro opcodes for example.
The general structure of this new profiler is:
* There is a compile-time feature for Pulley which is off-by-default where, when enabled, Pulley will record its current program counter into an `AtomicUsize` before each instruction.
* When the CLI has `--profile pulley` Wasmtime will spawn a sampling thread in the same process which will periodically read from this `AtomicUsize` to record where the program is currently executing.
* The Pulley profiler additionally records all bytecode through the use of the `ProfilingAgent` trait to ensure that the recording has access to all bytecode as well.
* Samples are taken throughout the process and emitted to a `pulley-$pid.data` file. This file is then interpreted and printed by an "example" program `profiler-html.rs` in the `pulley/examples` directory.
The end result is that hot functions of Pulley bytecode can be seen and instructions are annotated with how frequently they were executed. This enables finding hot loops and understanding more about the whole loop, bytecodes that were selected, and such.
* Add missing source file
* Check the profile-pulley feature in CI
* Miscellaneous fixes for CI
* Fix type-checking of `become` on nightly Rust
* Fix more misc CI issues
* Fix dispatch in tail loop
* Update test expectations
* Review comments
* Fix a feature combo
show more ...
|
|
Revision tags: v28.0.1, v28.0.0 |
|
| #
c2fa8171 |
| 11-Dec-2024 |
Alex Crichton <[email protected]> |
pulley: Add simple debugging support (#9796)
This commit adds a `debug.rs` to Pulley to print out the instruction being executed and the state of all registers between instructions. This is turned o
pulley: Add simple debugging support (#9796)
This commit adds a `debug.rs` to Pulley to print out the instruction being executed and the state of all registers between instructions. This is turned off by default and does not have a runtime or environment-based configuration value. Instead changing this requires changing source code for now. This enables the interpreter loop to unconditionally use this "debugger" where it'll compile away to nothing in release/benchmarking situations.
This commit additionally adds this support to the `tail_loop` module and fixes a few issues there such as it accidentally not being tested in CI as well as a new `#[cfg]` to use it on stable rust with normal `return` under the assumption that LLVM is highly likely to do TCO.
show more ...
|