waffle

A good bit of what I learned about Grand Central Dispatch, I learned from Mike Ash’s excellent Friday Q&A series. The latest installment highlights some real world problems you may come across when trying to apply task parallelization in the wrong way. He demonstrates with a fairly representative example that won’t be so easily mechanically transformed into going faster because the obvious way of doing so moves the bottleneck to a place where it, along with the good intentions of every other part of the system, actually floods it in a horrible way.

The problem with parallelization is fundamentally that we have to think beyond what we did before because of the discrepancy between new facts and old assumptions, and that extends not only to keeping locks and concurrency in check but to figure out what sort of load you’re putting the rest of the system under when you’re being more efficient with execution. Even a good solution with a wide scope won’t insulate you from the pre-existing architecture, pre-existing code and your pre-existing assumptions and approach. There are formulas that you can use (I’m seeing where I can change a @synchronized to pushing the work into a dedicated dispatch queue, asynchronously or not, for example, because that code often runs in its own thread) but you shouldn’t ever let them excuse you from finding out the full picture so that you may see everything in context.

We may finally be headed towards the right tools to tame the right hardware. Let’s put ourselves in the right mindset, too.