Parallel numerical execution can produce different low-order bits when operation order, compiler settings, math libraries, precision modes, or hardware backends change. Lu(x)iEdge controls the defined execution path and attaches SHA-256 receipts so supported workloads can be reproduced and compared byte-for-byte - in independent testing, five GPU and five CPU runs produced identical hashes for the tested workload.
The largest reproducibility risks typically arise from order-sensitive reductions, fused versus unfused operations, different math-library implementations, precision changes, compiler optimization choices, backend-specific execution, and uncontrolled concurrency or state.
When those factors are uncontrolled, small rounding differences compound - and the same code with the same input can produce different low-order bits across runs, builds, or machines.
This breaks:
You cannot reproduce historical results.
Regulators require predictable behavior.
You cannot reproduce failures.
Lu(x)iEdge controls the factors that cause drift, so supported workloads can be reproduced and compared byte-for-byte under the documented conditions.
Operations follow the documented engine path rather than an uncontrolled reduction order
Inputs, modes, and output serialization are normalized for reproducible comparison
Rust reduces common classes of memory-safety risk
Receipts allow byte-level output comparison when the same documented conditions are reproduced
Determinism claims apply to the documented engine version, execution mode, precision, canonical input, and supported/tested platform combination.
Some deterministic engines - physics libraries such as Box2D and Rapier are well-known examples - accept reduced acceleration in exchange for reproducibility. For games, that tradeoff works.
For quant finance running Monte Carlo at scale, or safety-critical systems that need both real-time performance and reproducible evidence, giving up acceleration is a hard price to pay.
Lu(x)iEdge is designed to preserve defined reproducibility properties while using accelerated CPU and GPU paths. Performance and supported behavior depend on backend, precision, operation, and workload.
| Backend | Status |
|---|---|
| CPU with SIMD (x86-64, ARM) | Available and tested in the evaluated environments |
| NVIDIA CUDA (H100 tested) | Available and tested in the evaluated environments |
| Vulkan | Available but experimental |
| Metal, WASM, RISC-V | Planned |
In TestFort's defined H100 evaluation, the tested workload sustained 286.94 billion aggregate operations per second across the defined tested functions.
Every Lu(x)iEdge response includes a SHA-256 hash of the output. Store the hash at computation time; re-run the same canonical input later under the same documented engine version, mode, and configuration, and a matching hash confirms the output bytes are identical. A complete reproducibility record should also preserve the canonical input, engine version, execution mode, precision, backend, and configuration - an output hash alone does not prove who ran the computation or which input produced it.
{
"expr": "sin(x)*cos(x)",
"x": [0.5, 1.0, 1.57],
"y": [0.4207, 0.4546, 0.0007], // rounded for display
"hash": "98bd97026a738671..." // computed over full output bytes
}
For a fixed workload, faster completion can reduce total board energy when the increase in power is smaller than the reduction in execution time. This must be measured for each workload - race-to-idle is not an automatic guarantee of facility or cooling savings.
The engine ships as a single compact binary that runs locally with no cloud dependency. On supported builds it selects an appropriate backend for the host - SIMD on CPU, CUDA on tested NVIDIA GPUs - with minimal configuration. Supported operating systems, GPU APIs, binary size, and startup behavior are documented per release with the published downloads.
Most benchmarks test isolated operations. That is like playing a single note on a piano.
The Art of Fugue is a defined reproducibility workload combining several numerical expressions and execution patterns - three concurrent "voices" of conflicting intensity: trigonometric identities, logarithmic decay, and discontinuous transcendentals. Its purpose is to expose drift and compare receipts across documented implementations and environments.
The output is captured as a single SHA-256 hash, so any drift between documented runs shows up as a hash mismatch. The public GitHub repository contains the workload definition and the published receipts.
The Art of Fugue covers the core trigonometric and transcendental function suite. Separately, TestFort QA Lab independently evaluated a defined deterministic numeric workload, including the statistical function suite and GPU endurance testing (December 2025); that evaluation did not certify every function, platform, backend, or expression.