Slashdot Mirror
The Future of Computing
An anonymous reader writes "Penn State computer science professor Max Fomitchev explains that computing has evolved in a spiral pattern from a centralized model to a distributed model that retains some aspects of centralized computing. Single-task PC operating systems (OSes) evolved into multitasking OSes to make the most of increasing CPU power, and the introduction of the graphical user interface at the same time reduced CPU performance and fueled demands for even more efficiencies. "The role of CPU performance is definitely waning, and if a radical new technology fails to materialize quickly we will be compelled to write more efficient code for power consumption costs and reasons," Fomitchev writes. Slow, bloated software entails higher costs in terms of both direct and indirect power consumption, and the author reasons that code optimization will likely involve the replacement of blade server racks with microblade server racks where every microblade executes a dedicated task and thus eats up less power. The collective number of microblades should also far outnumber initial "macro" blades. Fully isolating software components should enhance the system's robustness thanks to the potential of real-time component hot-swap or upgrade and the total removal of software installation, implementation, and patch conflicts. The likelihood of this happening is reliant on the factor of energy costs, which directly feeds into the factor of code optimization efficiency."
Every time I think software can't get any more bloated, I wait a year or two and it doubles in size again.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
>> we will be compelled to write more efficient code
Spoken like a true Microsoft programmer.
The Foley and van Dam classic, "Fundamentals of Interactive Computer Graphics" cites Myer and Sutherland's description of adding more intelligence to graphics processors until they become the equivalent of CPUs, at which point they repeatedly find themselves slower than mass-production CPUs and are turned back into simple devices driven by fast external CPUs once more (;-))
--dave
davecb@spamcop.net
Pardon my ignorance, but all the blades are going to have a lot of extra software running too (OS / App manager / network communication etc). So isn't there a chance of the micro-blades end up eating even more power (Specially if the software is still bloated)? Splitting the code in different blades is definitely not really code optimization anyway.
Although the universitys are pumping out thousands of qualified, certified programmers, there doesn't seem to have been any great innovations in software since Wolf3d & Office...And perhaps AOL & TCP...we need another new 'genre' of software...just for fun, here's the genres I can think of off hand: POS/Inventory, Email, File Sharing / Downloading, FPS, Paper Preperation, Scheduling and Coordination, motor control (fuel injectors / cars), RTS, Strategy/War, MMORPG, MMOFPS, Textgames, 2d photo/art, 3d modeling/art, business simulation, flight simulation, car/driving games, publishing (via the web),...and, uh, I'm probably forgetting a bunch, such as program building software (compilers, visual studio) and much more...although the future of computers is probably neat new software, that may or may not require more mhz, and not necessarily more mhz that allows the current styles of software to get more refined.
That's why I don't buy those Python/Ruby/Java productivity boasts. I'd rather do it efficiently in C/C++ right now than wait for a faster CPU that may never come.
Writing small is difficult and I don't think it can be done in a group. Most software which is small is written bij less then 3 programmers.
Compare: "Easy writing makes hard reading." -- Ernest Hemingway
What I cannot create, I do not understand
...is strongly dependent on the interfaces it presents to the world. The pressure is to push more and more functions onto a chip so that external interfaces can be eliminated. This is the victory of the general purpose computer. While in the short term it is always possible to build faster, more speciallised hardware to perform a function, eventually a faster CPU chip which implements the same facility in software becomes cheaper and generic.
What units are on the two axes of this spiral? Why isn't it nested tetrahedrons?
If I had a dime for every time /. has had a story titled "The Future of Computing".
Seriously. Not the same story, true, but the same title, over and over. Just look.
Gaming continues to be highly demanding on computer systems.
While I believe processors are currently heavily outmuscleing the exchange rate of primary memory, and that this gap should be closed, I don't believe the era of power expansion is over.
While chipmakers are becomming increasingly environmentally conscious by increasing performance per watt, they are also abandoning hype based "clock speed" development and actually focusing on reducing cycles per instruction, raising instructions per second, optimizing pipelining, and increasing responsiveness.
While this might not be seen as power growth it is, but it's similar to the difference between overall horsepower vs torque on a vehicle.
in the previous decade, most vehicles had decent horsepower but low torque, now the carmakers focus on less fuel hungry but higher torque engines, but as a side effect they also get more HP per liter.
VLC FOR MAC IS DYING! IF YOU DEVELOP, PLEASE SAVE IT!!
> "The role of CPU performance is definitely waning, and if a radical new technology fails to materialize quickly we will be compelled to write more efficient code for power consumption costs and reasons," Fomitchev writes.
Yes, he is right. The problem is that http://en.wikipedia.org/wiki/Unix_philosophy has been very long forgotten from the manifacturers of OS for 90% of the PC's around the world. I do not want to start a flamewar, just consider how many features of the OS you really need? It is arguably a GOOD practice to put everything you can in an OS, but for cryin' out loud, at least there must be a way to remove the unneeded parts.
> Slow, bloated software entails higher costs in terms of both direct and indirect power consumption, and the author reasons that code optimization will likely involve the replacement of blade server racks with microblade server racks where every microblade executes a dedicated task and thus eats up less power.
That looks like where we're heading now. Jut consider the 1000 projects for distributed computing out there, and the whole virtualization thingy. But this by itself cannot mean that much less power. If you want less consumption, you have to rely on technology AND on more optimized software.
> The collective number of microblades should also far outnumber initial "macro" blades. Fully isolating software components should enhance the system's robustness thanks to the potential of real-time component hot-swap or upgrade and the total removal of software installation, implementation, and patch conflicts.
YES!!! That's what we're talking about, man! We need separate modules to do the work. Just for info, try googling for Microkernels vs. Monolithic. Tannenbaum has good arguments in favor of microkernels in terms of stability. I don't want to take either side, but it is true that whilst a mere 99.999% of the cars don't suffer from reboots of their onboard computers, our desctops still do. Remember the old joke: "You've moved your mouse. Please restart your computer for the changes to take efect."
> The likelihood of this happening is reliant on the factor of energy costs, which directly feeds into the factor of code optimization efficiency."
Maybe we should move into higher-programming languages that take most of the optimizations hidden from the programmer. For example I have recently read a review that optimizied Java code is VERY near native C performance. Even if that is not true, C is not adapded enough for the various SSE, SIMD and so on optimizations in the modern PCs. Yes, GCC makes all kinds of optimizations, but maybe WE need to move into higher-order logic for our programs?
I should have been an academic after all, I think. All I'd have to do is write a paper that says the same thing Fred Brooks said 25 years earlier and people would think I'm brilliant.
ok, my BS meter is pegged
while the article has lots of intersting data and information, he doesn't know much about predicting the future
He's right on focusing on memory (vs. CPU) - this is where the major bottlenecks are
He completely missed the boat though on virtualization. Everywhere I look there are different examples of virtualization that are driving development choices - and he doesn't mention it once.
he also is missing the tide happening right now with metaprogramming and generators
also missing the boat on the trends in language flexibility that are turning application development into "domain specific language" development. we're at a tipping point over the current 2-3 year horizon where developers are building out the language AT THE SAME time they write their application. coupled with effective reuse strategy, this will revolutionize how quickly and how functional all our apps can be.
it sucks that tesxt is static, there are a huge number of ideas here, and I have not expressed them as well as I'd like, but alas, once submitted, the text can't change, and it presents the same info to each reader, no matter what their context or background is. I like talking to people much better.
...what's again that shit you've been smoking? That sounds awesome!
It's the algorithm. It's straight complexity theory; C/C++ is not a panacea. If you write a 2^n or n! algorithm in C, it'll have its doors blown off by an nlogn algorithm in Python.
Either you have constant time, nlogn, or even n algorithms that run OK (CPUs today are fast enough that even for a decent sized n, an n algorithm will be executed shortly). However, no computer humans can ever build that works on the same principles as your desktop computer will be able to do 2^n, n^n, or n! algortihms in any kind of useful time for large n.
You might be able to get results in a lesser amount of time if you can parallelize the work (see the Distributed.net cracking efforts on factoring into large prime numbers), but if you can't make the algorithm work in parallel or otherwise reduce it to a polynomial time algorithm, even a supercomputer from the year 50,000 won't solve these problems for large n.
Don't focus on the language; that's the wrong area to look.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Here's a link to the single page print version of the article.
To get the absolute bleeding edge advantage putting the seven of spades on a red eight?
Wow, if this guy is right, then I'd say to buy some SUNW stock, because this power-consumption problem is exactly what their latest line of server offerings directly address.
... yet :)
Oh, and I don't have any Sun stock myself, heheh
random underscore blankspace at ya know hoo dot comedy.
Today we have bulky boxen and entire rooms filled with computers. We have computers taking up space in our offices and homes. We dedicate energy to just keeping them cool. Tommorow (ok, so not really tommorow, probably in the semi-distant future) we won't really see computers at all in terms of our daily routines. They'll be so miniaturized as to become transparent. The only aspect of computing we'll see in our daily lives will be the user interfaces. The actual computers themselves will be invisible, or at least barely noticeable. They'll become mere extensions of our every whim, capable of reinforcing and improving our minds in a seamless fashion. That, I believe, is the future of computing.
Take for example Google. What happens when you can query a search into google without actually interfacing with an external device like a laptop with a wireless internet connection? Or into Wikipedia? You'll be able to answer questions within seconds of being asked. Maybe less. This is a bigger change than you might think. Where does this leave conventional schooling, for example?
To me, it's exciting. And I wish it were here already.
TLF
I do not respond to cowards. Especially anonymous ones.
Seriously, WHY DOES it take a 4ghz computer to play solitaire?
Translucent 3D! Just like real cards.
KFG
That has to do with the typical development process. It's organized poorly. Boeing builds aircraft (including its software) that requires tens of thousands of people. And that's not including the subs.
So, why is software different. Why is that I can't open up a catalog and get an module/library and have work - like you can with chips/ICs?
I tell you why: Software development doesn't operate with any engineering discipline. It's run like an arts and crafts shop. Until software is held to engineering standards, it's always going to be a buggy, sloppy, haphazard craft: definately not engineering. Software Engineering?!? Yeah right! Until there's some rigorous standards, that name will stay up there with sanitation engineering!
I don't feel like getting my brain hacked or virus infected a-la ghost in the shell thank you =/
VLC FOR MAC IS DYING! IF YOU DEVELOP, PLEASE SAVE IT!!
Throughout the article, he tries to make it seem like CPUs got "better" and then people tried to make apps that used that new CPU power. Ummm, not from where I sit...people wanted more CPU power and the manufacturers gave them what they wanted. I agree that RAM is the bottleneck, BUT I completely disagree with his assumption that people will switch to "green" computers because they save power. :-)
Try telling your mutual fund manager not to move several billions of dollars in a trade, because the "green" computer is not through computing, while his competitor (who doesn't use the "green" computer) has just made an extra few million for his clients
The only solution to the curse of infinitesimally small features is modular redundancy: hardware duplication. Triple modular redundancy is common in fault-tolerant computer design. As hardware becomes increasingly fragile due to decreasingly small features, the amount of redundancy must increase to cope with the problem of transient failure.
The implication is that the per-dollar amount of computing power which the typical consumer can buy will not increase indefinitely. As feature sizes shrink (and concurrently as the amount of computing power increases), we eventually reach a point at which the additional amount of required hardware redundancy will start to reverse the decline in dollar per unit (e.g., SPECint2005 or SPECfp2005) of computing power. Are we close to reaching that point?
I suspect that we are within 10 years of that point.
The problem of shrinking features is already manifesting itself. Microsoft now recommends that users buy computers with ECC (error-correcting code) memory if the users plan to install Vista.
Seriously, WHY DOES it take a 4ghz computer to play solitaire?
;-)
Even Vista only requires a ~800 MHz computer for the "Vista Capable" label, stupid!
Seriously, if all you want to do is to play Solitaire, why don't you grab MS-DOS and a DOS version of Solitaire and check the minimum requirements? Chances are it'll end up at something less than 8 MHz at least. But it won't be that suitable for many other modern world scenarios than playing Solitaire, you won't get something too much better than monochrome text graphics, you won't get good multitasking, no networking support or advanced features like domains or preparations for remote desktop, no USB support, and so on ad infinitum... And there you have a hint in why this looks the way you're wondering.
Modern operating systems are to be prepared for *everything* (or so the philosophy goes at least), and the users should basically just be able to press "Next" in the install process, and then it should be able to do everything listed on a website that don't know the user at all, but still have that big shiny list of stuff advertising what it can do. Guess what happens in the OS design process and how much is installed, and how high the requirements become?
Of course, minimalist freaks that still needs to use Microsoft software can take a look at Windows CE for embedded devices, or the upcoming "Windows Fundamentals for Legacy PCs" for something XP-like that has already been shown to only need 64 MB RAM in a review.
Beware: In C++, your friends can see your privates!
This discussion isnt about algorithms, its about the amount of infrastructure required to support an application. If you write the same algorithm in Java and in C++, the C++ is going to run faster, simply because it doesnt need to be interpreted again and again, which frees up CPU and memory resources (duh). Software is getting more and more bloated because developers are leaning on third party solutions (libraries,utilities, higher level languages, etc) to speed up development time. Market forces are saying that code developed efficiently is more important than efficient code. The problem lies in the tools of software developers, of which languages would be included.
Just give them a P-p-powerbook and you might see what talented ppeople those developpers are! :-)
Column 1: n. Column 2: 2^n. Colunm 3: n * log n. Column 4: n * log n + 100.
1 2 0 100
2 4 0.602059991327962 100.602059991328
3 8 1.43136376415899 101.431363764159
4 16 2.40823996531185 102.408239965312
5 32 3.49485002168009 103.49485002168
6 64 4.66890750230186 104.668907502302
7 128 5.9156862800998 105.9156862801
As you can see, for n less than 7, n * log n + 100 (which assumes our language is 100 times slower to run our n*log(n) algorithm vs. our 2^n language), the boundary exists at 6. If our language is only 50 times slower, the boundary is 5.
How much slower would a language have to be (in units) for that n to be not incredibly small; say you have AI for an RTS where you want 20 units on screen? Well, if we scale up our little speadsheet table, we see that 2^20 is 1.0x10^6 larger than 20 * log(20). This leads us to the conclusion that if we are writing AI for a game (such as Warcraft) where we want 20 units on screen, and we have a choice between C with a 2^n decision algorithm, or an interpreted language with an n*log n decision algorithm, the interpreted language would have to be 1048550.0 units slower -- or, 52428.0 units of time slower per iteration of the algorithm to be equally effective (and it'd have to have an overhead of greater than 52,428 units/iteration to be LESS effective!).
The order of the algorithm is the dominant factor in time performance of input to output. Compilers are not little god boxes, and will not fix broken algorithms. Even a very large per-iteration overhead (which doesn't exist, since interpretted languages will use caches, P-code, or even decent JIT techniques) isn't enough to sink the performance of them.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Yes, software could definitely use some trimming away of the cruft. But I don't agree with the idea that we should probably just go back to assembler, etc. Honestly, I think the new generation of programming languages have got The Right Idea, because the emphasis is shifting towards telling the computer what to do, and less and less about how to do it.
I believe the real "The Future of Computing" will happen when we move to clock-less architectures. The current problem is that high clock speeds suck up more power and generate more heat. "Efficiency" is currently understood in terms of cpu cycles. It will be a whole different ballgame between programming languages when that is no longer the case.
Well shit, stop using Java and
Care about electronic freedom? Consider donating to the EFF!
What you are comparing (a N^2 C++, to a python nlogn) you are varying two parameter. When comparing two thing you should only vary one, or you blow hot air. In other word I can counter your argument by saying a C++ nlogn implementation is better than a python n^4, but what does it says us of the CPU performance in comparing language : NOTHING.
The GP is comparing for the same implementation the speed difference. So if you implement a stupid N^2 bubble sort in C++, it will be slow as hell, but stil better than the same bubble sort in java. And if you have a nifty (N) algorithm it will still be quicker with a C++ implementation.
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
Garry Williams
continual evolutionary udates happen simply because the companies involved need to continue to grow their marketshare in order to keep the stock market happy. microsoft, for example, simply cant release windows X that ditches all the baggage from the last N versions of windows, because people expect all their applications built on any number of SDKs Libraries, etc to just work . microsoft cant afford to alienate large amounts of its existing userbase by doing so, not without commiting stock value sucidie...
hardware manufacturers are in the same boat, with the same reasons for their "bloat"(sic). its not driven by technoglical excellence, the market is driven by profit and marketshare.
the article attempts to address a technical problem which only exists because of the higher economic structure of things. simply put at the end of the day, all this hardware and software is there to make money, the future of computing will be the one that makes the companies involved the most marketshare, and cash, not the one that is the most elegant, or beneficial to humanity.
to think otherwise is to have one's head in the clouds.
Such a load of crap. You have to wonder why was the author hired as a prefessor, he seems to have a DiDio kind of insight into the future of computing. He never mentions the issue of bottlenecks, which for the last many years have been the buses connecting the computing cores. That forced the CPU manufacturers to include large caches and as much functionality as possible in a single core.
The one notable exception is the GPU which is complex enough to rival the CPU and which had the AGP bus specifically designed for it. It did not share it with any other processing core.
Now that AMD has readied HT 3.0 the bottleneck can be removed and it starts to make sense to have specialized cores connected by a high bandwidth, low latency bus. But I don't expect the author to understand this much without frying his neuron.
As I see it, the history of computing is one of repeated waves that crash against the beach as the next wave gathers behind it. In terms of corporate IT, this is marked by shifts back and forth between centralized and distributed computing, but the phenomenon encompasses all of computing.
What happens in each phase is that the new model is adopted first at the grass roots -- individual users or small groups see the "new thing" as a way to get something done, and start using it under the radar. It's frequently said that something needs to have an order of magnitude better price/performance ratio in order to be adopted over the existing way of doing things -- these waves are sufficiently radical that that's exactly what happens. This is the "decentralized" phase.
Word spreads about the new way of doing things, and it gets used more and more widely. Eventually, the corporate bureaucracy realizes what's going on and takes over, partly because it saves each group from having to support itself and partly because the "new way" becomes more sophisticated and more powerful, and outgrows the ability of small, isolated groups to manage. This is the "centralized" phase.
Time marches on, people are chafing under the iron grip of the corporate bureaucracy, and something new comes along...
On the supplier side, what happens is that the new technology is just as capable as the old, for a fraction of the cost (and size, and power requirement, and everything else), so the supplier wants to incorporate the new technology.
As I see it, the actual specific waves that we've experienced are:
What happened on the vendor side, of course, is that each wave offered tremendous cost savings. It was a lot easier to design a system around a microprocessor than to use LSI or discrete logic. Meanwhile, these microprocessor-based systems became more sophisticated, with increased I/O capacity and more processors (Sun E10K was basically 64 UltraSPARC microprocessors with lots of memory and I/O capacity), and commodity microprocessors, motherboards, memory, and disk attacked proprietary systems. Each wave
Where's the *journal* in Dr. Dobbs Journal? It has editors but apparently no one actually edits? I can forgive the lack of "the" articles in the article from I assume a Russian writer, but not the dozens of basic errors.
... CPUs execute"
Discreet elements were gradually replaced with integrated circuits
"Discrete elements"
Intel's new "Woodcrest" server chip as only 14
"Woodcrest server chip has only 14"
speculative threading in the vane of to Intel's Mitosis.
new manufacturing technology in the vane of IBM's
in the vane of Sun's UltraSparc
"in the vein of..."!
although it's new Efficieon CPU
"Its" here is not a contraction of "it is" or "it has", so no apostrophe, also garbled name "Efficeon"
the cores itself would become more simple and less-deeply pipelined (kind of like UltraSparc T1 is doing already).
The cores themselves would become simpler and less-deeply pipelined (similar to the UltraSparc T1)
while other cores might be deprived of such capacity
He means "capability"
unless a way of frequency increases is found that does not result in the market increase in power consumption
"Unless a way to increase frequency is found that does not result in a marked increase in power consumption"
instead are likely to seem them in niece markets
"see them in niche markets"
Code efficiency is at all time low and potentially hide at least a order of magnitude performance boost
"Code efficiency is at an all-time low and potentially hides at least an order-of-magnitude performance boost"
the role of CPU is likely to diminish with time living little reason for further clock-speed improvement
"leaving little reason..." !!
extremely bloated code that out GHz-rated CPUs execute
"that ouR
there is amble room for software optimization
"ample room" !
Quite another alternative to VLIW that is already sprouting profusely
WTF?
Crap editing makes text difficult to read, so people won't read carefully, leading to superficial scanning and the decline of RTFA.
=S
This is a simplistic view of the world. It assumes that the only means of optimization is a big-O algorithm change. If you're using a bad algorithm and you're working with non-negligible data sets, then obviously you should choose a better algorithm -- that's just CS101. The interesting conversation doesn't even start until you are already using the best algorithm available to you.
Is C/C++ a panacea? Of course not -- straw man. But when your algorithms are equal, high-level languages will execute an algorithm many times slower than a low-level language. An asymptotic order slower? No. But those constant factors are significant.
WinFLoP?
"Single-task PC operating systems (OSes) evolved into multitasking OSes to make the most of increasing CPU power"
I don't think so. The motivation for multitasking was to allow data to be exchanged between applications while both were still running as well as allowing a longer-term task to run in the background while the user does other work. The trade-offs between running a single application and muliple applications at the same time are actually rather independent of CPU speed.
That should be a given, regardless of your nice new shiny hardware. Anything less is pure lazyness.
---- Booth was a patriot ----
"...and the author reasons that code optimization will likely involve the replacement of blade server racks with microblade server racks where every microblade executes a dedicated task and thus eats up less power."
Huh? The reasons that blades sell is because they are economically efficient. Creating multiple "single task" physical blades to replace a single more powerful virtualized blade is not cost efficient. In the microBlade, you multiply the number of common components needed to run an independant system (I/O, memory, core chipset, etc) which costs more in absolute terms, costs more in power, and costs more to manage. If the microblade is less powerful than the macroblade, what do you do when you need the macroblade's execution power? Cluster a bunch of microblades together? Not real effcient.
Multitasking is for getting the most our of your computer (whether it's fast or slow) but pays off most rewardingly when it's slow. If processors and I/O were infinitely fast, people wouldn't give a damn about multitasking, because they would never be waiting for their computer to complete a task. It's when you have to wait for something that you most enjoy multitasking; it lets you use your machine for doing something else instead of twiddling your thumbs staring at the progress indicator.
Let's say you want to render a graphics scene, download a file, and edit a text document. An MSDOS user would do those things serially, sadly knowing that:
And this was true whether it was a 4.7 MHz XT or a 100 MHz 486. "Extra power" had nothing to do with it. Indeed, the 486 user probably lamented MSDOS' lack of multitasking less (not more, as the author suggests) because the rendering would be so much faster.
Meanwhile, the 7 MHz Amiga user, despite the seemingly "wimpiness" of his machine (HA!), did all three operations in parallel. His CPU stayed at 100% utilization, his serial port downloaded as fast as it could, and his text editor easily kept up with his typing. The Amiga user gets the most out of his machine. Not because the Amiga is fast, but because multitasking mitigates slowness.
It's the mere desire to get the most work done, that led to multitasking on personal computers. It wasn't the "extra power" that did it. It just seemed that way to the x86 users (and probably only the x86 users) because the slow chips (8086) just happened to have very poor support for multitasking compared to the fast chips (80386). So multitasking appears to correlate with speed. But for the x86ers, it was really a question of CPU features, rather than performance.
The crux of the author's error is this: "We had extra power and we wanted to do something with it." He has forgotten that "we wanted to do something with it" whether or not we had "extra power."
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
While there have been some very erudite comments made in response to this article it seems to me you are all missing the major new concept the author proposes. Let me quote:
Yes! Niece markets. A concept almost entirely unconceptualised before. And isn't that surprising? - surely people have looked for a place to buy and sell nieces before. Where to buy a nice niece? Where to offload a baker's niece (so irritating it seems like there's 13 of them). Step right down to Aunt Martha's Niece Market. "You'll love our nieces to pieces!"
Actually now I think about it - a niece market - a better example of a niche market you are not likely to seem.
Microblades were a real technological breakthrough 30,000 years ago. Let's do it again.
Code that is efficient and robust does not lead to long term profit...becasue it works.
Software vendors that make a profit year after year do so by selling an idea and a dream to customers that software will solve numerous business process problems.
So as long as we have users clamoring for the next shiney object dangle in front of them software vendors will continue to provide expensive, cumbersome, bloated, difficult to support and overly complicated software that provides a constant stream of revenue. There is no real motivation to produce quality code as long bloated code is profitable.
As one software maker who I worked for said:
"Sell them the sizzle and give them the bacon later."
People often ignore the potential of high-level optimisations to blow any low-level tweaking that can be done in C out of the water(*). Sometimes higher-level languages permit optimisations which are simply impossible/undecidable in C -- this can be by token of stronger/more powerful type systems, powerful term rewriting/elimination, or even just by making highly complex, but asymptotically more efficient, algorithms simpler to implement correctly, etc. Currently, low-level tweaking usually wins out, but the higher-level languages are gaining ground rapidly in this area.
Another point is that using high-level languages does not actually prohibit low-level optimisations in the code emitted by the compiler. Granted, the application programmer will not have as much control as in, say, C, but much of the potential is still there.
Of course, one should also never underestimate the value of programmer time vs. computer time.
(*) I'm NOT saying that low-level tweaking is pointless, btw. Ensuring cache-locality and is one of the most important activities that can be performed for any performance-critical code.
HAND.