| |

CIO Network

Insights and ideas for technology leaders. full bio →

Opinions expressed by Forbes Contributors are their own.


Tech 6,072 views

Why Software Doesn't Follow Moore's Law

Post written by Brian Maccaba

Brian Maccaba is CEO of Waratek, a specialist Java virtualization company based in Dublin, Ireland.

In 1965 Gordon Moore, co-founder of Intel, predicted that the number of transistors per square inch on integrated circuits, which had doubled every year since they were invented, would continue to do so for the foreseeable future. That prediction proved remarkably visionary.

So why haven’t computer systems achieved the same advances in speed, power and capacity promised by Moore’s Law? By this I mean in terms of visible and useful outputs, the amount of work achieved for a given investment in computer systems and operations. Despite a ten-fold increase in microprocessor performance every 5 years, corporate IT spending has increased, not declined.

The primary reason for this disconnect is that the size and complexity of operating systems has largely offset much of the increase in raw computing power. More processing power and memory have enabled engineers to write ever larger and more complex systems code. There is a direct correlation, in fact, between Moore’s Law and the increase in the size of operating systems. These charts (click to enlarge) show desktop and server trends.

Server Chart

Desktop Chart

The following practices and associated outcomes explain why advancements in IT value have not kept pace with Moore’s Law.

Lazy design. Increasing power and capacity have greatly reduced the need for efficient architectures and economic designs.  Soviet military engineers were long able to offset the disadvantage of less powerful chips by producing more efficient designs than their western counterparts.

Maintenance and Support. Brian Goetz, the chief language architect for Java, recently said that it is far more important to be able to read code than to write code.  That’s because the costs of maintaining software programs over their lifetime can greatly exceed the initial cost of writing them.

Forced Obsolescence. Virtually every software application suddenly experiences a significant drop in performance when upgraded to a new operating system, forcing an upgrade to a faster machine.

The Legacy Problem. New operating systems require perfectly good software applications, in which millions of dollars were invested, to be upgraded or rewritten with essentially the same business logic as the previous version.

Virtualization and the Cloud. Typical web applications, many of which are written in Java, do not run directly on the operating system.  They require an application platform such as Weblogic, Websphere, or Apache Tomcat, which in turn runs in a Java Virtual Machine that then runs on a Linux operating system.  In a virtualized computing environment the operating system itself will run inside a virtual machine such as VMware, Xen or KVM.  So the business logic in the application is now separated by four levels of intervening software from the underlying chip.

The ultimate promise of Moore’s Law is a world where hosting a computer application is extremely low cost. This is theoretically feasible, but first we need to stop the current practice of amortizing microprocessor advancements with bloated software. We want microprocessor performance to double every 18 months, but not software complexity.

The payback would be substantial. Leaner software can achieve a potential 50 percent reduction in the number of new servers purchased each year. This would translate into an estimated savings of $65B in capital and operating expenses over a five year period, and significantly reduce data center energy consumption.

This can be achieved through innovations in software engineering and virtualization. For example, startup Cloudius has built technology that eliminates software layers by combining an operating system with a virtualization engine. Meanwhile, Docker has developed an open-source engine that transforms any application into a lightweight, portable, self-sufficient container that will run virtually anywhere.

It’s time for software to grow up and keep up with its semiconductor sibling.

Post Your Comment

