Why do you deliver a build and not the source?
The optimization method is our know-how, so we deliver a static or dynamic library with a C header and a thin Rust wrapper. Hooking it up takes one line in Cargo.toml. Correctness is confirmed by equivalence tests, origin by the signature and provenance.
What happens when I change my code?
Rust integration and switchback are agreed for the delivered library. If the optimized core changes, send a new version for another measurement; CI work requires a separate accepted order. For business continuity, source escrow can be requested before payment through a qualified escrow box under the rider.
Do I have to send you my strategy?
Not for a preliminary range: the free harness produces a readings bundle without source code. For the build we need the code that runs in the hot loop, and only that, usually the simulator, the indicators and the portfolio state. It is covered by the NDA, is not used in work for other clients and is deleted on schedule. Part of your data can stay with you until acceptance: hidden inputs are sent encrypted, and you give the key once the build is ready.
Why not just add more cores?
Do both. Independent runs of a sweep spread across cores well, and our build makes each of those runs faster on every core you add. More cores do not help a single simulation along one history, where each step depends on the previous one, and that is exactly the code we speed up. Fewer core-hours for the same sweep also means a smaller cloud bill.
What if the promised speedup does not materialize?
On level 1 you pay for a result that is already measured, so this cannot happen. On level 2 we name a guaranteed minimum; if it is not reached, the money goes back to your balance according to the table in the contract, and paid funds on the balance are paid back on request.
How are lines counted?
We build your code with -C instrument-coverage in the same profile and for the same platform as in the passport, and run the passport benchmark on the open inputs. We count the Rust lines that executed at least once according to llvm-cov. Not counted: blank lines and comments, code that never ran, tests and benchmark scaffolding, third-party dependencies outside the scope of work, and assembly; a generic function counts once. The number goes into the passport before payment. Data does not count, only your code. For reference: decompressing the Silesia corpus with bzip2-rs executes 598 lines of its code, and encoding five Xiph clips with rav1e executes 12,809 lines out of 55,419.
Which platforms are supported?
The public demos target Linux x86-64 with AVX2/FMA. TA-Lib and vn.py measurements include AMD Zen 3 and Zen 4. For a paid build, CPU features, OS, ABI and acceptance hardware are fixed for the order; Intel, ARM and other environments need their own assessment.
What code speeds up poorly?
Decoders of formats that already have long-optimized C libraries (LZ4, zstd, deflate): we have not beaten them yet. Mature codecs with hand-written SIMD and assembly (x264, x265), cryptographic primitives such as SHA-256 and ChaCha20, processing of random incompressible data, and very short calls where all the time goes to overhead. In such cases the free estimate honestly shows a small gain, and you will not have to pay.
My cycle counts differ from yours. Why?
Cycles depend on the CPU model, frequency, turbo, memory and input data. Contract numbers are taken on the rig under the measurement passport. The harness reads the same counters, so on the same CPU model and settings your numbers should be close to ours. The instruction count depends far less on the machine: compare it first.
What about floating point?
By default, outputs match bit for bit, with a limited exception for NaN payloads produced by floating-point arithmetic where Rust permits different payloads. Explicitly preserved NaN encodings and other outputs remain exact unless you agree otherwise in the passport. The passport can also require exact NaN payloads. Any other agreed deviation is defined in the passport and checked by tests.
Will the build crash on an old server?
Check the CPU requirements of each package. Public showcase binaries may require AVX2/FMA and will not run on an older CPU. A paid build’s supported features and any fallback are agreed in its passport; a fallback is not assumed for every binary.
Will it cut the latency of my live trading?
Only if profiling shows that the computation is the bottleneck. For a live path we measure the whole path from the market event to the order, for example its p99 on your server, not one function: often most of the time goes to the network and the exchange. Our strongest results are batch computations: backtests, training and parameter sweeps.
Do you work with C, C++ and Python?
Yes, as individual orders. For C and C++ we deliver a drop-in replacement library with the same ABI, so your programs, and Python code that calls the library, work unchanged (see the TA-Lib case). For Python code we deliver a native program or module with the same output (see the vn.py case). This is level-2 engineering work, priced individually; self-service in the dashboard currently accepts Rust crates.