[not-matthias]

TLDR: Runtimes make decisions from elapsed time: benchmark harnesses pick iteration and warmup counts, GCs and schedulers use time-based heuristics, and time-bounded loops run until a deadline. Under Callgrind the host clock runs 20 to 100 times faster relative to the program than natively, and varies between runs, so all of these become instruction-count noise. --deterministic-time=yes derives every clock the client can read from the number of guest instructions executed, so the same instruction stream always observes the same time (Linux only; --deterministic-rng already lists this as a limitation).

Model

• 1 ns per executed guest instruction: a 1 GHz CPU retiring one instruction per cycle. Valgrind's own work (translation, syscall wrappers, tool instrumentation) does not advance the clock.
• CLOCK_REALTIME is a fixed epoch (2024-01-01T00:00:00Z) plus the virtual time; the monotonic, boottime and CPU-time clocks are the virtual time.

Core

• m_vclock.c holds the counter and a VEX instrument2 pass that counts IMarks and adds them to VG_(vclock_ns) before every conditional exit and at the end of each superblock, so every path adds exactly the instructions it executed. It runs after the tool's pass, so tool costs are unchanged and tools never see the counter accesses. Cost is three IR statements per SB exit.
• The pass is composed with the existing SP-update pass in vg_core_instrument_pass.

Syswrap

• clock_gettime, gettimeofday and time are completed in PRE from the virtual clock. Dynamic and unknown clock ids still reach the kernel.
• nanosleep and clock_nanosleep move the clock forward by the requested duration (or up to the absolute deadline) and return at once; EINVAL/EFAULT checks match the kernel. A completed sleep sets SfYieldAfter so other threads still get to run.

VEX

• New LibVEX_SetVirtualTSC(ticks, hz) hook, mirroring LibVEX_SetRandom32. RDTSC/RDTSCP (amd64) and CNTVCT_EL0 (arm64) return the virtual time in ns; CNTFRQ_EL0 reports 1 GHz; RDTSCP reports TSC_AUX as 0.

Review notes

• Not covered on purpose (documented in CODSPEED-CHANGELOG.md): timeouts on blocking calls (futex, poll, epoll_wait), interval timers, getrusage/times, and CPUID's TSC frequency. Doing timeouts right needs a discrete-event scheduler; I left it out until a workload needs it.
• The clock is global. Thread interleaving is still host-driven, so multithreaded programs can still observe different times.
• Regtest callgrind/tests/deterministic_time checks properties that hold on every host (epoch, clocks agree, sleeps skip ahead, TSC tracks the clock, identical work takes identical time, kernel errors preserved). The full callgrind suite passes with VALGRIND_OPTS=--deterministic-time=yes with the same pre-existing failures as without.
• Variance tests (zero Ir variance across runs under the flag, non-zero without) are in valgrind-helpers: AvalancheHQ/valgrind-helpers#6 (stacked on AvalancheHQ/valgrind-helpers#3).

Smoke (5 ms monotonic budget loop, then rdtsc delta, three runs each):

host time:          iterations=7880   ticks=29771478   secs=1793787211
                    iterations=9958   ticks=28456395   secs=1793787211
                    iterations=13037  ticks=27578133   secs=1793787211
deterministic time: iterations=192307 ticks=7002395    secs=1704067200  (x3, identical)

[codspeed]

Merging this PR will improve performance by 11.01%

⚡ 1 improved benchmark
✅ 83 untouched benchmarks
⏩ 60 skipped benchmarks¹

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
⚡	test_valgrind[valgrind.codspeed, stress-ng --cpu 1 --cpu-ops 10, full-with-inline]	7.5 s	6.8 s	+11.01%

Tip

Curious why performance improved? Comment @codspeedbot explain why performance improved on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing deterministic-time (8e8a952) with master (d034e80)}

Footnotes

1. 60 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