sample_cpu_temperature() only ever had a Linux implementation, so
Windows and macOS runs recorded empty temperature data points for
every sample. sample_cpu_clock_mhz() on both platforms read a static
nominal frequency once (Windows: the ~MHz registry value; macOS: the
hw.cpufrequency sysctl) instead of a live reading, so clock speed
showed as a constant throughout the benchmark.
Windows: temperature now queries the ACPI thermal zone over WMI
(MSAcpi_ThermalZoneTemperature), and clock speed reads live per-core
frequency via CallNtPowerInformation(ProcessorInformation). Both are
XP-compatible (verified via mingw cross-compile with the existing
windows-i386 XP toolchain/PE checks).
macOS: temperature reads the SMC directly (AppleSMC user client),
checking known CPU sensor keys across Intel and Apple Silicon
(M1-M5). There is no live-frequency API on macOS at all (Apple
Silicon has none, and hw.cpufrequency was always a fixed nominal
value even on Intel), so clock speed now reports as unavailable
instead of a misleading constant.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PcL8rcwwBeD6W3fZFCRLss
Adds CPU telemetry recording (temperature and clock speed) during
benchmark runs, uploaded alongside results. Workload phase recording
was tried and then removed after it was found to distort scores;
telemetry now samples at 2/sec.
The telemetry thread's per-core /sys scan was contending with the
timed benchmark passes, and could corrupt the workload-size
calibration step, causing run-to-run swings of up to 4x. Removing
phase recording and dropping the sample rate from 4/sec to 2/sec
brings runs back to <5% variance.
Two of the workloads (Native Integer Math and Memory Bandwidth) were
plain C rather than assembly, so the compiler's auto-vectorizer got to
decide how fast they ran. Newer Clang basically tripled the integer
number and blew up the STREAM triad by ~3x, which meant the same chip
landed all over the place depending on how it was built. Pinned both to
scalar codegen so GCC and Clang line up again.
Also stopped run_test from keeping only the fastest repeat -- it was
rewarding one lucky pass and hiding the normal run-to-run wobble. It
averages the repeats now.
And core detection was just wrong on a couple platforms. Windows was
handing back logical processors as physical cores (so an 8c/16t part
showed up as 16 cores), and Linux boxes where /proc/cpuinfo doesn't
carry topology (PowerPC, ARM) fell back to the thread count too -- a
176-thread POWER8 claimed 176 cores. Windows now counts real cores via
GetLogicalProcessorInformationEx, and Linux falls back to sysfs
thread-sibling groups, which also handles Apple Silicon's per-cluster
core_id numbering.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Windows builds previously stubbed out --upload entirely. WinHTTP handles
TLS and certificate verification against the system trust store natively,
so unlike the POSIX path this needs no OpenSSL/embedded CA bundle - just
-lwinhttp, a system DLL that ships with Windows.
Release binaries are built fresh by CI (.github/workflows/release.yml)
and attached to GitHub releases; checked-in binaries here were just
stale build output, not something the release pipeline reads.
SSL_CTX_set_default_verify_paths() only works if OpenSSL's compiled-in
default CA path happens to exist on the machine running the binary -
a path baked in wherever OpenSSL was built, not where the release
binary ends up. That almost never matched an end user's machine
(no such path on stock macOS; Linux distros disagree on the
location), so --upload failed with a TLS/certificate error on nearly
every machine except the one that built the release binaries.
Embed the Mozilla CA root bundle (src/ca_bundle.h) as a fallback trust
source, tried alongside the system's own default paths so locally-
trusted/corporate CAs still work where present. Windows is unaffected
since TLS is stubbed out there already.
Bump to 0.1.5-hotfix2.
The x86-64 kernels were written to the System V ABI only; on Windows's
different calling convention they silently read garbage args and ran in
near-constant time regardless of iteration count. Each public kernel now
gets a small ABI-translating thunk (WIN64_THUNK) on Windows so the kernel
bodies stay single-source. i386 also needed underscore-prefixed symbol
names to match Windows's cdecl convention. Verified end-to-end under Wine,
including determinism across repeated runs.
Also fixes CPU-core detection (sysconf isn't available under MinGW) and
adds memory/CPU-brand detection for the Windows system-info banner.
Uploads can now be attributed to a fossbench.net profile: set
FOSSBENCH_TOKEN and the client sends it as a Bearer token, which the
server auto-approves and links to the account. Anonymous, pending-review
upload stays the default when no token is set. New --upload/--noupload
flags skip the interactive prompt for scripted runs, and the client
reports HTTP 401/422 distinctly from other failures. The token is never
printed or logged.
Also renames the project and its internal identifiers (FM_/fm_ macros
and symbols, source filenames, binary output names) from fossmark to
fossbench, matching the actual product name. The "fossmark_version"
field in the upload payload is left as-is, since it's the server API's
fixed contract field, not this client's own name.
Replaces the C fallback (borrowed from PowerPC) with dedicated i386
assembly for all nine kernels, matching the amd64/arm64 convention.
Fixes two real bugs found and verified on physical Pentium 4 hardware:
scalar FP silently running on x87 instead of SSE2, and fm_int_math
calling __udivdi3 on every iteration of the highest-weighted test
because the C compiler didn't know its 0xdeadbeef divisor fits in 32
bits. Real-hardware SINGLECORE/MULTICORE scores go from 425/448 to
539/581.
owenandClaude Sonnet 5