Multi-core processors and GPGPUs (general purpose graphics processor units) now have an extremely high profile. Intel, AMD, IBM and others have, in effect, declared that processor architectures cannot be run at faster clock speeds. We are now told to use more cores to achieve greater performance.

In areas such as high-performance computing (HPC) and web services, parallelism has been employed for many years. The programs are often highly customised or embarrassingly parallel; broadly the algorithms are straightforwardly cast as parallel programs that can use as many cores as are available. So, in these cases, more cores means more performance. However, given that manufacturers are aiming to support all applications (and users), not just the HPC and web services, there is a problem: desktop systems and their users. Some might say, the real world!

End-users themselves mostly couldn't care less what processor runs their application, provided that the details are hidden from them. What is important is that their office system works faster or that they have better access to the latest social networking site. Here is the nub of the problem, it is not clear that more cores will actually make present office systems go faster. Faster processors did, as do faster disks, but more cores probably make very little difference because most office applications are not programmed with a parallel platform in mind.

Until all the applications that end-users use are rewritten to work properly with parallel hardware, users will have a problem, they may not benefit from the new technology no matter how many more cores they have.

So who is this a problem for?

Almost all software technology has lagged significantly behind the hardware advances of the past decade or so. Programs that we rely on, such as word processors and spreadsheets, presume single processor models of programming, even in the brave new world of parallelism. Although you may have a dual- or quad-core processor in your laptop or desktop, end user applications makes little or no use of the extra processing capability. The cores are available to the operating system which can run multiple applications at the same time, but this does not improve the performance of an individual application. How can applications developers make use of multiple cores in a single application? The current hope is thread pooling. Operating systems such as Linux and Solaris offer lightweight threads that can harness the power of multicore systems. However this is a low-level approach and leads to highly platform-specific code. Java, with its JVM, has re-energized the virtual machine approach. The virtual machine hides the details of the particular platform's approach to parallelism, but the underlying model remains a set of threads using shared memory. While Java is often claimed to "give parallelism for free" (web services people often claim this), there are limitations. In particular, if threads need to synchronise then there may (or may not) be problems. Embarrassingly-parallel applications rarely have this problem, which is why many web services people don't appreciate what the problem is. Unfortunately, there are currently very few programmers who can correctly program parallel applications when they have real synchronisation issues using threads. This either means a bonanza for the training companies, or a new way of programming these systems is needed.

So, is this scaremongering? No, there is a problem because you no longer have a choice—you will have multicore machines. The industry must start to adapt to the new technologies. The industry itself, research institutes and others need to make big efforts to develop technologies to let end-user applications properly exploit multi-core systems. As importantly, our academic institutions and training companies must start training current and would-be programmers to exploit the new technologies well.

This represents a massive challenge for the likes of Microsoft, Apple, the Linux community, and indeed anyone else who would write an operating platform for the brave new world. Applications development requires platforms that deliver seamless interfaces to multi-core processors, not just for four but for the many, many more cores that the manufacturer's roadmaps indicate are only a short distance into the future.

The best way to achieve the platforms that are needed might be for those developing tools and technologies to exploit multi-cores to place the results of their work into the public domain as open software with the intention of accelerating development. Some hope? Perhaps, but the major operating system vendors have had thirty to forty years to get where they are now. The industry has to find a workable, and common, solution in the next few years. The timescale really is very short. That doesn't mean that, say, Excel will find its way into the public domain but that a common interface and platform will have to appear to allow these bread-and-butter applications to run on the rapidly growing core count. Once the platform has evolved then letting "The Community" at initial implementations would probably represent the fastest and best way to a solution. Or it might just come from left-field…