Last week's acquisition of PeakStream by Google is still reverberating in the tech world.  IT watchers have offered various explanations as to why the Internet giant bought a tiny company that develops stream computing technology for high performance, multicore processors.  I chimed in with my own speculations last week. Theories for the acquisition usually revolved around Google's use of multicore technology to expand their Internet empire. The company's scaled-out computing infrastructure will surely be dependent on multicore hardware, so why not own some technology that exploits that kind of architecture in a novel way?

But let's face it -- even if Google uses the PeakStream stream computing technology to accelerate its own Web applications, it still seems a bit odd for a company that develops Internet software to be interested in owning a particular development platform. Then again, Google is an unusual IT company. Even though its main products are search engines, multimedia aggregators and web tools, Google also builds and maintains its own cyberinfrastructure. Rather than buying systems from cluster vendors, the company rolls its own from commodity x86 boards and Ethernet components (although of late it has become more secretive about this). So far this approach has worked out well for the Internet giant. It boasts one of the most efficient and robust distributed computing environments in the world. The inclusion of PeakStream may be just another manifestation of Google's inclination to control the means to its Internet ends.

However, a more logical buyer of a PeakStream's multicore programming platform would have been Microsoft. Now that's a company with a direct interest in multicore software technology. Essentially all of the processor  targets for Microsoft software are now multicore. And not only does Microsoft sell its own software development platforms, it also writes operating systems and applications. The hardware-agnostic PeakStream technology would appear to be a perfect fit for a software company that wants to incorporate multicore technology at every level of its offerings. The fact that Microsoft is now in the HPC business would have made a PeakStream acquisition that much more logical. If I were in a cynical mood, I might suggest that Google spirited away PeakStream to prevent Microsoft from getting it.

One thing is certain. The PeakStream acquisition focused some attention on their former rival, RapidMind Inc., a company that offers a very similar type of stream computing platform. RapidMind's product debuted in May, seven months after PeakStream delivered its first version. Ray DePaul, president and CEO of RapidMind, talked to me about his thoughts on the Google-PeakStream deal and what it might mean to his company.

Naturally, he was pleased that stream computing was getting some free publicity because of the acquisition. "This is a real validation of what's possible with this type of technology," said DePaul. "Anyone who looks at Google as a threat, a mentor or a technology leader should be a little concerned that they just leapfrogged everyone yet again."

But according to DePaul, RapidMind was less of a direct competitor with PeakStream than what has been portrayed in the press. He maintains that their customer base and plans for their product evolution is independent of what PeakStream was doing. Nevertheless, DePaul admitted that a handful of former PeakStream customers have already approached his company. Since RapidMind actually supports a broader array of target processors than PeakStream did, presumably the customer base can switch platforms fairly easily should they choose to do so.

DePaul maintains the real challenge for them was (and is) overcoming the resistance to using a high-level solution for performance-sensitive applications. Both PeakStream and RapidMind had to convince potential customers that their stream computing approach was the best way forward for multicore programming, not just because it was easier to use, but also because a systems approach could exploit more parallelism than a manual implementation. "Our main competitor is companies that think they can tackle the multithreaded game in the traditional way," said DePaul. "The in-house do-it-yourselfer is what we have to sell against."

RapidMind even encountered some of this resistance in their engagement with IBM, when working with the Cell processor team. But the IBMers had to be impressed when the RapidMind platform beat out the Cell programmers on a renderer application run on a Cell blade. In this case, the RapidMind-generated solution was able to double the performance compared to a hand-coded version. If RapidMind is able to maintain that kind of performance edge across an array of applications and processor targets, users should flock to the company's platform.

As far as becoming an acquisition target themselves, DePaul expressed that he has no interest in going down that path. His goal is to support as many platforms and applications as possible with the RapidMind offering. Currently over a thousand developers are using their product and a number of firms are looking into licensing the RapidMind technology.

Said DePaul: "I'm focused on building a company, not getting acquired by somebody in the Valley."

-----

As always, comments about HPCwire are welcomed and encouraged. Write to me, Michael Feldman, at editor@hpcwire.com.