In June 2026, Asymmetry Computing published a paper describing how PRISM, its real-time optimization engine, performs on institutional rebalancing workloads: Asymmetry PRISM: A CPU/GPU Portfolio Optimization Engine for Deadline-Bounded Institutional Rebalancing (arXiv:2606.23367). This post is the plain-language version — what the benchmark measures, how it was set up, and, importantly, what it does not claim.
If you only read one thing: the headline result is that on completed multi-solver rows from N=100 to N=2,000, Asymmetry PRISM-CPU is 4.5× to 24.1× faster than the fastest completed reference row in the same lane. Everything below is about what each of those words is doing.
The evaluation boundary, and why it exists
The benchmark is built around a deliberate boundary. Problem data goes in. What comes out is a defined set: returned weights, status codes, timings, memory class, external feasibility diagnostics, eligible objective comparisons, and audit records.
That boundary is doing two jobs at once. It keeps the engine's internals proprietary, which is a straightforward commercial choice. But it also does something more useful for a skeptical reader: it forces the evaluation to be conducted entirely in terms a buyer can verify from the outside. You do not have to trust a description of how the method works. You check whether the returned weights are feasible, whether the objective is competitive, and how long it took — all from the outputs.
This is a stricter standard than most vendor benchmarks meet, and it is the reason the artifacts can be published at all.
Figure 1: What crosses the evaluation boundary
"Completed rows" is the most important qualifier
The comparison is stated over completed multi-solver rows. This deserves attention, because it is the qualifier that keeps the number honest in both directions.
In a benchmark lane, some solver/problem combinations do not finish — they time out, or they return something that fails an external feasibility check. There are two dishonest ways to handle that. You can count a timeout as an infinitely large speedup, which manufactures spectacular numbers from nothing. Or you can drop the hard instances entirely and report only the easy ones, which flatters everybody equally.
Reporting over completed rows means the speedup is computed where a reference solver actually produced a comparable answer. It is the conservative choice: the cases where a comparator did not complete are exactly the cases where a speedup ratio would look most impressive, and they are excluded from the ratio.
"Fastest completed reference row in the same lane"
The comparison is not against a single named competitor or a convenient baseline. It is against the fastest reference that completed the same problem in the same lane. If several reference methods ran, the best-performing one sets the bar.
This matters because the easiest way to inflate a solver benchmark is comparator selection — pick a slow baseline, or a badly configured one, and any engine looks good. Comparing against the best completed alternative removes that lever.
The N range, and why it is stated rather than hidden
The result is scoped to N=100 through N=2,000. That is a stated range, not a marketing-friendly extrapolation, and a careful reader should treat it as a boundary rather than a trend line to extend. Claims about behaviour outside a measured range are exactly the kind of thing that should be checked rather than assumed.
Separately, and reported through the site's benchmark pages rather than this paper, larger universes have been exercised: a 75,257-asset rebalance with full risk attribution returned in under a second, and 100,004 real assets backtested at roughly 1.8 seconds per rebalance. Those are different measurements, on different lanes, and it is worth keeping them mentally separate from the paper's figure rather than blending everything into one number.
What a benchmark like this cannot tell you
A published benchmark establishes that an engine can do a thing on a defined workload. It does not establish that it will do the thing on your workload. Your universe, your risk model, your constraint stack, your tax rules, and your current baseline are all different, and any of them can change the answer.
This is not false modesty — it is the actual limit of what external evidence can carry. Public numbers are a filter for whether a conversation is worth having. A matched-workload pilot, run on your data with a pass/fail metric you set before it starts, is what settles it. We have written separately about what such a pilot should prove and how to read solver benchmarks adversarially — including our own.
Check it yourself: the evaluation artifacts — result tables, the evidence ledger, and external feasibility and residual checks — are published at github.com/AsymmetryComputing/prism-public-evaluation. The provenance of every headline figure is indexed on the research page.
Reading the rest of the evidence
The paper is one lane. The measured runs behind the other claims — energy dispatch, direct indexing, portfolio decisioning — are on benchmarks, with the losing cases kept in. For background on why this workload has a deadline in the first place, see Deadline-Bounded Institutional Rebalancing.
Sources & further reading. Asymmetry Computing publishes the evidence behind PRISM openly: the paper Asymmetry PRISM: A CPU/GPU Portfolio Optimization Engine for Deadline-Bounded Institutional Rebalancing (arXiv:2606.23367), the public evaluation artifacts at github.com/AsymmetryComputing, the measured runs on benchmarks, and the provenance of every headline number on the research page.