Accelerating MATLAB Code with parfor: A Practical Task Guide

Desired Outcome

Convert a serial for loop that processes independent data into a parfor loop, enabling MATLAB to distribute iterations across multiple CPU cores or cluster nodes. The result is reduced wall‑clock time while keeping the algorithmic logic unchanged.

Prerequisites

• MATLAB R2018b or newer (parfor behavior is stable from R2020a onward).
• Parallel Computing Toolbox license.
• At least one available worker (core or node) – check parpool('local') output.
• Loop body must be free of cross‑iteration dependencies: no shared writes, no use of break, continue, or nested function handles that modify outer variables.
• Script or function must run with a user account that has permission to start and stop parallel pools.

Procedure

1. Verify Parallel Pool Availability
   Run the following in the Command Window to ensure a pool can be started:

   pool = parpool('local');
   fprintf('Pool started with %d workers.\n', pool.NumWorkers);
   

   If the command fails, check the license and that MATLAB can access the local or cluster resources.
2. Rewrite the Loop
   Replace the serial loop:

   for i = 1:n
       A(i) = compute(i);
   end

   with:

   parfor i = 1:n
       A(i) = compute(i);
   end

   Key points:
   • The loop variable i must be a simple integer index.
   • All outputs that depend on i must be sliced (e.g., A(i)).
   • Avoid writing to the same variable from multiple workers; if you need a shared variable, use a parallel.pool.DataQueue or parallel.pool.Constant instead.
3. Run the Script
   Execute the script normally. MATLAB will automatically distribute the iterations across the workers in the pool.
4. Optional: Inspect Worker Distribution
   Open the Parallel Pool dashboard via parallel.pool.DataQueue or use the labindex function inside the loop to print worker IDs for debugging:

   parfor i = 1:n
       fprintf('Iteration %d handled by worker %d\n', i, labindex);
       A(i) = compute(i);
   end

   The output will show which worker processed each iteration, confirming parallel execution.

Verification Checks

• After the loop finishes, confirm that parpool('local') still reports the pool as active. If the pool shuts down automatically, the loop ran serially.
• Check the Parallel Pool task log: in the MATLAB desktop, go to Parallel → Parallel Pool → Task Log. Look for any "unassigned iterations" warnings; these indicate a dependency issue.
• Profile the code with profile on; ...; profile viewer; to see the time spent in the loop body versus overhead.
• If you see a parfor error stating “Cannot use parfor with subscripted assignment to variable” or “parfor loop body contains a break statement”, revisit the loop body to eliminate the offending construct.

Common Pitfalls & Recovery Options

• Pool Not Started
  If the pool is not running, parfor throws: "Parallel pool has not been started."
  Recovery: Run parpool('local') manually, or add parpool('local', 4) at the top of the script to request four workers.
• Cross‑Iteration Dependencies
  Using a global variable or a persistent variable inside parfor can create hidden dependencies.
  Recovery: Replace globals with parallel.pool.Constant or restructure the algorithm to eliminate shared writes.
• Dynamic Array Growth
  Appending inside the loop (e.g., arr = [arr; newRow]) is not supported.
  Recovery: Preallocate the output array before the loop or use a sliced assignment like arr(i,:) = newRow.
• Using Plotting or GUI Commands
  Calls to plot or figure inside parfor can fail because workers have no display.
  Recovery: Move plotting code outside the loop or collect data in the loop and plot afterward.
• Performance Degradation
  If the loop body is very small, the overhead of distributing work may outweigh the speedup.
  Recovery: Combine several iterations into a single loop body or use parfeval for fine‑grained asynchronous execution.

Conclusion

Using parfor is a straightforward way to harness multi‑core or cluster resources for embarrassingly parallel workloads in MATLAB. By ensuring the loop body is independent, starting a parallel pool, and verifying worker usage, you can achieve significant runtime reductions. When issues arise, the recovery options above provide a systematic path to debug and refactor the code.