Pyvorin for Risk Management

Risk management runs on two clocks. The slow clock is the overnight batch: Monte Carlo value-at-risk, correlation matrices, stress grids over thousands of scenarios — compute measured in hours, deadlines measured in "before the desk arrives". The fast clock is intraday: limit checks and margin calls on a latency budget of milliseconds or less. Pyvorin belongs squarely on the slow clock. This page maps the boundary with measured anchors from the benchmark artefact dated 13 September 2026, named per workload so each can be checked.

No customer appears here; the patterns are illustrative deployments. Modelled arithmetic is labelled as such.

The slow clock: what the measurements support

Monte Carlo VaR is the archetype. Simulate tens of thousands of correlated paths, value the portfolio along each, take a percentile. The per-path valuation loop, written in plain Python, is interpreted-loop work of the kind the compiler removes. The suite's nearest measured shapes: numerical.monte_carlo_pi at 28.3x for the simulation-loop core, statistics.correlation at 52.5x for the pairwise-correlation stage, and the financial category itself — financial.moving_average at 22.5x, financial.compound_interest at 8.1x — with a category geomean of 13.5x. For covariance-shaped work, numerical.matrix_multiply measured 4.9x and numerical.matrix_vector 62.4x.

Stress testing multiplies the same shape by the scenario count: each scenario is a revaluation loop, and scenarios are embarrassingly parallel across cores. Scenario grids are where the measured range matters most honestly — the suite's strong rows describe clean loops over large inputs, and a stress scenario with 200 positions and 50 factors may be too small to reach them. The suite also contains the cautionary rows: statistics.mean_variance at 1.0x and graph.floyd_warshall at 1.0x, both plausible-looking risk shapes that measured flat. Size decides. A stress grid with large scenario counts over meaningful portfolios sits in the acceleratable territory; a dozen small scenarios do not.

Honesty requires naming what is absent. There is no published workload named "Monte Carlo VaR", no expected-shortfall engine, no copula generator. The analogues above are the evidence; the specific claim about your risk library is yours to measure.

The fast clock: what they do not support

Intraday limit monitoring checks every position against every limit, continuously. The arithmetic per check is small; the requirement is a bounded, dependable response time inside a system that also handles market data and bookings. This is a latency problem with a tail budget, and Pyvorin is a throughput tool for CPU-bound batch Python. Median backtest speedups say nothing about worst-case response under load. Where the requirement is "always under two milliseconds, including the tail", the correct engineering choice is a runtime selected for that contract — and this page says so plainly rather than stretching a benchmark table to cover a case it does not.

Between the two clocks sits a grey zone worth describing: near-real-time risk, where batches run every few minutes rather than overnight. There, compiled batch Python can be legitimate — minutes-scale deadlines are throughput problems — provided the process is not on the synchronous order path and its tail behaviour is monitored like any other batch job. The line to hold is architectural, not numeric.

An illustrative deployment

Consider an overnight risk batch: 60% of runtime in Monte Carlo and scenario loops, 25% in market-data parsing and preparation, 15% in report formatting and I/O. Assume — labelled, not measured — 20x on the loop share, inside the measured 8.1x to 52.5x range for the matching shapes. The model yields 0.25 + 0.15 + 0.60/20 = 0.43 of the old runtime, about 2.3x end to end. On those assumptions, an eight-hour batch becomes a three-and-a-half-hour batch, or the same batch runs on fewer machines at the same deadline.

The model's sensitivity is instructive. Risk batches that re-parse reference and market data nightly will find the 25% parsing share larger — and parsing measures 0.7x to 1.0x in the suite, so every point of parsing share subtracts directly from the win. Materialising parsed inputs once, ahead of the loops, is frequently worth more than the compiler. Conversely, teams whose batches are simulation-dominated, with data already in memory, will find the model conservative. Your profiler, not this page, decides which you are.

What a pilot looks like

A contained pilot comes first. Take the correlation function or the Monte Carlo core, wrap it in a zero-argument entrypoint over a representative portfolio, and run the proof sequence on it. An afternoon of work answers the material question: whether your loop, on your position data, measures anywhere near the published anchors. The honest outcomes are three, as ever. The number lands near the anchors and the pilot proceeds. It lands near 1x, meaning the loop is library-bound or too small to amortise, and the batch needs restructuring rather than compilation. Or the function is declined, and the fallback record says why. Each outcome is a cheap decision; the expensive version is skipping the pilot and discovering the same fact during a production run against the reporting deadline.

Two pilot details matter for risk code. Size the input like production: a correlation matrix over ten positions tells you nothing about one over two thousand. And record the environment in the write-up — Python version, Pyvorin build, input size — because a risk function re-measured next quarter against a changed library is a new claim that needs a new proof, not a confirmation of the old one.

Where the engineering judgement sits

The judgement specific to risk systems is governance of the correctness gate. A faster VaR number that differs from the validated reference by a basis point is not a faster VaR; it is a model change, and model changes go through validation. The proof workflow's correctness check — both backends returning the identical result — is therefore not a courtesy in this domain; it is the difference between a performance improvement and an unapproved model revision. Teams should also pin the measured configuration: the Python version, the Pyvorin build, the input sizes, recorded in the write-up exactly as how to run a speed proof prescribes, because a risk function re-measured next quarter against a drifting library is a new claim, not a confirmation.

The second judgement is placement of the seam. Risk code accumulates formatting, logging and report assembly inside the same functions as the maths. The compiled module should contain valuation and aggregation loops only — no string work, no I/O, no percentile calls into C unless measured. An engineer who draws that seam gets an interpretable number and a small fallback surface; one who compiles the drifting whole gets a blended figure that will not survive a validation review.

Proving it on your own risk batch

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

Quote only runs showing Correct: YES, COMPILED_FULL, and matched warmup and run counts. Report the median of the raw samples, keep the compile cost visible next to it, and record the environment in full. The harness mechanics are in how to benchmark a function, and the full 71-workload context for the anchors is on the benchmarks page. Scripting the three commands into the batch's release validation turns the proof from a one-off exercise into a standing gate — a small process change that keeps every future claim attached to a recorded measurement, which is what a validation review will ask for anyway.

Limits, stated plainly

One host, one date, one suite — the distribution is the message, your measurement the verdict. Market-data parsing and report formatting will not accelerate and can slow slightly if compiled. Workloads whose heavy work lives in C libraries or vectorised frameworks have no interpreted loop to remove. Intraday latency-critical checks belong on a different runtime, and the fallback path — described in unsupported code and the fallback path — is what keeps any declined function correct while you decide what to do with it.

Where to go next

• How to run a speed proof — the audit-grade method, including the write-up a validation review will accept.
• Benchmarks — the full measured table, slower rows included.
• Example workload: financial risk calculations — the same analysis worked through stage by stage.
• Pyvorin for regulatory reporting — the downstream consumer of risk outputs.

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