lawyer

#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.

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.