Monday, October 13, 2008

Wasted Cycles

As you might recall, Intel was quite happy when they were able to snag Apple into their camp. Formerly, Apple used processors manufactured by Motorola for their systems. I figured Intel was happy because of the uptick in sales, but in hindsight I think it was the fact that they were reaching the upper echelon of what kind of speed they could crank a CPU up to and they knew that it was only a matter of time before even a slouch like Motorola was able to catch up to them and negate Intel's speed advantage, such as it was. After all, there was a lot of truth to what Apple was saying at the time that the CPU speed isn't the be-all end-all. It doesn't really matter if your CPU is moving at 509 million gigahertz if your memory is stuck at 100Mhz since a computer is generally as fast as its slowest component.

But the speed game was great marketing. Who wants to talk about front side bus speed and PCI bus access rates when you can just slap a number on your product like "2.4Ghz". So Intel was happy to get Apple because work is so much easier when you don't have to, you know, work.

Intel though can't completely sit on it's laurels and it's substituted all that hard work that they put into speeding up their product for the lazy-out of cramming more identical CPUs onto the same form factor. Now when one goes to buy a product it's measured in 'cores', or the number of CPUs that have been baked onto the chip. Here's the nasty secret though: hardly anything uses multiple 'cores'. That's why some people experience a performance drop when they trade in their ancient 2.4Ghz PC for a 2Ghz multicore because the app(s) that they use most heavily isn't written to use more than one CPU.

I bring this up because MSDN magazine, Microsoft's organ for Microsoft programmers, has been running a series of articles on coding to multi-core systems. It's in Microsoft's interest to push this skill set since no one is going to buy a new PC with new M$ software on it if they're going to get worse performance. This brings up the other nasty secret: writing multi-threaded apps sucks.

Reading about programming in general isn't the most uplifting topic, but reading about multi-threading may be the most boring thing I have ever read, ever. It's like listening to a bug doctor talk about the different kinds of dirt that can accumulate on the legs of ants: the topic is easily grasped by many, but cared about by exceedingly few. Add onto that the fact that writing multi-threaded apps is like having to teach someone to juggle correctly the first time they try by writing down the instructions and mailing them to the aspiring juggler. I found this quote over at MSDN that best summarizes the whole topic (emphasis me).
Anyway, back to the problem in hand. If you are seeing effects akin to thread sync issues in a multi-threaded program then it's very likely that there are thread sync issues. This is a problem with your application, not with Windows. It may be things like you aren't using memory barriers where needed so the processor cache isn't being flushed, or that you're missing or have incorrectly placed one or more critical sections, or any number of things. As I'm sure you're aware this is very difficult to debug...
The core issue, as it were, is that the main program has to farm out it's sub-functions to what is essentially a completely different computer. When will the 'separate computer' get back to the main program? Who knows!

Companies like Adobe, Autodesk and Microsoft have the skills and resources to code their high-end packages to take advantage of this functionality, but I still think it's a stretch for Microsoft to expect that the vast army of 3rd party programmers who write to Windows will be able to tackle multi-core programming when so much of what they write barely works on one.

No comments: