"
Why take such a gamble? In short, because there wasn't much of an alternative."
It doesn't get much truer than this. It's also something we talked about in brief a
couple of months ago, thanks to an Ars Technica article that was published.
I like this paragraph in particular from the IEEE article:
"
One of the biggest factors, though, is the degree of motivation. In the past, programmers could just wait for transistors to get smaller and faster, allowing microprocessors to become more powerful. So programs would run faster without any new programming effort, which was a big disincentive to anyone tempted to pioneer ways to write parallel code. The La-Z-Boy era of program performance is now officially over, so programmers who care about performance must get up off their recliners and start making their programs parallel."
It's true, and that's the reason a LOT of software is not coded for parallel execution... not even some of the flagship programs from monolith companies. On the other hand, companies like Autodesk have had good multi-threaded capabilities in their applications for a while. Before multi-core CPU's, programs like 3ds Max could take advantage of multiple PC's networked together. I believe the same technique is still used by movie studios, where a single frame in a movie could take a day or more on a regular PC.
I'm not sure of the solution we need, and everytime I try to think about, I get a headache. I still don't fault the processor vendors for making this move though, because it
had to happen. Once the world IS multi-core aware, we're sure not going to look back and be pissed off at the direction we took.
Great article though. Bookmarked because I plan to read through again in the future, especially since I feel like we're long overdue for tackling the same kind of article. I wish I was a programmer so I could better understand all the real issues.
return 0;
