Public result records
The result summaries name directory work, bridge requests and equal-work controls. Performance and responsiveness pages explain why those measurements cannot stand in for one another.
For data centers and other compute-heavy environments, Valen Systems' benchmark method keeps the workload, hardware, versions, correctness, telemetry, cleanup, and limitations attached to every named result.
These are different measurements with different operation definitions. They’re not one universal speed claim.
Equal work, checksums, postconditions, accepted samples, errors, and invalid-trial handling.
Host, runtime, versions, topology, telemetry, startup boundaries, cleanup, and raw artifacts.
Host and load dependence, mixed latency effects, energy scope, unreproduced claims, and experimental status.
A directory operation, an IPC request and a completed workload use different units. Read the record for the component and operation being measured before applying the result to another system.
The result summaries name directory work, bridge requests and equal-work controls. Performance and responsiveness pages explain why those measurements cannot stand in for one another.
Start with matched inputs and accepted output. Then inspect the environment, repeated trials and the boundary of the measurement, especially for energy claims.
The Kestowv pilot references describe workload configuration and operating checks. They identify the supplied environment and the controls a repeatable evaluation needs.
The campaign figures above and the linked public records cover separate tests. Each result retains its own operation definition, environment and limits. An upstream contribution is a different kind of evidence: read the JRuby 10.1 contribution record.
Working through a hardware or runtime decision? Explore compute evaluations