This uses sched_getcpu(2) to find the CPU we are scheduled on and then
cpufreq(4) to find the frequency of that CPU. The caller is responsible
for pinning the thread to one CPU and/or disabling frequency scaling if
a consistent result is required.
I forgot to include this patch originally. While the warning is
harmless (sigjmp_buf and jmp_buf have the same layout on FreeBSD),
it might not be on downstream ports consumers like DragonflyBSD.
libcpucycles is a microlibrary for counting CPU cycles. Cycle counts
are not as detailed as Falk diagrams but are the most precise timers
available to typical software; they are central tools used in
understanding and improving software performance.
The libcpucycles API is simple: include <cpucycles.h>, call cpucycles()
to receive a long long whenever desired, and link with -lcpucycles.
Internally, libcpucycles understands machine-level cycle counters for
amd64 (both PMC and TSC), arm32, arm64 (both PMC and VCT), mips64,
ppc32, ppc64, riscv32, riscv64, s390x, sparc64, and x86. libcpucycles
also understands four OS-level mechanisms, which give varying levels of
accuracy: mach_absolute_time, perf_event, CLOCK_MONOTONIC, and, as a
fallback, microsecond-resolution gettimeofday.
When the program first calls cpucycles(), libcpucycles automatically
benchmarks the available mechanisms and selects the mechanism that does
the best job. Subsequent cpucycles() calls are thread-safe and very
fast. An accompanying cpucycles-info program prints a summary of
cycle-counter accuracy.
WWW: https://cpucycles.cr.yp.to/
Tested by: jhibbits
