After years of delivering faster and faster chips that can easily boost the performance of most desktop software, Intel says the free ride is over. Already, chipmakers like Intel and AMD are delivering processors that have multiple brains, or cores, rather than single brains that run ever faster. The challenge is that most of today's software isn't built to handle that kind of advance. "The software has to also start following Moore's law," Intel fellow Shekhar Borkar said, referring to the notion that chips offer roughly double the performance every 18 months to two years. "Software has to double the amount of parallelism that it can support every two years."
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-12-15
I still disagree and for the record I don't believe it's a poor argument. To my mind, justifying sloppy, unprofessional and inefficient code the way you have is a horrible example of why we have such bloated software these days.
Backward compatibility has a place here too I believe, but to say that lean and efficient code is not very useful is narrow minded, short sighted and more a means to justify one not being up to the task.
To my mind, it's wiser to write smaller, fast & efficient reusable modules.
Edited 2007-05-27 01:46
Member since:2005-07-06
I'm not justifying sloppy, unprofessional, inefficient code. I'm justifying clean, elegant, maintainable, inefficient code 
You're lumping in all the attributes of good code (small, reusable, professional), into the "efficient" box, and lumping in all the attributes of poor code into the "inefficient" box. But that's a highly illogical claim. Less-optimized code is at least as small, simple, and reusable as optimized code, and usually much more so. An unoptimized program must only be concerned with solving the problem at hand. An optimized program must both solve the problem and run quickly, creating an additional constraint on the solution. The solution set under the unoptimized condition is a superset of the solution set under the optimized condition. Therefore, the former set contains any "small, elegant, reusable" solutions that the latter set does, and very likely many "smaller, more elegant, and more reusable" solutions that the latter doesn't.
More concretely, "optimization" is the process of taking advantages of special cases in more general algorithms, thus realizing a performance gain. Recognizing and utilizing these special cases almost always makes the code larger, and inherently makes the code less reusable (by making it rely in additional assumptions). It also almost always makes the code less elegant, but cluttering up the logic of the algorithm with said special cases. There is no getting around it --- it's just simpler when code only deals with solving the problem, rather than solving the problem and doing it quickly.
As for the "bloated" software of today; go use NT 4.0 for awhile and tell me how awesome software was back in the day. Yes, it got things done quite nicely in 64MB of RAM. But it's a relic best left in the past!
Member since:2005-07-07
I still disagree and for the record I don't believe it's a poor argument. To my mind, justifying sloppy, unprofessional and inefficient code the way you have is a horrible example of why we have such bloated software these days.
I disagree. Code has to be made reusable in order to reduce code complexity while increasing features. In order to do that you have to refactor a lot of code into reusable libraries. When you do that it takes a lot more resources to use those than it does to use smaller optimized routines within the program itself. It is inevitable. If we want software to progress we're going to have deal with this reality. That isn't to say that there isn't bloated software out there but I hate it when people lump everything useful into the bloated category while they suggest that fast and featureless code is much better just because it is fast. To me bloated usually means "backward compatible".
Member since:
2005-07-06
This is a really poor argument. There is a trade-off between stability/robustness, performance, speed of development, ease of maintenance, and features. More of one necessarily means less of another.
Some people would like to think that if we increased the relative importance of performance, by holding CPU performance to a specific level, we'd get software that was as functional as today's software, only faster, but that's a fantasy. We'd just get bugger, less-complete software that took longer to develop and progressed more slowly. Some people look back fondly on the early 1990s, to software they perceived as "lean" and "focused". But by and large, most of it was crap compared to the stuff we have today. I mean find any serious user of Aperture and tell them they'd be perfectly happy with Paint Shop Pro 1.0!
For most purposes, "efficient, lean" code is not very useful. The goal of any software is to meet target requirements (performance and features) while controlling costs. If fast processors means that you can write good code*, then why not take advantage of that? It makes a lot more sense to buy more (cheap) processors, than to hire more (expensive) programmers, or to waste your user's time on software that isn't as robust or complete as they need.
*) By and large, highly-optimized code is poor code. Well-abstracted, elegant code is usually slower, but it's much, much easier to maintain in the long run.