Currently, the Metrics struct and the Runner implementation only capture wall-clock time (using std.time.Timer).
While this is sufficient for simple, single-threaded CPU-bound tasks, it lacks precision for more complex scenarios. Standard benchmarking tools (like Google Benchmark) provide both Time (real world elapsed time) and CPU (time the processor actually spent working) to help developers identify if a benchmark is CPU-bound or waiting on system resources.
It would be great to update the measurement loop to capture both metrics simultaneously.
We should do the following:
- Update
Metrics to include a field for mean_cpu_ns.
- Implement a
CpuTimer helper (likely using CLOCK_PROCESS_CPUTIME_ID on Linux) to track process time.
- Update
Runner.zig to record both timers during the sample loop.
// Proposed Metrics update
pub const Metrics = struct {
name: []const u8,
mean_ns: f64, // Wall Time
mean_cpu_ns: f64, // CPU Time (New)
// ...
};
// Proposed Usage in Runner
var wall_timer = try Timer.start();
var cpu_timer = try CpuTimer.start(); // Helper wrapper around clock_gettime
for (0..batch_size) |_| {
try execute(function, args);
}
const wall_ns = wall_timer.read();
const cpu_ns = cpu_timer.read();
Currently, the
Metricsstruct and theRunnerimplementation only capture wall-clock time (usingstd.time.Timer).While this is sufficient for simple, single-threaded CPU-bound tasks, it lacks precision for more complex scenarios. Standard benchmarking tools (like Google Benchmark) provide both Time (real world elapsed time) and CPU (time the processor actually spent working) to help developers identify if a benchmark is CPU-bound or waiting on system resources.
It would be great to update the measurement loop to capture both metrics simultaneously.
We should do the following:
Metricsto include a field formean_cpu_ns.CpuTimerhelper (likely usingCLOCK_PROCESS_CPUTIME_IDon Linux) to track process time.Runner.zigto record both timers during the sample loop.