Google's interest in concurrent programming is no surprise -- indexing the Web involves a lot of parallelism -- but their \<a href="http://www.theregister.co.uk/2007/06/05/google_buys_peakstream/"" target="_blank" rel="noopener noreferrer">acquisition of Peakstream, developers of a low-level programming tool, is startling.
To quickly review: today's Graphics Processing Units (GPUs) are every bit as complex and powerful as the CPU. As opposed to mainstream CPUs, though, they are already highly parallel, with up to several dozen pipelines. I say "already" because highly parallel processing units is the future that awaits us all; it's one reason why I've been writing lots of articles about GPUs (the other reason being that graphics are hella' cool).
The trade-off for the high parallelism of GPUs is that they don't have anywhere near the flexibility of CPUs; the pipelines are quite rigid, with severe restrictions on memory access and code length. GPUs are architected to quickly perform matrix math on big parallel arrays (geometry and pixels), and for such tasks, they are blazingly fast. This graph shows the advantage of a GPU-based Mandelbrot set calculation I wrote.
A sufficiently motivated programmer with a highly parallel task can sometimes recast his problem so that it conforms to GPU architecture (arrays become textures, calculations become pixel coloring, etc.). This is what is known as "General Purpose GPU" (GPGPU) programming. Such recasting is difficult, especially across the broad ecosystem of GPUs, each with differing performance capabilities and characteristics. (For instance, that Mandelbrot shader I wrote exceeds the code length supported by my \$350-in-2006 graphics card.)
Peakstream is one of several companies that promises to make GPGPU programming easier. Since GPGPU is a fairly extreme task, it is no surprise that there are also academic and FOSS tools.
Last Fall, Peakstream started making PR noise. As soon as I saw their press release, I expressed interest in seeing their technology. I never heard back from them. They also nominated themselves for a Jolt Award. But, when asked to provide access to their technology so that we could, you know, evaluate it, we never heard back from them. At the time, I wrote them off as having put the PR cart in front of the technology horse. In retrospect, perhaps Google had already begun their acquisition inquiries.
One way or the other, the question of what Google is going to do with Peakstream's technology is fascinating. Are they going to use it as an internal advantage? What I don't get about that is: they're Google. My investigation of GPGPU libraries and tools was a major influence on my conclusion that there is no near-term "one size fits all" solution to concurrent programming -- the hardware is too demanding and too specific to be abstracted away. I am highly dubious that Google would trade a modicum of programming ease for a significant penalty in run-time performance. That's not how Google works.
My analysis of GPGPU is that the only thing that would really be worthwhile is a complete compiler chain. And not your CS201 "Introduction to Compilers" compiler, but a serious-voodoo compiler, with hardware-specific transforms, dynamic profiling, etc. If Peakstream had that (and the talent to put such a thing together), then I could imagine Google absorbing the company for internal use.
The other, more interesting, possibility is that they intend to offer Peakstream's technology to the masses. But while it's fair to say that Google has created a programming platform with APIs to their hosted services, a GPGPU tool is the furthest thing from a Web Service imaginable. GPGPU is as low-level as it gets: C-like languages are considered "high level" and the tools are binary libraries and compilers. These are the types of tools that one expects to come from Intel, AMD, and Nvidea. Why would Google get involved?
Perhaps the answer lies in that "already" that I threw out all those paragraphs ago. Whoever -- and I mean whoever -- figures out a way to get the mainstream through the manycore tsunami dictates the development platform for the 2010s. Maybe Google is interested in having a say.