Slashdot Mirror
IBM's Chief Architect Says Software is at Dead End
j2xs writes "In an InformationWeek article entitled 'Where's the Software to Catch Up to Multicore Computing?' the Chief Architect at IBM gives some fairly compelling reasons why your favorite software will soon be rendered deadly slow because of new hardware architectures. Software, she says, just doesn't understand how to do work in parallel to take advantage of 16, 64, 128 cores on new processors. Intel just stated in an SD Times article that 100% of its server processors will be multicore by end of 2007. We will never, ever return to single processor computers. Architect Catherine Crawford goes on to discuss some of the ways developers can harness the 'tiny supercomputers' we'll all have soon, and some of the applications we can apply this brute force to."
The argument that software will get slower assumes that most consumer software will continue to have additional CPU requirements without being coded for multi-core applications. This doesn't make sense. The average consumer uses an Office product, e-mail, and a browser. None of these use anywhere close to 100% of the CPU for very long even on a Pentium 3, let alone on a 2GHz+ core in a multi-core processor.
Workstation computing will suffer some until software vendors catch up, but this is already happening (e.g. most CAD, Animation, Video Processing are starting to come out with multi-core optimized software). Sure, some apps will continue to be single-threaded, but eventually, who would buy them? Software vendors aren't dumb.
Games will probably speed up significantly as well. Imagine the possibilities of having a game engine where each AI character utilizes 100% of a single core? Game designers aren't going to sit around desiging games that run on single core engines, they always push the boundaries and will continue to do so.
Crack - Free with every butt and set of boobs
A New Kind of Science. Converting a range of standard CS algorithms into Cellular Automata networks is the very solution our brains use; a combination of message passing and feedback loops. If we want our computers to scale in parallel, we might want to look at how biology has solved the problem. A lot of people laughed at Wolfram when he initially published that book. I think he yet might have the last laugh.
I keep thinking about this as well. Really, sitting down a trying to write code that runs optimally on multiple processors is a huge headache, and, frankly, judging by the code I've seen in my life, most coders aren't up to it...It would be far better to put a VM or a specialty compiler between the code and the system, one that is capable of taking regular code and making it more multi-core friendly.
Sure it'll add overhead, but the number of cores we're going to be working with at a time is going to continue to change, and the only way to not write immediately obsolete code is to have an intermediate control layer that is smart enough to translate.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
And if thread management is good/fast enough then there's no reason things like GUI widgets can't run on their own thread/core. (I doubt spell checker in Firefox runs in it's own thread though)
thank God the internet isn't a human right.
Forgive my ignorance, but can't the OS just make each new app run on it's own core? That would probably give us some overall apparent-speed-of-computer increases, without having to completely modify all existing stuff.
stuff |
How does current virtualization software fare with multi-core architecture? I mean, if the hype is even somewhat believed even SMBs will be able to afford off-the-shelf "supercomputers". Of course relative to the real super-computers, these machines will be slow. But relative to actual requirements, they should be, well, supercomputers.
4 0210 ) becomes interesting again. If virtualization software works, then we don't need to wait for a golden age of multi-threaded software development. SMBs (and large companies too) will be able to deploy dumb terminals linked to multi-core monsters, install virtualization software to get as many servers as they need, offload individual instances of programs to the various cores as is natural, and viola: now you can actually realize all those TOC savings the thin client crowd has been raving about all these years.
Suddenly the old "everyone's moving to thin-clients/mainframes/dumb terminals/etc" story (as recently as today: http://it.slashdot.org/article.pl?sid=07/01/30/13
This transition to multi-core is what we need because, as far as I know, actually getting individual programs to run nicely on multiple cores is (with notable exceptions) something we're not really ready for yet in terms of development.
-stormin
The Southern Baptist Convention has creationism. On Slashdot, we have porn.
I'm just dipping my toe in to the world of programming so bear with me if this is silly.
Couldn't the programs inherit the benefits of a multi-core system if the APIs they call are written to distribute the work to the cores? I know this probably isn't optimal but there must be some benefits from this.
I could take an old library (QuickDraw for example) and totally rewrite it to take advantage of a new architecture as long as it accepts the old calls and returns the expected results. This is probably an over-simplification though.
-- Using the preview button since 2005
Berkeley tech report (inc. Patterson as author)
Brief summary (I heard the same talk when he spoke at PARC), computational problems are divisible into one of thirteen categories that range from matrix multiplication to finite state automata. Most existing research (academia and industry) into parallelism tends to focus on about seven of those categories that are most easily parallelized - think supercomputer cluster. Most apps that you or I use fall into the graph traversal or finite-state categories (think compilers, apps with an event loop, etc.), into which there is essentially no research. Patterson even suspects that finite state machines are inherently serial and CANNOT be parallelized.
So ... the apps that we already use can't really get faster on parallel cores without major, fundamental advances in computer science that don't seem to be approaching. Which means we'll be using our current apps for a LONG time.
Additional note: IBM (and other chip manufacturers) have a vested interest in telling everyone that parallelism is the future. They can't make faster chips anymore, they can only compete on sheer number of cores.
A witty [sig] proves nothing. --Voltaire
TFA is nothing more than a press release announcing the plan to develop a supercomputer in Los Alamos, New Mexico. Yeah, it'll be made by IBM and based on Cell (and Opteron). In an attempt to make it more interesting, the article seems to struggle to make another point... and the point is difficult to discern from its river of vague generalities, lame statistics and other banalities. Best I can fathom is that the writer (IBM's chief architect) simply hopes that new, multicore-centered development tools will somehow emerge as a result of the computer's development:
Fair enough. The Slashdot summary is a horrible spin on TFA, and the attached "-dept." tagline attached is just embarassing. Too bad there wasn't more information content here, because multicore processing is indeed the future, and this could have been a much more interesting read.