Please or sign up to comment.


  • LeoTM LeoTM 6 months ago

    Great informative article.

  • “More processing power and memory have enabled engineers to write ever larger and more complex systems code.” Implicit in that statement is the assumption that an application’s time spent executing operating system code is directly proportional to the size (LOC) of the operating system. That is not necessarily the case. In fact, when I was doing operating systems work, part of our objective was for the OS to provide functionality to applications with as “thin” a processing layer as possible, precisely to avoid the kind of execution bloat the author describes. So the issue is not the LOC of the operating system; it is the OS’s design quality. I think some OS’s have become more bloated both in overall size and in the “thickness” of providing functionality to applications, so the author has a point, but his charts comparing OS LOC size with Moore’s law are basically meaningless.

    There is another issue with operating systems that does bear on application efficiency, and that is the complexity of the operating environment. Services provided by operating systems are becoming more and more asynchronous, and more richly so (windowed environments, mobile services, touch screen response, etc.), and this takes more cycles than in previous, more synchronous times. It’s fortunate that Moore’s Law is allowing us to forge ahead into this new world of (we hope) user-friendly functionality.

    “Lazy design” — the author’s point is well taken. Faster processors, and more especially the drop in RAM prices, have encouraged bloated and inefficient software design and implementation. Given the state of the software development business, this has always been a problem, but it has gotten much worse because of cheap RAM and faster processors.

    “Maintenance and Support.” This is obviously an issue, but I don’t think it has gotten that much worse recently; the problem is that it has been bad for a long time. The author’s point about Soviet software engineers is well taken; back in the days of severely limited RAM and slow processors, we had to be efficient and, even more importantly, our software had to be robust. That’s still true of real-time systems, especially life-critical ones. The problem is that software developers are not trained to, nor held to, the standards that exist in those life-critical endeavors. For instance, operating system development used to have very high standards, and we followed a “separation of concerns” principle that kept the guts of the OS at a low level, with most functionality provided at upper levels, closer to the application (e.g. run libraries). What I’ve seen since those days is a conflation of OS “guts” with higher-level functionality that, in my view, is likely to compromise the OS’s robustness. And it results in much more frequent mandatory updates, which is a pain for users.

    “Forced Obsolescence.” The author’s point depends on the nature of the application. Our computer language expert system requires little in terms of OS services, so it has been pretty much immune to the problem he describes. The trade-off is that using the OS’s functionality locks the application into that OS and exposes it to the upgrade issues the author describes; not using that functionality means rolling it yourself. What we try to do is “virtualize” the functionality so we can float it onto different operating systems while still taking advantage of their functionality as much as possible, without the downside.

    “The Legacy Problem.” Any major application that requires a rewrite to accommodate movement to a new operating system was badly designed and implemented in the first place. (And yes, I agree that happens a lot.) We have refined our application code to make it highly OS-independent, in sheer self-defense.

    “Virtualization and the Cloud.” This assumes that a VM is “thick” (as I used the term above). A good VM is as “thin” as possible, translating as many virtual services as possible directly to native OS services. (I once worked on a minicomputer simulation system whose hardware simulation was so complete that when code running on it hit a breakpoint, the simulated HDD stopped rotating! That meant that the simulation ratio was around 85:1, so we had to be as effective as possible to offset that.) But the author’s point about layers is a good one, especially in terms of a VM executing byte code, although JIT is making some progress in ameliorating that problem.

    The author makes the point that more efficient software could save a lot of money in hardware expenditures. But in my view, the major expense is not hardware; it is developer time. And that will only be solved when we train for, and then insist on, much higher software quality than we have now.

    Longer term, as the author of a computer language expert system that provides rule-driven symbolic manipulation (both assessment and transformation) of a broad ranges of languages, my view is that as automation sinks its teeth into software development, the number of developers will dramatically decrease, and the average skill and talent level of the survivors will just as dramatically increase. They will be either creating & maintaining systems using the automation tools, or creating & maintaining those tools. Because of their advanced level of skill and experience, they will be in short supply, so their geographic location will be irrelevant, and they will earn globally-based salaries. This will eliminate labor cost arbitrage as a business driver, which will wipe out the whole concept of “off-shoring”. All of this will not happen tomorrow, but sooner than people think. At that point, the concepts of migration and modernization (and even software maintenance) will be obsolete as we know them now.

  • Gautam Tandon Gautam Tandon 6 months ago

    I agree with the entire argument of how software has become “bloated” and all. However the catch 22 situation with writing “lean software” is that you need to spend much more effort (in terms of time & money) to be able code a lean software. In many cases you might not even be able to find the right kind of resources who have the background, knowledge, skills and mindset to write super lean software. And so practically, how so ever pathetic it may sound, the only way to write lean software would be to write lot of fragmented software tools (ex: the base Linux kernel is extremely lean but it’s good for nothing as far as any day-to-day business activity is concerned); something that we did back in 70s and 80s (or perhaps even before that). I think we humans are “hardwired to consume resources” and that’s what we are doing with the computing resources… 10 yrs back a 1GB HDD was an envy on the market, now no one cares even about 1TB… and the same holds true for CPU, RAM, and so on…

  • Gary Allison Gary Allison 6 months ago

    This topic has been on my mind of late, though I have a different perspective on how Moore’s Law applies to Software Architectures. Here’s my blog post from today summarizing these thoughts posted at: http://www.garyallison.com/how-software-architectures-follow-moores-law/

    Monday, an article was posted on Forbes titled “Why Software Doesn’t Follow Moore’s Law”. This topic has been on my mind some lately as we’ve been working to rollout a new platform with greater scalability, lower maintenance costs, and significantly enhanced capabilities. For engineers that have worked only on the new platform, it is easy to disparage the original platform. Many of them were were not even professional engineers when the original platform was written and they lose sight of how software architectures have changed over the years from the traditional three tier architecture to the lambda architectures of today.

    It’s interesting to break this down a bit more. Are engineers smarter today than they were 8-10 years ago? And were those of 10 years ago smarter than those of 20 years past? In my humble estimation no, and one could argue todays graduates know appreciably less about how computers actually work but lets not digress.

    What has changed is the way software is constructed. One can argue that modern languages have a major role to play in this, but one can argue also they are an outcome of the changes in architecture. But why has the architectural change occurred?

    I believe a significant part of the change in software architecture is attributable to Moore’s law, somewhat in opposition to Mr Maccaba’s article in Forbes this week. Certainly engineers 10 and perhaps 20 years ago understood the advantages of isolation and service oriented architectures. Why didn’t they build systems in this way?

    A major reason what that the systems and networks in place really couldn’t support it. Without gigabit networks, fast processors, and super cheap compute, the emphasis was on highly optimized code paths. REST Call? You would have been laughed out of town. Now the opposite is true.

    Thus, Moores law has enabled much less efficient architectures to be feasible. Mr Maccaba also asserts this, but missed the point. These new architectures are much more scalable, can be built with fewer dependencies, can be changed independently since they are loosely coupled, and allow previously unobtainable compute goals to be broken down into independent parts and delivered. This is true whether we are talking about large scale web application infrastructure or big data analytics.

    By constructing software architectures that take advantage of Moore’s law, we are solving problems that could never be solved before and constructing software systems of higher quality that we can actually deliver in much faster times to market. While certainly not doubling every 18 months, the time to market of new highly scalable solutions is measured in months today instead of years.

    At the end of the day, I feel the point Mr Maccaba has missed here is that Moore’s law doesn’t apply to humans. Thus, we leverage Moore’s law to make humans more effective in software engineering through architectures that do deliver significant increases in scalability, quality, and capability.

  • Dean Schulze Dean Schulze 6 months ago

    This has been known for a long time. Nilaus Wirth’s law says that software gets slower faster than hardware gets faster. In other words what Intel giveth Microsoft taketh away.

    Software allows far more sloppiness and just plain stupidity than you could get away with in hardware. As a software engineer for 20 years I still can’t believe the shoddy work and just plain incompetence that is endemic in software. What we call internal quality, the quality of the design and code itself, counts for nothing.

    Software should get better over time as more work is done on it, but the opposite happens. It gets worse until you have to throw the whole thing out and start over.

    There are no standards in software. Nature enforces some standards on other fields of engineering, however.