Essential Linkage: Inherent coding restrictions holding back performance.
Every enthusiast either already has or wants a fast dual/quad core processor, simply for the speed that they offer, but is there a limit to that speed? Can more cores just be whacked in there to give better performance every time?
The Multicore Expo presentations didn't think so, and there's many valid reasons why, the most important one being that most software was coded for a single core.
It's true that many programs have been patched to include support for more than one core (see Team Fortress 2 for a good example), and while this does improve performance it isn't truly multithreaded - just a splitting up of the single-threaded tasks between the cores.
This means that one core will do the physics and AI, while another will coordinate the display driver info and the sound. There's nothing wrong with it, and it's an easier way than recoding all the software, but you hit a point when you have more cores than you do single threads to shuffle about - and hit a wall.
Large amounts of cores (such as Intel's upcoming 8-core Nehalem chip) have previously been the sole domain of servers, but they're moving into the desktop space, and performance benefits are not going to be realised fully unless developers put more effort into their code.
Infoworld takes a closer look at this, but for those programs that we want to run faster (games, operating systems, encoding) we'll definitely want to see an improvement in code, or we might as well stick with what we have now.
Issue: 107 | December, 2009