Excellent article. One day soon, the computer industry will realize that, 150 years after Charles Babbage invented the concept of a general purpose sequential computer, it is time to reinvent the computer as we know it. AMD and Intel are in big trouble and they know it. Programmers are having a hell of a hard time writing multithreaded applications that can take advantage of parallel cores. Threads were never intended to be the basis of a parallel programming model but as a mechanism to execute multiple sequential programs concurrently. To find out why multithreading is not part of the future of computing read 'Nightmare on Core Street' at the link below:

http://rebelscience.blogspot.com/2008/03/nightmare-on-core-street.html

What is being ignored is Amdahl's rule. We have very high capacity CPUs, large memory, but the I/O speed to disks is becoming a major bottleneck to speed. While disk capacity climbs to mthe terabyte range, the capacity to move data on and off the disk has not kept up.

Ever wonder why your PC's CPU is four or five times the speed of your old one, has four times the RAM, yet still takes two or three minutes to boot? Look at your C-drive's I/O queue length! Everything is stacked up waiting for the disk heads to move.

This is nothing new. Hardware has ALWAYS outpaced software in the Computer Industry. We were using 10-processor Unix boxes in the eighties (circa 1986) in many Engineering Colleges. This was called Massive Parallel Processing (MPP). Then we started moving to clustering separate compute machines. Now it looks like it is back to MPP, the only difference is that the processors are now on the same substrate. However, writing software for these mult-core chips is the SAME as it was in the 1980s. System Engineers can easily write code (i.e. OSes,DeviceDrivers...) to take advantage of mult-core hardware, usually with well established C code. It's the new breed of Object-Oriented Programmers (i.e. C++,Java,.Net,Ruby) that are going to have headaches re-writing their bloated inefficient APPLICATIONS to properly utilized the underlying OS services, mainly provided by high-performance C code. OOP apps are typically poorly written apps that don't have a clue about the underlying hardware.

It is something new. Those Unix boxes with 10 processors in 1986 cost a big chunk of change. I can buy a 16-core box, loaded with memory and a few disks for around $10K today. Multicore has moved to the masses.

Given "massive" parallelism has moved to the masses, software needs to catch up. Not everyone can write multi-threaded code in C. Threads are really the wrong paradigm. At Pervasive, we're working on a framework for building parallel data processing applications. It takes a totally different approach to building parallel applications. Being dataflow based, problem decomposition is data oriented.

Check it out at http://www.pervasivedatarush.com and let me know what you think.

This article takes a very very simplified view of what is happening in computing with respect to multicore today. You cannot seriously say that multicore is a disruptive play that can displace an Intel or AMD or IBM -- it is disruptive for SOFTWARE, but a very natural continuation for hardware. The resources needed to design and build multicore devices with high performance means that mostly our current incumbents will be able to do that reliably.

On the software side, however, things are harder. And the easy place

Note that there are several ways to take advantage of a multicore device:

* You can run a large set of independent tasks that already exist with improved efficiency. There is no attempt to scale peak performance here, only to enhance system throughput. This is where the parallelism of IO that Psat noted comes in. I have noticed the same thing: http://jakob.engbloms.se/archives/36

* You can use a multicore device as a substitute for a set of existing discrete processors, and run it in asymmetric mode with several operating system instances on the same chip. This lets you consolidate hardware, and is a very popular use of current multicore devices in the embedded space.

* You can try to use all cores at the same time on the same problem, which is what RapidMind is looking into doing.

In the first two cases, a very important problem is just how to debug legacy code and make sure it actually works in a truly concurrent world. Which is not a given. See http://www.embedded.com/columns/technicalinsights/183701679?_requestid=171089 for some examples.

Most of the parallel code we will use on a daily basis will not be new code written to take advantage of parallel hardware to solve "large" computational/data processing problems, but rather decision, control systems, and user-interface code that is mostly ported from existing uniprocessor environments. Written in a mix of assembler, C, C++, Java, Python, Perl, Basic, Prolog, Cobol, etc (and custom languages).

Multi-core computing is more important to the operating system running many applications, the typical software engineer doesn't care. We developers rarely need concurrency. A few of us write Monte-Carlo simulations, a few of us make image processing applications, but concurrency is a niche requirement on the desktop reflected by the niche tools that are already available to us. I enjoyed my Concurrent Programming Techniques module that I took fifteen year ago, maybe it would have been useful if I'd written compilers and operating systems.

"I can buy a 16-core box, loaded with memory and a few disks for around $10K today. Multicore has moved to the masses."

Depends on your terms. Who are the masses with the 16 core processors you are going to be programming for?

A year old MacBook only has a dual processor. Most consumers, ie. masses will not be spending $10K in the next few years for computers.

Are you talking about entertainment systems where multiprocessors will do well for processing graphics?

Are you talking about enterprises where you have sixteen virtual machines running on a single server?

The reason the problem has not been properly addressed yet is because the problem has not been properly defined yet.

When you settle on a design that sells for a thousand bucks a system, not ten thousand, then you will have a target to shoot for. Other than that, it is all an academic exercise, or specialized government project, like weather prediction.

There once was a tiny OS called BeOS that handled an 8 processor Xeon server better than anything that I have ever seen still.... I wonder what happened to that tiny OS......

It is amazing to me that anyone would have been surprised to see multi-core/multi-CPU systems on the desktop. They knew it was coming in the 70's, 80's and 90's. Low and behold it is here now. Big problems have always needed this type of power but the desktops been able to get by. Not that the applications on the desktop really need it now but it sure is nice.

An aside from this and related of course is the the happy migration back to specialized processors all residing in one system or even on one piece of substrate. So it is not just multiple of the same CPU but of heterogeneous types be it DSP SPU CPU GPU PPU or some other acronym.

It would have been nice to see Universities being more proactive on this. People really need to think about problems in parallel terms. The market really determines the need though. Quick and dirty sequential applications on really powerful single processors always seem to win out over elegant concurrent designs... such is life!