I’ve been mulling over what to choose for my last session, and concluded I have a lot of interesting material on writing fast code. So I’m rolling my session “The Forgotten Parallelism” into a two-part talk on writing faster code.

I’m going to open with a section entitled The Art of Benchmarking. Many of us, me included, have been guilty of predicting or even estimating performance behavior of different constructs by using intuition. This shortcut is a natural reaction to the complexity of today’s computing architectures, and, just like many shortcuts taken in evaluating complex environments, is often difficult to generalize, misleading, or plain wrong.

As intuition is often useless, measuring is a vastly superior alternative. However, that approach has its own secret ingredients that are difficult to master. Too often code that’s supposed to benchmark some piece of code ends up measuring some irrelevant ancillary work (such as setting things up, looping, calling functions indirectly, or massaging and printing results). So benchmarking must systematically account for and compensate extraneous influences. Which brings us to choosing appropriate baselines. Good baselines are utterly important in measuring anything. It’s actually surprising how often benchmarks compare apples with oranges, or simply only show results for one brand of apples without providing reference points to assess whether one is better than the other.

So much about benchmarking. We’ll then dedicate some time to general approaches to speed optimization, with an emphasis on understanding the underlying dynamics (computation vs. data, straight-line code vs. control flow, semantics-preserving code transformation). And, as mentioned, “The Forgotten Parallelism” will become an integrated topic within this two-part session.

I should remind you all that registration is closing on August 1st. That’s next Wednesday! There are only a few seats left, so if you’ve considered joining, it’s time to make a decision.

See you soon, and happy coding. Well and happy benchmarking. Well and happy optimizing. And then happy benchmarking again. And… you catch my drift.