I was reading articles like this in the 70s, and alternatives being proposed ranged from content addressable memory to dataflow architectures and on. The answer is probably sitting in the IEEE archives somewhere, waiting to be re-invented.
The problem is not technical. It is a mental block provided by the panelists themselves. They even say it right in the article,
"One of our problems is how to parallelize existing programs with eight or 10 million lines of code--you can rewrite everything but it will cost a lot of money," Bachmutsky said.
Sorry boys, but a rewrite is required. The real and true problem of multicore is NOT that the programming is impossible, or even hard.
The problem is you can not throw the old crap on the new hardware and call it done. Everyone is searching for the silver bullet that lets us put the poor code, which has been tested into working, onto a multiprocessor system. There are no silver bullets.
Yes, this is costly. Yes this is difficult and error prone. Yes, you should have started the project 2 years ago. Better get started now!
I don't think 2 cores really give 2 times performance. Parallel programming is a monster that I don't think we have good way to deal with yet. To most products, multi-core is more or less a marketing tactic rather than a real technical advantage!
The problem is not really the data transfer speed of the connections. We know that there is an upper limit to speed dictated by physics. So there not much we can do about that. The problem has to do with bus contention, i.e., having multiple cores trying to access memory via a single bus at the same time.
Even the slowest connection speeds would not be so bad if we had a memory system that allowed tens or even thousands of cores to have simultaneous random read/write access to multiple data. This is an area that is crying for a breakthrough.
The memory bandwidth problem cited by Mapou is actually an interconnect problem. But shortening the interconnect distance would lead to heat dissipation problems. Perhaps embedded DRAM would be more helpful?
The multicore industry is in deep trouble and, as we know, they've known that this problem would mushroom into a major crisis for at least a decade. The people that are the most to blame for this sad state of affair are none other than the people whom we have entrusted to finding a solution: computer scientists. Why do I say this? Because the reason that we have a crisis is that the baby boomer geeks, who are still in charge of computer science, worship the Turing Computing Model as God's gift to humanity. But guess what? The TCM is the problem, not the solution. It is time for the old boomers to gracefully retire and let a new generation have their turn at the wheel. Sorry, you blew it, guys. Big Time.
It gets worse. Sure, the programming wall is breachable in principle; after all, the most complex computing system known, the brain, is inherently parallel. And the brain accomplishes its magic with extremely slow elementary processors and a very small energy footprint. There are several lessons to be learned here, I'm sure. However, there is another more formidable wall on the horizon and we are approaching it at high speeds. It's called the memory bandwidth problem: As the number of cores continue to increase, the memory bus bottleneck becomes intractable and destroys the performance benefits of having multiple cores.
I've been saying this for at least as long as Rick Merritt has been covering the multicore programming crisis. My advice to the industry is this. Realize that our current thread-based, Turing-inspired parallel computing model sucks. I know it and you know it. It's time for a radical change. The more you procrastinate, the worse it's going to get. Google (or Bing) "How to Solve the Parallel Programming Crisis" and do the right thing.
And please, stop wasting your money on the Turing worshipers and boomer geeks in general. It has not worked in all the years you've been doing it and it's not about to work any time soon. Telling it like I see it.
A Book For All Reasons Bernard Cole3 comments Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...