Not all programming languages are created equal

[Case Study on the Energy, Execution Time, and Memory Triptych]

It’s no surprise: spending time in the specification phase is essential to designing a high-performance and efficient electronic product. When it comes to embedded software, these electronic products—driven by that very software—will behave quite differently depending on the programming language chosen. This choice of language can (and should!) be addressed during the specification phase.

Of course, the choice may differ between the prototyping phase and the product deployment phase. One may select a language with a high level of abstraction to prototype quickly and effectively, then move toward a more performant language once the prototype stage is complete. However, with more and more languages available to developers, choosing the right one is far from simple.

And to make the developers’ task even harder, the popularity of programming languages itself changes (sometimes drastically) from one year to the next. For example, to observe the trends, we can refer to the study by RedMonk [1], updated every year using GitHub and Stack Overflow data. Still, we can see that some factors significantly influence the choice of language: the constraints applied to the product, developer expertise (or preferences 😉), development speed—since development time in embedded projects is often seen as the most significant constraint—or even security aspects (with certain languages excluded because memory management falls to the developer).

Choosing the Language Based on the Triptych

‍

One thing is certain: the choice of programming language impacts the performance of the application—namely the triptych of execution time, memory, and energy—thus impacting the product itself. That said, let’s be honest: a good language will not save poorly optimized code.

So, the real question is: how can we make a choice and compare different languages across these three aspects? The comparison is tricky, because you have to compare like with like, and the benchmarks implemented in different languages must be implemented in an “equivalent” way. While there are frustrations around this, most studies converge toward the same conclusion.

Take this study [2], for example, which measured the performance of different benchmark implementations across 27 programming languages. The benchmarks used came from The Computer Language Benchmark Game [3], a reference framework that enables fair comparisons across languages. Strict implementation rules are required for each benchmark to ensure fairness. After all, a maliciously anti-C++ developer could make a C++ implementation deliberately slower than Python 😉 (Oops, spoiler alert on the study’s results).

One of the goals of the study was to determine whether focusing on languages that improve execution speed also has a positive effect on energy consumption. Memory aspects were also evaluated, in particular by measuring peak memory usage. For energy consumption measurement, Intel’s RAPL tool was used. This tool allows for very precise energy measurement of a program (more on that later!). Each metric was averaged over ten runs to smooth out cache initialization effects.

The study was published in 2017 (so experiments were likely conducted earlier), which explains the processor used at the time: an Intel(R) Core(™) i5-4460 (Haswell, Ubuntu 16.10, 16GB RAM, 3.20 GHz)—the crème de la crème back then.

The different programming languages considered in this study are classified according to various paradigms:

• Functional: using functions to structure code, with possible links between functions and the ability to pass some functions as parameters to others. This programming paradigm closely resembles mathematical functions (e.g., Ocaml, Perl, Rust…).
• Imperative: describing a precise sequence of instructions to enable state changes (e.g., Ada, C, C++, Go, Rust…).
• Object-Oriented: defining and interacting with software building blocks known as objects. Each object has its own internal structure and can interact with other objects (e.g., Ada, C++, Java, Python…).
• Scripting (e.g., JavaScript, Python, Perl…).

Analyzing Energy, Execution Time, and Memory

‍

The study aimed to analyze the triptych of energy consumption, execution time, and memory, and the relationships between them. The ultimate goal was to propose a guide to help developers choose a programming language based on their primary constraint—whether it’s memory, energy, or execution time.

At first glance, the mathematical link between energy consumption and execution time can be misleading, leading one to believe that optimizing for execution time automatically optimizes for energy consumption.

Why? Because the relationship is as follows:

E = P × t

Where:

• E is energy (in Joules),
• P is power (in Watts),
• t is time (in seconds).

If power remains constant, this relationship holds true. But that is not always the case (hello, Dynamic Voltage Frequency Scaling 👋🏻). This makes the study even more interesting, as it shows whether both metrics really evolve in the same direction.

And so… drum roll! The study’s results indicate that compiled languages are, on average, the fastest and most energy-efficient. Regarding the top 5 languages for execution time and energy efficiency, we find C, Rust, C++, Ada, and Java (the only non-compiled language in the list).

Language Choice Impacts Application Performance

As you know, at WedoLow, we’re big fans of C and C++. In terms of popularity, these languages (alongside C#) also remain in the top 5 despite Python’s overwhelming rise.

And speaking of Python—it also ranks in the top 5… of the most energy- and time-consuming languages. The study also examined where most of the energy goes during execution, and it’s still primarily the CPU (with the rest attributed to dynamic memory). Another key finding is that rankings shift depending on the metric being analyzed, meaning there is no single “best” language overall—it always depends on the chosen criterion.

Conclusion: Toward Eco-Design in Software

At WedoLow, we firmly believe that the choice of language strongly impacts application performance.

In the context of eco-design, it’s essential to keep these performance trade-offs in mind and make informed decisions from the specification phase. This approach not only improves efficiency but also reduces the environmental footprint of software systems.

📩 Want to discuss your technical constraints?
Contact our team of experts: sales@wedolow.com

References

[1] RedMonk Top 20 Languages Over Time (2021)
[2] Pereira, Rui, et al. Energy efficiency across programming languages: how do energy, time, and memory relate? Proceedings of the 10th ACM SIGPLAN International Conference on Software Language Engineering. 2017.
[3] Gouy, Isaac. The Computer Language Benchmarks Game. 2017. http://benchmarksgame.alioth.debian.org