Who will be the Microsoft of multicore?
Giving the keynote address at the Multicore Expo in Santa Clara Tuesday (March 27), Anant Agarwal, professor at the Massachusetts Institute of Technology (MIT) spoke about how multicore computers will reshape computing. Agarwal characterized the growth of multicore computing:
"Multicore has really crashed the computing party," Agarwal said. While today's multicore systems may have 2 to 16 cores, he said, cores will range into the hundreds within the next two to three years and reach 1,000 early in the next decade. There are three critical questions, he said --- how we size resources, how we connect cores, and how programming must evolve if multicore is to succeed.
If you're interested in resource sizing or connections, you can read the article in EE Times. What caught my eye was the discussion of how programming will change.
Agarwal likened the state of multiprogramming tools to the state of ASIC design tools in the 1980's. When I was a grad student in the late 80's I took several classes in parallel and distributed programming. We thought it would be the next big thing. Of course the Internet came along and parallel programming has had to wait for the appearance of multicore chips to really gain traction, but there's no denying its time has come.
The conventional wisdom for handling multicore programming is threads. And they do work pretty well when the number of cores if small. But what happens when chips regularly have 512 cores? Can we keep them all busy with threads? Agarwal agrees that Pthreads (POSIX threads) work in the short term, but he argues that they offer no encapsulation or modularity. He also dismisses direct memory access (DMA) and message passing interface (MPI) as too inefficient.
A better solution, according to Agarwal, is a streaming model where data is streamed from one compute unit to another. Hardware designers have used this model for years, so there's plenty of experience in how it works. It's also conceptually similar to sockets, so programmers have at least a little experience with it. But we're not used to building fine-grained processing units connected by sockets and we don't have great abstractions in current languages for doing so.
The dearth of tools supporting large-scale multiprogramming provides new opportunities for companies to step in an fill the void. Agarwal asks "Who will be the Microsoft, the Cadence, or Synopsys of multicore?" Maybe it's time for Ed Ashcroft and Bill Wadge to bring back the Lucid programming language?