Pyvorin for Algorithmic Execution

Algorithmic execution systems contain two kinds of code with opposite requirements. Around the trading day sits analytics: slicing schedules built and rebuilt, market-impact models fitted, participation strategies simulated against historical volume — batch Python measured in minutes. Inside the trading day sits the order loop: decide, slice, place, repeat, on a budget measured in microseconds with a tail that costs real money. Pyvorin is a tool for the first kind. This page draws the boundary with measured anchors and says plainly why the second kind belongs elsewhere.

No customer is quoted; the deployments are illustrative. Speedups name workloads from the benchmark artefact dated 13 September 2026, and any combined arithmetic is labelled an illustrative model.

The acceleratable ring around the order path

Schedule construction. A VWAP or TWAP slice schedule for a parent order is a loop over the day's volume curve: compute target quantities per interval, adjust for constraints, reconcile rounding. Written in Python — as it often is in the analytics layer — it is a pure numeric loop over in-memory data. financial.moving_average, the rolling-window shape underneath volume-curve smoothing, measured 22.5x. etl.top_n_selection, relevant to picking the intervals that matter, measured 7.8x. These are not exotic claims; they are named rows in the published table.

Market-impact research. Fitting impact coefficients from historical parent orders — regressing slippage against participation rate and volatility — is statistics-shaped work. statistics.correlation measured 52.5x, and ml.perceptron_predict, the shape of a fitted linear impact model applied in batch, measured 9.9x. Simulation of execution strategies against replayed volume is numerical.monte_carlo_pi's shape at 28.3x, or simulation.conway_life's at 180.5x for tight state-update loops. A desk that re-fits and re-simulates nightly has hours of exactly this compute.

Portfolio and account state during analytics. object.bank_account — a workload of method calls over account-like objects — measured 147.5x, the suite's strongest object-manipulation result. Research code that walks position and account objects while computing analytics matches that shape.

Read the range as a range. The strong rows describe large, clean, pure-Python loops on one host. A schedule builder that spends its time in pandas calls hands the loop to C and will measure near 1x, as the vectorised-code caveat elsewhere on this site repeats. The analytics described here is the hand-rolled-Python kind, which desks keep because it is transparent and easy to audit.

The boundary itself

The order loop is excluded on latency grounds, and the exclusion deserves its own paragraph because benchmark figures tempt people to ignore it. The loop that decides each slice placement runs synchronously against the market; its requirement is a bounded worst-case response, microseconds, with tail behaviour that directly becomes slippage. Pyvorin is a throughput tool for CPU-bound batch Python. Median speedups on batch workloads say nothing about worst-case latency inside a hot loop. If the requirement is a bounded microsecond response, the correct engineering answer is a language and runtime chosen for that contract — and an execution stack that needs one will already have one. The compiler's place is upstream: it makes the analytics that parameterise the execution system fast enough to run every night, not the system itself.

There is a practical middle ground some desks use, and it is worth describing honestly. Signals and parameters produced by the compiled analytics layer — schedule templates, impact coefficients, participation caps — are exported to the execution runtime each morning. The boundary is a data hand-off, not a code call. That keeps latency-critical code in its dedicated runtime while the research side retains the transparency and iteration speed of Python, now running several times faster on the shapes that matter.

An illustrative deployment

Consider a desk whose nightly analytics builds next day's schedules, re-fits impact coefficients and simulates three participation strategies against a month of replayed volume. Assume profiling attributes 65% of runtime to those loops, 25% to data preparation and parsing, 10% to output and I/O. Assume — labelled, not measured — 15x on the loop share, inside the measured 7.8x to 52.5x range for the matching shapes. The model: 0.25 + 0.10 + 0.65/15 = 0.39 of the old runtime, about 2.5x. On those assumptions, an analytics window that closed at 23:00 closes before 21:00, which in practice means analysts can iterate on the same evening's data instead of queueing against the clock.

The model's fragility is in the data-preparation share, as usual. Replay preparation that parses raw market-data feeds nightly will find parsing at or below 1x in the suite — the parsing category's geomean is 0.86x — and every point of parsing share subtracts from the model. Materialising parsed replays once is worth more than any flag.

What a pilot looks like

A contained pilot precedes any integration. Take the schedule builder — the most self-contained analytics function, and the one with the clearest deadline — and run the proof sequence on it with a realistic volume curve as input. An afternoon answers the material question: whether your loop measures anywhere near the published anchors. The honest outcomes are the usual three. Near the anchors, and the pilot extends to the impact fitting and strategy simulation. Near 1x, and the analytics is vectorised already, in which case the compiler has nothing to remove and the honest answer is that the analytics is fine as it is. Declined, and the fallback record explains why. Each outcome is a decision made at pilot cost rather than at integration cost.

One pilot detail matters here: fix the volume curve and the replay period in the write-up. Execution analytics is measured against specific market periods, and a schedule builder proven over one month of data is proven over that month. Recording the period alongside the proof keeps the claim scoped, and re-running on each new period is cheap once the harness commands are scripted.

Where the engineering judgement sits

The judgement specific to execution is resisting scope creep across the boundary. Execution codebases grow organically: an analytics helper gets imported by the order loop, a formatting utility migrates inward, and before long the seam is a fiction. An engineer who enforces the data-hand-off boundary — analytics exports parameters, the runtime never imports analytics modules — keeps the latency-critical surface clean and keeps the compiled layer free to change daily. The one who lets the import graph blur the boundary will eventually discover why that is expensive, in slippage rather than in a benchmark.

The second judgement is the correctness gate on exported parameters. A coefficient or schedule that changed value in compilation is a trading defect, not a performance footnote. The proof workflow's requirement — both backends returning the identical result, quoted in the write-up — is where a compiled analytics layer earns its place upstream of a trading system. Parameter files should be accompanied by their proof records the way model changes are accompanied by validation notes.

Proving it on your own analytics

python -m pyvorin support your_analytics.py
python -m pyvorin run your_analytics.py --function entry --compare --runs 5 --warmup 2
python -m pyvorin bench your_analytics.py --function entry --runs 7 --warmup 2 --json

Quote only runs showing Correct: YES and COMPILED_FULL, with matched warmup and run counts; report the median of the raw samples and keep the compile cost alongside. The full discipline, including the audit-proof write-up, is how to run a speed proof; harness mechanics are in how to benchmark a function.

Limits, stated plainly

One host, one date, one suite: the anchors are a map, your measurement the verdict. Vectorised analytics has no interpreted loop to remove. Market-data parsing regresses under compilation. The order loop is out of scope for latency reasons, full stop. Declined functions fall back to correct CPython behaviour via the path in unsupported code and the fallback path, which is also the safety net that makes a small, clean compiled surface the right design.

Where to go next

• How to run a speed proof — the measurement discipline, including the correctness record trading parameters need.
• Benchmarks — the full 71-workload table behind every anchor here.
• Pyvorin for quantitative trading — the research-side sibling of this workload.
• Unsupported code and the fallback path — the safety semantics under the compiled surface.

Last reviewed 28 May 2026 against the benchmark artefact dated 13 September 2026 (71 workloads, 54 faster / 17 slower than CPython, suite geomean 3.16x). Anchor figures are extracted from that artefact; deployment arithmetic is a labelled illustrative model. This page contains no customer claims.