Efficiency Spoilers

Freitag acknowledges that efficient code does not necessarily lead to an energy-saving program. For example, a pass-through NAS solution draws more power from the grid than server-based services that start up time and time again. If an application demands hard work from the CPU for a short period of time and then has to clock up or switch on its power-hungry high-performance cores, the energy balance could be worse than that of a slow program that is satisfied with a power saver. Go developers can use the NumCPU() function from the standard library to query the number of available processor cores, but they cannot target work to a specific CPU core. You have to rely on the operating system or manipulate the Linux scheduler in order to target a specific core.

Special computing units can reduce energy consumption. For example, crypto units help build low-power SSL connections, and AI accelerators evaluate neural networks in an agile way. Go programs use libraries to pass their computations to these accelerators. For example, the GoCV package supports the use of NVIDIA's CUDA interface [10].

More energy guzzlers are hidden away in what are now numerous intermediate layers. For example, ownCloud, which is written in PHP, requires a complete LAMP stack. Accordingly, the power bill includes at least one database, a web server, and the PHP interpreter. On top of this, the individual services are often locked into a complex container environment or virtualization solution. OCIS, on the other hand, like most Go programs, runs natively on the server, making the PHP interpreter and some other intermediate layers obsolete.

Another task that often goes under the radar is software development. Developing software generates energy costs. In the development phase, complex CI systems repeatedly build and test the source code. OCIS is created using Drone [11], for example. Automatically starting the compiler and running the constantly recurring (unit) tests causes the software's footprint to grow, although the Go compiler itself is considered quite fast and economical.

Data Flood

Energy consumption depends not just on the processor load but also on the processed data. For example, an online store that is constantly bombarded with orders consumes more energy than it takes to deliver a text-centric website once an hour. Fetching large volumes of data from RAM costs significantly less power than requesting the data from a database or extracting the data from disk storage. Caches also catch intermediate results, such as preview images once they are generated. Once again, you don't have to reinvent the wheel: Many libraries provide efficient caching. Go developers can take a look at Gocache, for example [12].

However, RAM also consumes power. If the required data fits into the processor cache, the main memory goes to sleep. So if you're juggling sparse matrices, for example, you will want to compress them using efficient methods. By the way, the study also looked at RAM consumption. The programs generated by Go take up less space on average than their counterparts from competitors. Only Pascal takes less space.

Programmers also play an important role in energy-efficient RAM usage. When you pass a value to a function (calling by value), Go and many other languages copy it in memory. If the function is called frequently, many copies of the same value are created. But if you pass the function a reference to the value (calling by reference), this removes the need to access memory. Much like C, Go offers pointers (Figure 5) for this purpose, meaning that you only pass in references to the actual data. This approach saves energy in the case of repeated access and large data structures.

Figure 5: Pointers speed up memory access and data transfer in Go. In this way, you can quickly exchange the content of a variable without having to copy it.

The reference implementation of the current Go 1.19 uses a garbage collector [13] to manage memory. The garbage collector cleans up in the background and automatically releases memory space that is no longer needed. However, its activity consumes compute time and therefore power. Although you could disable the garbage collector, you might end up running out of RAM or experiencing some other unpleasant side effects. The results of the study indicate that the garbage collector in Go uses very little energy.

Energy Ping-Pong

The Computer Language Benchmark Game includes the k-nucleotide benchmark program, which relies on Goroutines in the Go implementation to compute the results. The JavaScript version also runs concurrently, thanks to the Node.js runtime environment. The TypeScript version, on the other hand, has to perform all the computations one after the other and is therefore slower than the JavaScript and Go implementations. The SLE study reveals unsurprisingly that TypeScript uses 17 times more energy than the almost identical JavaScript.

Parallel calculations mean power savings for a program. A similar thing happens if a process needs to actively wait for an action to finish. For example, if a client polls a non-responsive server at short intervals, this causes power consumption. Callback functions or push messages ensure greater efficiency. The program sleeps until the computed data or an event wakes it up. Go supports this approach through its channels and with listeners from the net package in network programming.

OCIS consists of numerous microservices, each of which performs a clearly defined task. According to Freitag, communication between the services is responsible for most of the cost in terms of performance and, in-turn, energy. For example, if two microservices constantly send requests to each other, this game of ping-pong drives up energy consumption. The electricity bill also increases if all connected systems have to apply new settings. For example, if several services need to be informed of a change in authorizations, numerous messages will inevitably cross the network, and these messages need to be coordinated and evaluated. Consequently, you can save energy in distributed systems with a reduced communication frequency.