How do you do it?
We analyse the code and apply the Pareto principle as deeply as it goes: we remove computation that isn’t needed and use different computational methods, moving a significant part of the work from run time to compile time.
Why do you deliver a build and not the source?
The optimization method is our know-how, so we deliver a build, never source code: for a Rust crate, a static or dynamic library with a C header and a thin Rust wrapper that hooks up with one line in Cargo.toml; for a C or C++ project, the executable. Correctness is confirmed by equivalence tests, origin by the signature and provenance.
What happens when I change my code?
Integration and switchback are agreed for the delivered build. 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 coverage instrumentation 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 lines of your code that executed at least once: for Rust with llvm-cov (-C instrument-coverage), for C and C++ with gcov. 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 the language of your code 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. We optimize your C and C++ source code: projects built with CMake or make go through the dashboard like Rust crates, are measured before you pay, and you receive the executable. A drop-in replacement library with the same ABI, so that your programs and Python code that calls the library work unchanged (see the TA-Lib case), and native builds for Python code with the same output (see the vn.py case) remain level-2 engineering work, priced individually.