What if multicore is all wrong?
Stories Columns Opinions Resources
Sun extends Groovy, PHP support to NetBeans
Version 6.5 of the IDE will see complete support for those two languages along with comple...
|
Sun reorganizes its software production infrastructure
Facing economic hardships, lost revenue and loss of employees, Sun has split its software ...
|
Adobe steers Flash toward RIA implementation
At this year's Adobe MAX Conference, the focus was on Flash, this time making Flash more o...
|
BigLever builds a bridge to SCM with Gears
The Gears Universal Configuration Management Bridge allows CM systems to integrate with Ge...
|
SOA Watch: New economic realities
In the current economic downturn, agile programming and SOA are attractive options that bu...
|
Integration Watch: A new twist on threads
The key to raising the efficiency of multiprocessors is to shrink the overall workload by ...
|
Integration Watch: The Return of NetRexx?
Java scripting languages are seeing a surge in popularity, with NetRexx looking particular...
|
Windows & .NET Watch: Transaction crowd gets a boost
With multicore chips becoming the standard for processors, the need for a flexible, usable...
|
From the Editors: Election should shake up JCP
Rod Johnson has the right ideas for opening up the Java Community Process, and he may be a...
|
Letters to the Editor: Sun gives REST, SOAP choice
A reader takes issue with a headline on our story about Sun working with REST along with S...
|
Guest View: Be smart and lazy
The optimal solution for problems is the simplest one, so always aim to streamline your ap...
|
Zeichick's Take: From EXEC to EXEC 2 to REXX to NetRexx
Andrew Binstock's column last week, "The Return of NetRexx," brought back some fond memori...
|
Practical tips for saving money on code maintenance
If software design is expensive, well, code maintenance is even more so. When you look...
|
Transform your app-dev quality by involving the whole community in testing
As the saying goes, the more eyes you have on software, the shallower the bugs. That’...
|
Build your dev and test labs for less – a lot less – with virtualization
You don’t have the budget to equip developers and software test teams with all the har...
|
Software Common Hacks and Counterattacks: A Guide to Protecting Software Products against the Top 7 Piracy Threats
Software piracy continues to be a growing epidemic. This white paper examines prevalen...
|
By Andrew Binstock
June 1, 2008 —
For the past few years, fellow columnist Larry O’Brien and I have been banging the drum for moving to multithreaded apps on the client side. The basic proposition, as we’ve stated it, is that eventually users will not accept versions of client apps that are slow because of a lack of support for multiple threads. And since every processor on the desktop has multiple cores or equivalent features, there will be no excuse for lazily programming in a single-threaded mode.
Larry and I then went in separate directions discussing solutions to making this transition easier, though we have both felt at various times that the OpenMP model was one of the easiest and most effective approaches to desktop threading.
Now that PC vendors ship sub-US$700 quad-core systems, our point should take on greater urgency. However, no one except possibly the two x86 multicore vendors—Intel and AMD—have the slightest interest in this issue. Chip vendors care deeply about this problem because their road map for the foreseeable future is based on adding even more cores to the processors.
So, if developers aren’t exploiting the cores and users aren’t pushing for them, the demand for chips suddenly could slow down appreciably. Only high-end software would make sense on the new chips. For that reason, Intel, AMD, Sun, IBM and others started funding new research projects to find compelling ways to move developers to the new many-threaded world. (For example, see their initiative at Stanford University.)
But, perhaps instead of trying to force the problem into a specific solution (developer adoption), we should re-examine the problem itself. What’s wrong with a limited number of threads? And is multicore the answer? In a recent interview with Donald Knuth, I asked the wizard the latter question, to which he responded:
“I might as well flame a bit about my personal unhappiness with the current trend toward multicore architecture. To me, it looks more or less like the hardware designers have run out of ideas, and they’re trying to pass the blame for the future demise of Moore’s Law to the software writers by giving us machines that work faster only on a few key benchmarks. … I’ve written well over a thousand programs, many of which have substantial size. I can’t think of even five of those programs that would have been enhanced noticeably by parallelism or multithreading.
“How many programmers do you know who are enthusiastic about these promised machines of the future? I hear almost nothing but grief from software people, although the hardware folks in our department assure me that I’m wrong.
“I know that important applications for parallelism exist—rendering graphics, breaking codes, scanning images, simulating physical and biological processes, etc. But all these applications require dedicated code and special-purpose techniques, which will need to be changed substantially every few years.”
The applications that Knuth points out as suitable for multithreading are for most desktops limited to encoding and decoding graphics, video and audio. And while those apps benefit from multiple cores, it’s not clear that they need more than the quad-core machines of today to render all the sound and visual display in real-time.
As for me, I just finished a review of quad-core workstations and found that most apps, except true high-end visualization or statistical software, were entirely satisfied with four cores. And my perception was that even at two cores, most apps would have run only slightly more slowly. So, who but a few high-end users need more? And, with each core streaming through 3 billion instructions per second and being fed by chip caches that scale up to 12MB, is there a need to rewrite single-threaded software for multiple threads? Probably not. Sure, things will be faster with multithreading, and where task decomposition can be done easily, it should be included. But it is unclear whether that benefit suggests a larger embrace of multithreading.
In retrospect, I am surprised that the major chip companies have done so little to spur the adoption of multicore processors. I can remember the Intel Inside, the Intel bunnies and the Blue Man Group as promotions for various Intel architectures. But for multiple cores, I can recall no such campaign. So, I slowly conclude that if there is no pull by the market, then no push on developers will work because all solutions currently add complexity. And until either user satisfaction changes or multithreading becomes easier, I don’t see how pushing developers to the new threading model makes sense for the client.
Andrew Binstock is the principal analyst at Pacific Data Works. Read his blog at binstock.blogspot.com.
Related Search Term(s): Multicore
Share this link: http://sdtimes.com/link/32164