Computational Cost And Parallel Forest Fitting

Why Computational Cost Matters

A random forest can be statistically sensible and still be impractical to fit. Increasing the number of trees, using more candidate predictors at each split, or expanding the training data can increase computation substantially. Parallel execution may reduce elapsed time, but it does not make the underlying work disappear, and additional workers can require additional memory.

For an actuarial analysis, computational choices affect more than convenience. They influence how many candidate models can be compared, whether a validation plan can be completed, and whether a fit is feasible on the available machine. A useful estimate is not a guarantee of runtime; it is a structured way to anticipate the main costs and identify assumptions that need checking.

A Practical Model of Forest-Fitting Work

Suppose a forest fits \(B\) trees using \(n\) training observations and considers \(m\) candidate predictors at each split. Each tree repeatedly searches for splits in subsets of the observations. Its work depends on the number of nodes, the observations reaching each node, the split-search method, and the predictors considered. Therefore, no formula based only on \(n\), \(B\), and \(m\) gives an exact runtime for every implementation and data set.

For a rough comparison, a useful proxy is \(Bnm\log_2(n)\). This proxy assumes that the trees have broadly comparable shapes and split-search costs, and that changing the data size does not radically change factor handling or other implementation details. The logarithmic term represents the increasing depth or sorting/search effort often associated with larger samples. It is a scaling approximation, not a guaranteed complexity bound for every tree-building algorithm. Very unbalanced trees or costly split calculations can behave differently.

This expression gives a disciplined way to compare proposed fits. Holding everything else fixed, doubling \(B\) approximately doubles the work. Increasing \(m\) by 50% approximately increases the work by 50%. Doubling \(n\) increases the proxy by slightly more than a factor of two, because the logarithmic factor also changes. Actual elapsed time can depart from these ratios because of hardware, memory bandwidth, data types, factor predictors, tree controls, and parallel overhead.

Why Parallel Speedup Is Limited

Trees in a forest can often be fitted independently, so forest implementations can distribute substantial work across processors. However, not every part of a fit necessarily runs in parallel. Data preparation, coordination, prediction assembly, and other tasks may remain partly serial. Parallel execution also has overhead, and several workers may compete for memory bandwidth or other shared resources.

A standard way to describe the limit is Amdahl’s law. Let \(f\) be the fraction of a computation’s time that can be parallelized, and let \(p\) be the number of equally effective workers. Assume for this idealized calculation that parallel work is divided evenly and that communication and scheduling overhead are zero. The remaining fraction, \(1-f\), is serial.

The denominator is the fraction of the original elapsed time that remains: the serial fraction plus the parallel fraction divided among \(p\) workers. This explains why adding workers has diminishing benefit. Even with indefinitely many workers, the serial portion remains, so the maximum ideal speedup is \(1/(1-f)\).

Memory and Worker Choices in R

Memory demand has several sources: the input data, temporary objects used during fitting, and the forest object retained for later prediction or interpretation. A parallel strategy can add further demand. In particular, parallelizing several separate model fits using separate R processes may duplicate input data and hold several fitted objects at once. By contrast, threads within a single fit do not necessarily create a full private copy of the input for every thread. The actual behavior depends on the implementation and operating system, so a memory calculation is an estimate to be checked, not a universal rule.

With the ranger package, the num.threads argument controls the number of threads used for fitting. It should be set deliberately rather than assumed to match the number of logical processors. The usable resources may be limited by a shared server, a job scheduler, or other work running on the machine. A machine’s reported logical processor count is not always the number of processors available to the current task.

Parallelize at One Level at a Time

A common R workflow has two possible levels of parallelism: run several resampling or candidate-model fits simultaneously, or let each forest fit use several threads. Combining both without a resource plan can create far more active workers than intended. For example, four concurrent model-fitting processes, each requesting four threads, may try to use up to 16 threads. This can increase contention rather than reduce elapsed time.

A practical sequence is to decide which level has the largest independent workload, allocate the available resources there, and set the other level to avoid nested oversubscription. For a single large forest fit, using ranger’s thread setting may be appropriate. When comparing several independent fits, it may be more effective to parallelize the fits and use fewer threads within each fit. The better choice depends on the workload and machine; a small benchmark under the intended conditions can resolve the trade-off.

Common Computational Traps

One frequent error is to assume that \(p\) workers always reduce elapsed time by a factor of \(p\). That is only an ideal limit when the work is fully parallel, evenly divided, and free of overhead. As the worked speedup example shows, a serial component alone makes that conclusion incorrect.

Another error is to extrapolate runtime from tree count alone. If sample size or \(m\) also changes, the approximate work changes as well. For example, the proxy ratio for two fits is:

Using this ratio is more defensible than assuming runtime is proportional to \(B\) in all circumstances. It still relies on comparable tree-building behavior and does not replace measurement. Also avoid interpreting low CPU use as proof that more threads will help: the fit may instead be limited by memory bandwidth, data handling, or a serial stage.

For an analysis aligned with the SOA Exam PA (Predictive Analytics) syllabus, explain the basis of a computational recommendation. Identify the workload being compared, state whether the estimate is about elapsed time or memory, and disclose the assumptions behind any scaling or speedup calculation. A resource choice is more useful when its limitations are clear.