Parallel backtesting: why compute is time
6 min read
Our work is one loop: build a strategy, test it, deploy it. The loop is only as fast as its slowest stage, and for most quant teams that stage is testing.
The research loop
Every strategy we ship follows the same path. A hypothesis becomes code. The code runs against historical tick data. The results decide whether it moves forward, goes back to research, or gets dropped. Only a validated candidate reaches the engine that mirrors trades into each end client's own MT5 account at their own regulated broker.
Writing the idea is rarely the bottleneck. Validating it is.
Why sequential backtesting is slow
A single backtest is cheap. A credible validation is not. One idea quickly turns into hundreds of runs:
- Walk-forward analysis: fit on one window, test on the next, roll forward, repeat across regimes.
- Out-of-sample checks: the same logic on data and instruments it has never seen.
- Parameter sweeps: every input varied to see whether results sit on a plateau or a spike.
- Monte Carlo resampling: trade order, costs and slippage randomized thousands of times to stress the drawdown profile.
Run all of that on one machine and research stops being a loop. It becomes a queue.
An embarrassingly parallel problem
Most of this work is embarrassingly parallel. Each walk-forward window, parameter set, or Monte Carlo path is independent. No run needs the result of another. The job scales close to linearly with the number of workers, limited mainly by data loading and result aggregation.
Illustrative arithmetic
2,000 backtests x 20 minutes = 40,000 minutes
1 worker → about 667 hours, roughly 28 days
64 parallel workers → about 625 minutes, roughly 10.5 hours
Illustrative only. Real run times depend on strategy complexity, data resolution and I/O.
The same research question gets an answer the next morning instead of next month. That is why our investment ask is compute, not trading capital. Money buys time, and time is the scarce resource in research.
More tests is not more truth
Faster testing has a trap. If you can run 2,000 variants overnight, you can also find one that looks brilliant by chance. Compute makes overfitting cheaper too, so the guardrails scale with the cluster:
- Hold-out data stays locked. A final out-of-sample period is never touched during development and is used once.
- Multiple-testing awareness. The more variants we try, the higher the bar for any single result. We record how many configurations were tested, not just the winner.
- Walk-forward over single splits. A strategy has to survive many sequential out-of-sample windows, not one lucky one.
- Robustness over peaks. We prefer parameter regions that hold up consistently over single settings that score best.
Parallel compute is valuable because it lets us run these checks every time, not because it produces better-looking backtests.
Why it matters for B2B clients
Companies license our engine or ask us to build and operate strategies for them. For them, a faster loop means:
- Shorter time from a strategy request to a validated candidate.
- Re-validation on fresh data as a routine job, not a quarterly project.
- Changes to execution logic tested against the full history before they reach production.
We manage the technology, never the money. Faster research means the technology our clients license improves faster.
Conclusion
Compute is the shortest path from idea to evidence. If you want to help us shorten that path, read the investor overview. If you want to see what the engine is built on, explore the technology.