Compact Code and Energy Efficient Software

Back in the dark ages when microprocessor chips had just been invented, engineering undergrads often got their first taste of serious computer programming on machines such as the DEC PDP-11 minicomputer. Besides trying to write programs that actually ran correctly on the PDP-11, students of the day also had to make their code compact. One way to get exasperated looks from instructors in those early computer classes was to turn in programs taking up 20 lines of assembly code that could have been done in 15. The reason for their consternation, of course, was that memory was expensive. The PDP-11 typically had just 4,096 16-bit words of read/write memory consisting of 22-mil magnetic cores that were accessed using wires.

A PDP-11 computer from Digital Equipment Corporation (DEC). (Image source: flickr)

Fast forward to today and you'll find programming courses still stress compact code. But indications are programming classes may soon shift their emphasis from writing not just compact code but also software that minimizes energy consumption.

Computer code energy efficiency was once a niche subject. It was of interest mainly to programmers of small embedded systems where an MCU's power dissipation had to be nursed along to maximize the life of the coin cell providing the juice. Now, software energy efficiency is going mainstream. It is increasingly common to see smartphone users avoiding CPU-intensive apps just to get a bit more out of the phone battery. Even cloud-based systems are paying attention to software energy efficiency because of its impact on the carbon emissions of data centers.

At first glance, you might suspect that compact code already is energy-efficient. It turns out that this rule of thumb is sometimes true, but not always. Moreover, the energy efficiency of a computer program generally depends on the language it is written in. Compiled languages are more energy-efficient than interpreted languages or those making up virtual machines. But there can be big differences in the energy efficiency even among compiled languages that seem to be related to each other.

Insights into how energy, time, and memory use relate to energy-efficient programming come from work done by researchers in Portugal (https://dl.acm.org/doi/10.1145/3136014.3136031). They analyzed the performance of 27 software languages for energy efficiency. To do so, they used state-of-the-art compilers, interpreters, and virtual machines and watched what happened when they ran 13 different programs used to compare how widely used algorithms can be implemented in various popular programming languages.

For example, one benchmark program measured the time it took to calculate the interaction between multiple particles in a system. Another one allocated and deallocated lots of binary trees. A third updated a hash table and used it to count specific DNA nucleotide sequences.

The researchers note that there's a common misconception that energy consumption in software is proportional to execution time: Faster is always better. So reducing the execution time of a program would reduce its energy consumption by the same proportion. But the relationship isn't necessarily simply because dissipated energy is the product of power used and time duration. Thus a faster program may not be more energy-efficient if it consumes more power while it executes.

Consequently, researchers found several instances where the rank of a programming language's energy consumption differed from that of its execution time. For example, in a benchmark involving the generation and writing of random DNA sequences, Fortran turned out to be the second most energy-efficient language, though it came in eighth place for execution time. And when computing binary trees, the energy consumption of the Pascal and Chapel languages was within 10% of each other, though Chapel takes about 55% less time to execute.

A few of the researchers' conclusions are not surprising. One finding: The C language is, overall, the fastest and most energy-efficient (57 J, 2,019 msec on average to execute). After C, the top four languages needing the least energy and time to execute the benchmarks turned out to be Rust (59 J, 2,103 msec), C++ (77 J, 3,155 msec), Ada (98 J, 3,740 msec), and Java (114 J, 3,821 msec). And as you might expect, compiled languages were far more energy-efficient than interpreted or virtual machine languages. Compiled programs averaged 120 J to execute the solutions, while virtual machines and interpreted languages sucked up 5,760 J and 2,365 J, respectively.

No surprise, then, that the bottom five languages in energy efficiency and execution time were all interpreted: Perl (4,604 J), Python (4,390 J), Ruby (4,045 J), JRuby (2,693 J), and Lua (2,660 J) for energy; Lua (16,7416 msec), Python (14,5178 msec), Perl (13,2856 msec), Ruby (119,832 msec), and TypeScript (93,292 msec) for time.

The researchers also showed where most of the dissipated energy goes. CPU-based energy consumption always represents the majority of the energy consumed. On average, the CPU consumes almost 90% of the energy with DRAM consuming the rest, regardless of whether the language is compiled, interpreted, or virtual.

All in all, the Portuguese researchers say it's relatively easy to decide on the best software language if developers are only concerned with execution time and energy consumption. But the choice isn't automatic if memory use is also a factor.

Thus for the planet, there is good news: It's possible to optimize software for energy efficiency. For students learning to program, there is bad news: You can now earn a scowl from your programming instructor not only for turning in an insufficiently compact program but also for one that lacks energy efficiency.