Archive for October 6th, 2006

Multicore CPUs and software

Friday, October 6th, 2006

Everybody’s talking now about multicore CPUs - it is the new hype. Once it was the race for MHz, some other time was GPUs and SLI, now it is more cores in a single package. The idea of having more than one CPUs in the same box is not new. Both Intel and AMD, as well as IBM and a few others had products for parallel processing and multiprocessor systems. Also, many system manufacturers had their lines of products - just think of DEC (RIP), NEC, Cray, SGI and many others.

However, the Intel Core Duo made multiprocessing mainstream. Now everyone can buy one chip and have two processors - multiprocessor systems tend to be somewhat more expensive that multicore systems, because the former often need separate memory for the processors, require more power (thus more expensive power supplies) and never became mainstream. Now, with the Core Duos and AMD’s Athlon64 X2s, anyone can have two processors in his box.

This step wasn’t sudden at all: HyperThreading was a first rough form of multicore CPUs, and the Core Duo was the next evolutionary step. However, the (r)evolution is incomplete: we don’t have the software to fully exploit multicore CPUs. The majority of mainstream software is written with one processor in mind, even if it uses threads: most software uses threads to handle the slow I/O rather than splitting computations across different threads. Even games are optimized to run on one processor. Additionaly, a lot of existing algorithms have been designed to work in a centralized environment and not on a parallel or a distributed one.

Writing efficient parallel programs is a real pain: there are many portability issues (although POSIX threads are a very good step towards portability), there aren’t any good tools for developing quickly parallel applications and there is just too much software out there that is not written having in mind more than one processors. However this applies for desktop applications and normal users, since laboratories, research institutes and companies across the globe have already parallel applications for calculating whatever they need.
There are a few attempts to standardize parallel programming (for example I am working in parasol labs of the CS dept. in TAMU on STAPL, an STL-like framework that supports parallel and processing) but they are just now being developed and it will take a while before everyone adopts them.
Up until now, we could fully exploit the dual core CPUs. Everyone runs a bunch of daemons (services in Windows) and some applications the same time. However, even a modest 2GHz CPU was enough for all these, the dual core CPUs just gave us some speedup. But what will happen if the new 4-core or 8-core CPUs will come out? Who - and how - will use the additional cores? And for how many cores would you optimize your software - for 1-core tablet PCs, 2-core laptops, 4-core desktops or 8-core dream machines?

Having a lot of threads would be an overkill for 1-core or 2-core CPUs, having too little would waste the other cores. And how is the multicore implemented? How much does the communication cost between threads? All those must lie in the back of software developers’ minds - and there is no tool to take care of it.

The bottom line is that the hardware leads the way and software is the last to follow: since we cannot stop the progress of hardware, we have to develop more efficient software.