How do I improve my critical edge with threading?

In my job, I visit many development teams who are thinking about threading their application. Here are the questions I get asked most frequently. - Bob Kuhn, Intel

“How do I improve my critical edge with threading?”

Frequently I am ushered into the VPs office who looks across the table from me in dead seriousness and ask this. I say, “Tell me about your competition?” Listening I try to figure out if they are in a horse-race to deliver features or performance. Either way, they making the application faster will keep them ahead. I try to figure out if they are serial now whether there is something that would make their market elastic; something customers would pay nearly anything for. Going from a single processor on a board to quad dual or quad-quad processors, a factor of 10x or more, could change the rules of their game. Finally, I listen to whether the users are looking for productivity, or even creativity. Threading an application can make them either and anytime we reduce human costs for increased computer cost, it’s a pretty certain win.

“If the Woodcrest is faster core-to-core than Smithfield, why shouldn’t I wait until Mon Reve (ficticious processor name) comes out?”

Many developers are still hoping that we microprocessor manufacturers will invent an processor architecture that can go dramatically faster. That hasn’t been promised since RISC architectures and we see where that got us today, there aren’t new anymore. A change here is a little (but just a little) more likely than finding a fabrication process which uses dramatically less power. Power consumption increase as clock speed increases is what is driving us to Multi-Core, we just can’t change that. You will have to bite the bullet.

“We added threading to support sending file to the printer. It’s just that easy.”

Some can underestimate how much work there is to threading an application. I have seen a few applications where it IS easy, so it is worth a good look to see how easy it could be in this case. Usually the inherent parallelism jumps out of the application architects head after a couple of minutes of reflection. And, nearly always he is right, so it is always good to look closely at his hunch. Sometimes the architect has a parallel work alright but the parameters are not advantageous. There is not enough work or the work is too fine grain. The latter is easier to fix. The former is causes me to look outside that. The parallel work can be combined with or made thread-safe for parallel work outside that.

Read more at Intel Software Community Website