I recently spoke at the ACCU ("Association of C and C++ Users") Conference in the UK, with the title of my talk being "Seven Tips To Help Get You Started on Multicore".The first tip was 'don't fix what works', the point being that if you have an application that already runs fast enough and there is no business case for making it faster, then don't invest the time implementing parallelism.

When I next do such an event I'm going to add an additional point "If it works -- use it". My thought being that if you have a technique that makes your application run faster you should use it -- even if the solution is not perfect.

I've just read a paper that discussed the performance gains when using two compiler optimisation switches - O2 and O3. The paper showed that by fiddling with the environment and link order, you could make either O2 or O3 produce the faster code for the given application. The implication was that some benchmarks can be turned upside down by altering some variable of the system or build environment.

It would be easy to use such observations to become skeptical of any benchmarks, worse still, you could stop doing any optimisation work at all. When we get to this point, we have lost the plot!

It's easy to get to what I call a 'relegious position' on such matters. (If you don't know what I mean, try talking to a LINUX developer about the benefit of using Windows -- or vice versa).

Surely if my application in a given environment runs faster, then I should take advantage of that. "If it works -- use it!".