Benchmark campaigns

Equal work. Correct output. Disclosed limits.

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.

4,387,675Median mixed subsystem operations per second across three full-kernel runs, zero errors, 116 of 116 modules.
3.254×JRuby parallel scaling against 1.0005× CRuby scaling for equal checksum-matched work.
94,160,428Deterministic useful operations per second in the named maximum transport profile.

These are different measurements with different operation definitions. They’re not one universal speed claim.

Correctness first

Equal work, checksums, postconditions, accepted samples, errors, and invalid-trial handling.

System context

Host, runtime, versions, topology, telemetry, startup boundaries, cleanup, and raw artifacts.

Limitations disclosed

Host and load dependence, mixed latency effects, energy scope, unreproduced claims, and experimental status.

Inspect the result, then the method.

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 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