backtestEngine / runBacktest speed of execution / parallelisation

Hi Experts,

Do we know whether runBacktest (part of backtestEngine) does any parallel execution ... on timatables having daily data (say, up to 10K lines), daily rebalance is "bareable" - however, the higher the table, the slower the execution. Looking at the CPU, it doesn't look like parfor is being used at all. Basically, getting on higher time resolution, anything other than daily bars (such as hourly, minute, etc.) - it gets practically impossible to execute a runBacktest on a bar by bar rebalance, even on a very small number of tickers / instruments / timetable columns (take 20 for example, forget about taking a full index).

Thanks

Answer 1

[Shubham]

Hi Andy,

It appears you're encountering performance issues with MATLAB's runBacktest function, particularly when dealing with high-frequency data such as hourly or minute bars. The runBacktest function, part of the MATLAB backtestEngine, is designed to streamline the process of backtesting trading strategies over time series data. However, the documentation and user guides available do not explicitly state that runBacktest utilizes parallel computing or the parfor loop for execution.

Parallel computing in MATLAB, facilitated by the Parallel Computing Toolbox, allows for the distribution of tasks across multiple CPU cores or workers, potentially speeding up computations significantly. The parfor loop is a common way to parallelize iterative tasks that are independent of each other, which seems like it could be beneficial for backtesting scenarios where each period's rebalance or strategy evaluation could theoretically be processed independently.

Addressing Performance Issues

If runBacktest does not inherently utilize parallel processing, and performance is a concern, here are a few strategies you might consider:

1. If your backtesting logic can be modularized, you might manually implement parallel processing using parfor or other parallel computing functions. This approach requires a good understanding of how to divide your backtesting task into independent chunks that can be processed in parallel.
2. Ensure that your data handling within the backtest is as efficient as possible. This includes pre-processing data outside of the backtest loop, using efficient data structures (e.g., matrices or arrays instead of tables for numerical computations when possible), and minimizing the overhead within each iteration of the backtest.
3. As a temporary measure or for initial testing phases, consider reducing the frequency of rebalancing or using lower-resolution data. While this may not be ideal, it can provide quicker feedback on the performance of your strategy before moving on to more granular data.
4. For strategies that do not require tick-by-tick or bar-by-bar rebalancing, consider batch processing where you evaluate the strategy at less frequent intervals. This can significantly reduce the computational load.
5. Look into other tools and libraries that might be more optimized for high-frequency backtesting. Depending on your specific needs, there might be specialized software or libraries designed to handle high-frequency financial data more efficiently.