Parallel Image Processor

The experiment

Image filters are embarrassingly parallel: the work splits into pieces that never need to talk to each other. I compared two ways of splitting it with multiprocessing.Pool. Strip-based processing cuts one image into horizontal strips, one per core. Multi-image processing gives each core a whole image.

What I found

Strip-based processing was slower than sequential everywhere I tested it. Each strip is so little work that starting and coordinating processes costs more than the filtering. Multi-image processing beat sequential on Linux x86, because each worker gets a full, independent job and the fixed overhead is spread across more work.

Hardware changed the answer. On Apple Silicon, Python multiprocessing was less effective than on Linux x86, the architecture of clusters like Georgia Tech's PACE Phoenix. Amdahl's law sets the ceiling, and fixed overhead sets a floor no number of cores can get under.

Splitting into strips also has a visible cost: each strip is blurred without its neighbors' pixels, so a wide Gaussian blur shows seams where the strips meet. Overlapping each strip by the blur radius and cropping afterwards would remove them.