Optimizing Computation with MATLAB parfor: Implementation and Variable Constraints

Solving Execution Bottlenecks with Parallel Loops

When processing large datasets or running repetitive simulations in MATLAB, a standard for loop executes sequentially on a single CPU core. If the iterations are independent—meaning the result of iteration 10 does not depend on the result of iteration 9—you can reduce total execution time by using parfor. This distributes the workload across multiple worker processes (cores) in a parallel pool.

The primary takeaway for implementation is that parfor is not a drop-in replacement for for; it requires specific variable classifications to avoid communication overhead and runtime errors. To see a performance gain, the computational cost of the loop body must be significantly higher than the overhead of sending data to the workers.

Configuring the Parallel Pool

Before running a parfor loop, MATLAB must initialize a parallel pool. While MATLAB often starts a default pool automatically when parfor is called, manual configuration allows you to control memory usage and core allocation.

% Run this in the MATLAB Command Window or a script
% Check available cores and start a pool with a specific number of workers
numCores = feature('numcores');
parpool('local', numCores); 

Risk: Allocating all available cores to a pool can starve the OS or other background applications of resources, potentially leading to system instability during heavy memory-intensive tasks.

Worked Example: Parallelizing Independent Simulations

Consider a scenario where you need to calculate the sum of squares for several large arrays. In a serial loop, this happens one by one. In a parfor loop, MATLAB slices the output array and distributes chunks of the work.

% Setup: Generate a cell array of 100 random matrices
numSims = 100;
data = cell(numSims, 1);
for i = 1:numSims
    data{i} = rand(1000, 1000);
end

% Preallocate the results array to ensure it is a 'sliced' variable
results = zeros(numSims, 1);

% Start timing
tic;
parfor i = 1:numSims
    % Each iteration is independent
    % 'results' is a sliced variable because it is indexed by the loop variable 'i'
    results(i) = sum(data{i}(:).^2);
end
toc;

Variable Classification in parfor

To make the above code work, MATLAB classifies variables into specific categories. Misclassifying these is the most common cause of parfor failures:

• Sliced Variables: Arrays indexed directly by the loop variable (e.g., results(i)). MATLAB sends only the necessary slice to each worker.
• Broadcast Variables: Variables that are read but not modified (e.g., data in the example above). These are copied to every worker, which can consume significant memory if the variable is large.
• Reduction Variables: Variables that accumulate a value using operators like + or * (e.g., totalSum = totalSum + x). MATLAB handles the synchronization of these values automatically.
• Temporary Variables: Variables created and used only within a single iteration.

Limitations and Common Pitfalls

The Overhead Trap

Parallelization is not free. The time taken to start the pool, partition the data, and communicate results back to the client can exceed the time saved. If your loop body executes in milliseconds, a parfor loop will likely be slower than a standard for loop.

State and Randomness

Workers are independent MATLAB processes. This leads to two critical issues:

1. Persistent Variables: Variables declared as persistent or global are not shared across workers. Each worker maintains its own local version, meaning updates in one worker are invisible to others.
2. Random Number Generation: By default, workers may initialize their random number generators with the same seed, leading to identical results across iterations. To avoid this, use the rng function inside the loop with a seed based on the worker ID or the loop index.

Illegal Array Growth

You cannot dynamically grow an array inside a parfor loop. For example, results(end+1) = val will trigger a runtime error because the workers cannot coordinate the size of the array in real-time. Always preallocate your arrays before the loop.

Verification and Diagnostics

To verify that your code is actually running in parallel and not falling back to serial execution, use the MATLAB Profiler:

1. Run profile on before the loop.
2. Execute the parfor block.
3. Run profile viewer.

In the viewer, check the execution time of the loop. If the "Self Time" is distributed across multiple workers and the total elapsed time is lower than a serial run, the parallelization is successful.

Rollback: To return to serial execution for debugging or compatibility, simply change parfor to for. No other state changes are required as the parallel pool remains dormant until called.