Speed‑Up Large Matrix Multiplications in MATLAB with parfor

Why Parallelizing Matrix Multiplications Matters

In many engineering workflows—signal processing, finite‑element analysis, machine learning—large matrix multiplications dominate runtime. A 10,000×10,000 matrix product can take minutes on a single core, making iterative algorithms or real‑time processing impractical. MATLAB’s Parallel Computing Toolbox (PCT) offers a lightweight way to split this work across multiple CPU cores using the parfor construct. The goal of this post is to show you how to turn a serial multiplication into a parallel one with minimal code changes, what speed‑ups to expect, and the pitfalls you need to guard against.

Getting Started: Verify PCT Availability

Before you can use parfor, confirm that the toolbox is installed and licensed. Run:

ver Parallel Computing Toolbox

If the toolbox is missing, the command will return an empty table and parfor will fall back to a serial loop. In that case, you must obtain the PCT license.

The Classic Matrix Product Example

Let’s create two random 10,000×10,000 matrices. The data size is roughly 800 MB each, so you’ll need a machine with at least 2 GB of RAM per worker to avoid swapping.

A = rand(10000);
B = rand(10000);

Measure serial performance:

tic;
C = A * B;
serialTime = toc;

Now enable a parallel pool with four workers:

parpool(4);   % Creates 4 workers on the local machine

We’ll use parfor to compute the product row‑by‑row, which is an embarrassingly parallel problem because each output row depends only on one input row of A and the entire matrix B.

tic;
parfor i = 1:size(A,1)
    Cpar(i,:) = A(i,:) * B;
end
parallelTime = toc;

Finally, compare the two timings:

fprintf('Serial time: %.2f s\n', serialTime);
fprintf('Parallel time: %.2f s\n', parallelTime);
fprintf('Speed‑up: %.2fx\n', serialTime / parallelTime);

On a typical quad‑core laptop with hyper‑threading disabled, you should see a speed‑up between 2× and 3×. The exact figure depends on memory bandwidth and CPU cache behavior. If the parallel time is higher, check that each worker has enough memory and that the data transfer overhead isn’t dominating.

What Happens Under the Hood?

• Data partitioning: PCT automatically slices the loop index range (1:10,000) into blocks and assigns each block to a worker.
• Variable handling: Variables that are read‑only in the loop (here A and B) are sent to each worker once. The output array Cpar is built incrementally by each worker and assembled back into the base workspace.
• Communication overhead: For very small loops, the cost of distributing work and gathering results can outweigh the computational benefit. That’s why the example uses a 10,000‑row loop.

Trade‑offs and Limitations

1. Memory Footprint: Each worker holds a copy of the read‑only inputs. With 10,000×10,000 matrices, each worker needs ~800 MB, so a 4‑worker pool requires ~3.2 GB plus overhead. Swap or crashes can occur if RAM is insufficient.
2. Debugging Complexity: Breakpoints inside a parfor only pause the current worker. MATLAB offers a special debugging mode, but you can only inspect one worker at a time. Use dbstop if error and print statements to trace issues.
3. License Requirement: PCT is a separate license. If you don’t have it, the code will run serially and you’ll see a warning that parfor fell back to for.
4. Heterogeneous Environments: The example assumes a homogeneous local cluster. Remote or GPU clusters need additional configuration (e.g., parpool('remote',4) or parpool('local',4) with a remote cluster profile).
5. Non‑Embarrassingly Parallel Work: If your algorithm has data dependencies across loop iterations, parfor may not be applicable or may require restructuring.

Practical Checklist Before You Run

• Verify PCT license: ver Parallel Computing Toolbox.
• Ensure enough RAM: parpool('local',4) will fail if workers cannot allocate memory.
• Profile the serial version with profile viewer to confirm the multiplication is the bottleneck.
• Keep the loop body simple: avoid heavy function calls inside parfor that could increase overhead.
• After parallel execution, run memory to check for unused memory and close the pool if you’re done: delete(gcp('nocreate')).

Actionable Takeaway

If you’re stuck waiting for a large matrix product to finish, try the parfor pattern shown above. It requires only a few lines of code and works out of the box on any machine that has four or more CPU cores and the PCT license. Remember to monitor memory usage and be prepared to adjust the number of workers or split the data into smaller chunks if you hit swapping. Once you’ve validated the speed‑up, you can extend this approach to other linear algebra kernels—matrix‑vector products, solving linear systems, or even custom kernels that fit the row‑by‑row paradigm.

Happy parallelizing!