Jeff Atwood, of Coding Horror, says that "the benefits of moving to quad core and beyond are less clear." He produces some numbers to reveal that many of today's processor-intensive applications (media, gaming, databases, etc.) are not multithreaded and, therefore, do not run significantly faster on multicore machines. He observes that the infrastructure (OS, disk subsystem, etc.) can automatically get a significant benefit from a second core but then might have a hard time finding stuff to keep it busy with 4 cores and, by the time we get to 8, there will be little "free lunch" performance gain from increasing cores.
So far, he's dead on: your 2005 software suite will not run much faster on your 2012 32-core Dual-Dos-Double-Zwei-Core-Two chip. The multicore era (2-4 cores) will show infrastructure benefits. The manycore era (8+ cores) will require application support.
He then describes the task of making your program utilize manycores as "Rewrite your entire application in a new language aggressive....It's also not a common optimization, except within very specific application niches." While I agree that this is true today, it cannot hold true in the manycore era. All performance-related programming in the manycore era will require concurrent programming.
Today, the benefit of multithreading is either negative a few percent or, on a dual-core system, a gain of perhaps 70%. So it's reasonable not to bother, especially since multithreaded programming in mainstream languages is today where memory management was about twelve years ago: an error-prone, manual process involving low-level abstractions. But look at the speedups to be gained from multithreading as we move into the manycore era:
Cores
1
2
4
8
16
32
::: {align="center"} Multicore :::
::: {align="center"} Manycore :::
Yr. of common availability
2006
2008?
2010?
2012?
Application speed
(Assumes 70% utilization of additional cores)
1
1.7
3 (?)
6 (?)
11 (?)
23 (?)
There is simply no way that any professional can ignore that.
And as a professional, now is the time to learn those skills. In no more than a few years, multithreaded programming is going to be the central issue of performance. No mainstream language is automatically parallelizable. No automatically parallelizable language is close to being embraced by the mainstream.
Wake up and smell the cores: the mainstream is going to get hit by the manycore era like a tsunami. Those who are prepared will prosper. Those who are not prepared will feel like COBOL programmers in 2001.
P.S. If you aren't a regular reader and you see the OpenMP post below, you might think that I'm saying that's a silver bullet. Heck no. A parallel loop isn't going to help Ted Stevens get his Internets through the tubes any faster or, more to the point, overcome disk contention, memory locks, cache corruption, etc. But the systems programmers and hardware manufacturers (e.g., disk drives) won't be able to ignore the manycore era either. Essentially, the whole dang box is going to have to be re-engineered for manycores. This is why Vista has put Microsoft on the edge of a precipice: they lost years in the undoubtedly-painful process of refactoring Windows so that it stood a fighting chance to be put together anew in the manycore era. They said that Vista was a "bet the company" gamble and while that was always hyperbole, it's not a lock that the mainstream OS for the manycore era will be Windows.