EETimes: "Both AMD and Intel have said they will ship processors using a mix of X86 and graphics cores as early as next year, with core counts quickly rising to eight or more per chip. But software developers are still stuck with a mainly serial programming model that cannot easily take advantage of the new hardware.
Thus, there's little doubt the computer industry needs a new parallel-programming model to support these multicore processors. But just what that model will be, and when and how it will arrive, are still up in the air.
"It's a critical problem, and the technology is needed right now," said William Dally, a professor of computer science at Stanford. "The danger is we will not have a good model when we need it, and people will wind up creating a generation of difficult legacy code we will have to live with for a long time."
Dally said he would urge the industry "to start experimenting right away and try a dozen different ideas to find a few that work." Even then, he said, "the best ideas that emerge from that work won't be perfect in their first implementations."
"The industry is in a little bit of a panic about how to program multicore processors, especially heterogeneous ones," said Chuck Moore, a senior fellow at AMD now serving as chief architect of the company's so-called accelerated computing initiative. "To make effective use of multicore hardware today, you need a PhD in computer science. That can't continue if we want to enable heterogeneous CPUs."
I don't know. I just don't get the whole multicore stressout. The big problem in computing seems to be managing data. Lots of data. Zettabytes, like.
9 Comments
Perhaps the point is that if performance now increases only via multicore then you must master multicore in order to handle the increasing problem of managing every greater amounts of data.
Thus Multicore is not a problem, it is a solution to the problem, but they need to figure out how to use the solution. The problem is by this thinking abstracted and nobody discusses managing the Zetabytes, they discuss managing multicore, under the supposition that managing the latter solves the problem of managing the former (we will solve the primary problem as soon as we understand how to use the increased power we have.)
I don't know that this makes sense, it is just what I think might be the background thinking.
That is the background thinking, yes. The stressout is because the overwhelming majority of code is sequential and difficult to parallelize, and we're heading into an era where hardware power is expressed in parallel.
Much like the y2k problem, if you don't think it's a problem, you can probably safely avoid worrying about it, and someone else will solve it while you're working on what you do think is important; and if it becomes a material problem for you, you will surely notice.
This doesn't make any sense. Back in the single processor/single core days -- which we're basically still in -- the way we faked multitasking/multithreading was by scheduling each thread to run for a certain amount of time, putting it to sleep, processing the next thread, etc. With more processors the scheduler becomes more efficient at its task and applications run faster as a result.
While it's certainly not _quite_ as straight forward as this, as far as I can tell the supposed problem is not really a problem at all. We may need to focus more time on writing more efficient kernel schedulers, but the end result is that our existing code -- while it certainly isn't designed to take full advantage of multi-core processor -- is going to be enabled to run, in many cases, on a dedicated core, or at very least with each thread being given more time by the scheduler to run through its process before being put to sleep.
I don't see it as a problem at all -- I think the industry is stressing about a non-issue. Yes, there are changes required in operating systems and low-level libraries, but those changes will get done by the experts that live in those domains and have -always- worried the fine details. The rest of us can piddle-fart around the edges of parallelization for a long time and still see some sweet speedups -- it doesn't take a genius to read up on OpenMP and decorate his for loops with parallelization pragmas. With multicores, there's A LOT of low-hanging fruit to be had.
The -real- cause of the stressout, IMO, is the perception that unless you're writing highly-parallel code your product is going to slip behind your competitor's product. There is some truth in this: similar applications are probably going to have similar problems and also a similar mix of inherently serial and possibly parallel code, which means the first product to optimize Amdahl's Law for their code will run far better than the competition.
But that isn't going to happen overnight. Which suggests that we can expect the same old competitive landscape we've always experienced, where new versions always seem to be better! faster! sleeker! than last year's version. Progress will happen at the pace it needs to and the real losers are going to be the companies that spend inordinate amounts of effort trying to squeeze every last drop of performance from the multicores...instead of actually shipping products.
For a single computer, I think "learning to program for multicore" is being pushed by hardware vendors trying to convince everyone to buy their 80-way chips
As Bill said, the real problem is dealing with massive amounts of data. The bottleneck won't be processing power but memory, disk and network IO. Parallel-friendly programming is important to the extent that it addresses those problems, see MapReduce and other moving-processing-to-the-data-methods (I'd cite them, but am ignorant). So I'd say that programming for multiple machines is important, and if those techniques speed you up on a single machine then bully. Parallel programming that works across machines also let you leverage "the cloud."
Certain technologies can change the competitive landscape (see: Microsoft and the internet). Dealing with large data has certainly been a competitive advantage for google. I don't know if cloud computing will be a drastic change but I wouldn't be surprised by a hot startup that leveraged both, say to perform rapid machine learning on genomics data (possibly as an outsourced service to big pharma).
Multicore is difficult because there is no programming model for it, which makes it very hard to write compilers and VMs. The absence of standard programming patterns other than bulk synchronous style operations (such as MapReduce), and the complete absence of type checking for code correctness, makes it hard and risky to scale programming projects outside of small teams focussed on one-off projects.
We basically have two ways to go.
One way is to treat multicore as it were distributed computing between cores, using existing techniques. In other words all developers carry on writing OO code as they were. For example: program as if every core has a private OO heap. There are three problems with this: cores will have tiny local caches; access to off-core memory is relatively expensive, indeed explicit control of all communication is needed for any efficient compiler or VM to be written; and it is hard to write compilers for those remoting models, for various reasons. So people generally don't think this will work - but it may work ok for a while.
The other way is to change the programming model right up the stack, so the developer has to learn new programming tropes. OpenMP was mentioned in a comment - that is an example. People have not found OpenMP easy to program compared to Java, Ruby, C#, etc. There are other models e.g. Actors (Erlang, Scala, et al.).
Whatever happens, it has to work for tens of thousands of cores on one motherboard. Because, that is where we are going. Think "teracore" and "extreme concurrency". People also talk about "grid on a chip" where cores are laid out like Gotham City and every inter-core transport junction is a mini-router / scheduler.
Yes, data will be a problem. For one thing - show me a correct programming model for getting data to move around a grid of cores on a chip let alone accessing zettabytes off-chip. Any data model has to be both location-aware and location-invariant in the sense of the former being needed to optimise for communication paths and the latter being needed for scaling programs to work over networks as well as grids of cores.
So yes, people, this is a problem.
Address the risks It's not just home users who suffer. For businesses of all sizes, the risks are manifold. Crucial data distorted by viruses, financial data misappropriated by cyber criminals, and mountains of spam reducing ROI on human and technological resources. An effective risk management strategy is essential for business success. New technologies - new anti-malware solutions As cyber threats have evolved, so has software to deflect such threats. Sophisticated antispyware and antivirus solutions capable of detecting the most complex new viruses are now available. New personal firewall programs designed to identify the stealthiest hacker attacks can hide your computer on the Internet. And the latest anti-spam products filter out up to 99% of unsolicited mail, protecting computers from malicious code and saving time and resources., http://www.hotbot.com/?query=antiviru... HoBot.com Favorite Links, :], http://search.lycos.com/?query=antivi... Lucos.com Links, 070846, http://www.hotbot.com/?query=antiviru... Hotbot Links, llrf, http://search.live.com/results.aspx?q... Live.com links, 365915, http://www.webcrawler.com/webcrawler/... Webcrawler.com Favorite Links, %-((, http://info.com/searchw?qkw=antivirus... Info.com Favorite Links, 057, http://www.altavista.com/web/results?... Altavista.com Favorite Links, edkk, http://www.dogpile.com/dogpile/ws/res... Dogpile.com News Links, fhx, http://www.viewzi.com/search/ti-simpl... viewzi.com linksnd fifty years ago. He knuckled it away. He stood there for a moment, staring at her as if he had never www|, 343, http://msxml.excite.com/excite/ws/res... excite.com Links, tew,
thanks for ur article...
[url="http://www.uggsupply.com"]uggs[/url], with a legendary brand, first to see the snow ugg boots ,Ugg people will not Ben Ben flu cartoon form, and is [url="http://www.uggfree.co.uk"]boots[/url], as a result of many European and American film star has adequate Gordon Street Ugg snow boots and a pretty popular in Europe and America look like the earth, Ugg blowing sustained winds of the popular Madden, in Japan, Taiwan has a lot of fans Ugg.
http://www.airjordanmart.com
http://www.headphonesky.com
http://www.up2heels.com
http://www.toolsinhair.com/
http://www.aceghd.com
http://www.hotsoftshop.com
http://www.goodsbox.com
http://www.shoppingtiffany.com
http://www.topbootsmart.com