The need for new software development models suitable to the parallel processing environments of multicore chips is growing more acute, with both Intel and AMD lending support to find a solution, fast.
Words like "critical problem" and "panic" are starting to turn up when experts are asked about the issue, which centers on the fact that even business-critical software is likely to see significant performance degradation in the coming years if they can't adequately exploit multicore's ability to divide workloads across multiple CPUs.
Last month, Intel and Microsoft ponied up $10 million to the Parallel Computing Lab at UC Berkley, with AMD donating one of its chief architects, Chuck Moore, to the lab full-time. The lab will concentrate on developing a model for higher-level multicores, rather than the typical 8- and 16-core models due out in the next year or so.
AMD has also joined forces with Topcoder to establish quarterly competitions to solicit winning parallel programming designs. Multicore Threadfest will offer cash prizes ranging from $250 to $2,500.
AMD has also opened up some of its source code in an effort to foster enhanced media applications for its multicores. The AMD Performance Library, which has been redubbed Framewave, is available on SourceForge.net. The idea is to let programmers customize their software for multicore environments using Linux, Windows and Solaris compilers.
The multicore future also has the wizards at Microsoft toying with the idea of a completely new operating environment. That's right, a non-Windows OS. The company is already working toward optimizing its experimental Singularity OS -- currently a set of tools and libraries available for research licenses -- to multicore environments, most likely by allowing multiple kernels to run on multiple cores.
One of the main design challenges for multicores is the fact that one size does not fit all. Developers are finding out that what works for a two- or four-core system tends to break down as more cores are added. Intel's James Reinders suggests here that the use of abstractions like libraries, Open MP or the Threading Building Blocks (TBB) system will work better than programming directly to raw threads, particularly as new chips begin to use cores running at different speeds.
That both hardware and software vendors recognize that a lack of parallel programming is such a serious problem is a strong indication that end users will likely be spared some of the worst-case scenarios as multicores spread throughout the enterprise. But time is growing short, and it would be a shame if performance does start to suffer simply because someone dropped the ball.