When we discuss software, we rarely associate its development to energy efficiency. It seems to be quite the opposite: larger, more powerful machines have led to larger, less efficient software. Long gone are the days, where an IBM 360 mainframe could handle up to a remarkable amount of 8MB of main memory. However, due to cost and other limitations, it was easier to find deployed systems that used from 512KB to 1024KB (1MB) of memory. It was on this type of environment that business software ran.
When the Apple][ plus hit the market, in 1979, it offered 16KB of RAM for its users, which could be expanded to 64KB, the maximum address space for the Motorola 6502 processor it used. With the Z80 SoftCard, one could add the Zilog Z80 processor, and a whopping 128K of RAM to that and open the door to databases, professional word processors and more.
As the market evolved, CPU speed and addressable memory became accessible and software began to grow. And grow it did.
When WordStar was released for the CP/M 80 operating system, it fit into a single 140 KB, 5¼” disk, with the operating system included, and enough space for a few documents. Now, if you want to run Microsoft Word locally, you need, 4GB of free space on disk after Windows has been installed. And let’s not forget the memory requirements. WordStar happily edited my university essays with 64KB of RAM (and that’s because I had the Z80 SoftCard installed) while Office 365 suggests 2GB of RAM if you are using a 64-bit computer. Things are not different in the Open-Source world. LibreOffice asks for 1.5 GB of free disk space and, a recommended, 512 MB of RAM to run on a Linux installation.
We did have new features incorporated to the word-processing tools we use. Spell and grammar checking being only two of them. We also requested our software developers to deliver more typesetting features to “enrich” the writing experience. All in the name of “efficiency”. We tend to forget that printing was slow, expensive, and that we really only had a “feel” for the final text after it had been put on paper. It was not uncommon for users to print several drafts just to see how their text would look on paper. So, responding to printing efficiency requests, we started to use the larger playground of CPU and memory provided by new machines just to see how our text would look on paper.
Word processing (or, as we old people like to call it, typing) is just an end-user example of how software bloat came to be. After the IBM PC came out, I could eventually use both WordStar and Ventura Publisher on the same machine, just not at the same time. Users demanded more processing power and with that, came larger machines with more memory and CPU speed. And just as in the parking lot analogy, if you have it, it will be used.
The same goes for servers in data centers. With the difference that these machines must be used “to the max” for economic reasons. Idle servers cost money to maintain and, in general, the less idle CPU cycles, the better. Idle CPUs are still needed to cover sudden, unexpected, surges in processing, but in general, good CPUs are the ones that are being used.
This idea has led to the efficient use of hardware through virtual machines and containers where physical servers are optimized to extract the maximum possible processing from each Watt of energy consumed.
This search for efficiency has already fueled (pun intended) initiatives such as the Green Software Foundation, where an attempt to define and promote energy-efficient software is being made. From new compilers to more efficient coding, everything counts to reduce our current software power-hunger. These initiatives are well intended, but the results are never clear.
Optimizations made in lab environments either fail to show results in the data center or are not conclusive across different platforms. We all agree, however, that inefficiencies exist and must be worked on to improve current software energy demands, which impact directly on carbon emissions and, to a certain extent, on climate change.
Cue the Open-Source advantage.
Nelson Rodrigues, a Brazilian journalist and writer, has said that “the obvious is always howling” (“O óbvio é sempre ululante”, in Portuguese). We just choose not to listen to the howls. Until someone does.
Two researchers from the University of Waterloo investigated the “performance characteristics of network stack processing for communication-heavy server applications” and their research article, “Kernel vs. User-Level Networking: Don’t Throw Out the Stack with the Interrupts” available at the ACM Digital Library (https://dl.acm.org/doi/abs/10.1145/3626780) is quite interesting.
After evaluating how the Linux kernel handles network traffic in “communications-heavy server applications”, Martin Karsten and Peter Cai were able to rearrange the operations within the networking stack.
According to their study, they were able to increase the network throughput by up to 45%, in some situations. This also pointed to a possible energy consumption reduction of 30% in certain data centre operations, with a corresponding reduction in the use of CPU cycles to handle these network events.
This was done with 30 lines of code.
This change has already been incorporated to the Linux 6.13 kernel.
While not a breakthrough in computer science, the research done by Karsten and Cai shows how access to the source-code and being able to change it, can not only increase knowledge, but deliver practical results in a very short time. The same open approach is being seen as groundbreaking, with research showing how to optimize language models with less computational resources.
There are certainly other howling packs hidden in our code. We just have to hear where they are.