Hacker News Reader

Comment by Mapou | Hacker News Reader

Yeah, but this is a different ball game. The big players have an Achilles' heel. They are clueless as to what the future holds for multicore processors and they don't seem close to a solution. Parallel programming is a pain in the ass. There is even panic in the air because the big vendors have no real idea how to proceed. The solution is out there though. Some unknown startup may sneak behind them and steal the pot of gold while they're busy fighting amongst themselves.

View on HN

Anything is possible, but so far the flying car and parallel programming startups have all failed :). (Moller and Peakstream come to mind)

Which parallel programming startups are you referring to? Sure, the established companies are adapting their exisiting tools to address the new multicore processors but I am not aware of any new parallel programming tools startups that failed. Most of the multicore processor startups are still around. Tilera, Ambric, Pico, etc... are still hanging in there. Pico is doing great. Israel's Plurality is just now beginning to get recognition for its self-balancing 64 to 256-core hypercore chip.

My point is that there are very few new multicore startups and I think that the reason is not that too many of them failed in the past but that only a few have had anything really interesting or disruptive to offer. It remains that there is a big problem that needs to be solved right now and whoever solves it will grab a lion share of the CPU market in this century.

To what end? What specific value add is a multicore processor to mom and pop that is not being addressed by an intel quad core? The only thing that moves units is applications. As far as the general user is concerned, the processor does not exist. And that is how it should be.

Are you kidding me? Once cheap massive parallelism becomes the norm, you're going to see amazing applications for the average person, especially intelligent programs. For examples, intelligent answering systems, voice recognition, handwriting recognition, face recognition, dog walker, housekeeping robots, portable language translators, self-driving vehicles, sentries, etc... The possibilities are endless.

All of those things are already with us. The problem with those things are in the algorithm performance, not compute cycles.

Peakstream may not have reached their "peak" but they were bought by Google for an undisclosed sum, which was probably good timing given that larger players are now entering that field.

http://arstechnica.com/news.ars/post/20070605-google-buys-pe...

I don't know all the specifics, but I doubt that was a "successful" exit.

Wasn't peakstream just a quick flip of the stanford brook gpu research?

http://arstechnica.com/news.ars/post/20060918-7763.html

The new company is entering the public eye with $17 million in funding and a leadership roster that includes former executives and tech guys from Sun, VMWare, NVIDIA, and NetApp. PeakStream's Chief Scientist is Prof. Pat Hanrahan of Stanford, who was formerly involved with Stanford's stream processing research endeavor, the Brook project. The Brook project's work on using GPUs as stream processors formed the foundation on which PeakStream has built their newly announced product.

"Parallel programming is a pain in the ass."

Eh, it is really not that bad.

Depends on the tools... it's usually done in C or C++ with low-level locking primitives and that can be pretty tricky to make efficient. You can easily write code that's correct and slow, or fast and error-prone.

IMO there's a lot of room for improvement on the tools side. I don't think a new architecture is needed/warranted given the improvement we could get just from better programming models and tools.

Reply on news.ycombinator.com