Not All Languages Are Equal

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

It’s no secret that spending time in the specification phase is essential to designing a powerful and efficient electronic product. When it comes to embedded software, these electronic products, driven by the same software, will behave very differently depending on the chosen language. This choice of language can (and must!) be addressed during the specification phase. Of course, this choice may differ between the prototyping and product deployment phases. You may choose a language with a high level of abstraction for efficient and rapid prototyping, but then switch to a more powerful language once the prototype phase is over. Nevertheless, more and more languages are being offered to developers, and choosing a language is not so easy when faced with such diversity.

And to spice things up, the popularity of languages themselves changes (sometimes dramatically) from one year to another. To keep up with the trends, you can consult the RedMonk[1] study, which is updated every year with data collected from GitHub and Stack Overflow. However, we can see that certain factors have an impact on the choice of language, in particular the constraints applied to the product, the developers (more or less trained in certain languages, or more or less fond of certain languages 😉), the speed of development depending on the language, as the development time of projects, especially embedded ones, is perceived as being the strongest constraint, or even security aspects (with a choice that may exclude certain languages for which memory management is a task assigned to the developer).

Select the language according to the triptych.

One thing is for sure: the choice of language has an impact on the performance of the application in question, i.e. the triptych of execution time, memory, and energy, and thus on the product designed, even if, let’s face it, a good language does not save unoptimized code. So the question is, how can we choose and compare these different languages according to these three aspects? Comparisons are tricky indeed, because you must compare the comparable, and the benchmarks implemented in the different languages have to be implemented in an “equivalent” way. Many people are unhappy about this, but the various studies point to the same conclusion…

Using this study [2]as an example, the work was done by measuring the performance of different benchmark implementations across 27 languages. The benchmarks chosen are part of The Computer Language Benchmark Game [3](CLBG), a reference set of benchmarks to be used to make these comparisons between different languages. For each benchmark implemented, strict implementation rules must be followed to ensure a fair comparison. Indeed, I’m sure that an ill-intentioned anti-C++ developer could make a C++ implementation of a code much slower than Python 😉 Oops, I’m spoiling the results of the study. One of the goals of this study was to determine whether focusing on languages that improve code execution speed also has a positive impact on energy consumption. Memory issues were also considered in this study, in particular by measuring peak memory usage. RAPL, the tool proposed by Intel, was used to measure energy consumption. It allows a very detailed measurement of a program’s energy consumption, but more on this tool in a moment! Each measurement was based on an average of ten executions of each implementation to mitigate the effects of caching at initialization. Since the article presenting this study was published in 2017 (and so the experiments were certainly done before then), you’ll have to excuse the processor used at the time, which was an Intel(R) Core(™) i5-4460 (Haswell, Ubuntu-like OS 16.10, 16GB RAM, 3.20 GHz), the crème de la crème at the time.

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

• functional: the use of functions to structure code, with possible links between different functions and the possibility of passing some functions as parameters to others. This programming paradigm is very similar to functions in the mathematical sense (e.g. Ocaml, Perl, Rust…).
• imperative: description of a precise sequence of instructions to allow state changes (e.g. Ada, C, C++, Go, Rust…).
• object-oriented: definition and interaction between software components that are objects. An object has its own internal structure and can interact with other objects (e.g. Ada, C++, Java, Python…).
• script (for example, JavaScript, Python, Perl…).

Analysis of the triptych energy consumption, execution time, memory.

One of the objectives of this study was to analyze the triptych of energy consumption, execution time, memory and the various links between these three parameters. The ultimate goal of this study was to be able to offer a guide that would allow developers to choose their programming language according to their constraints, be they memory, energy or execution time.

When you look at the mathematical connection between energy consumption and the execution time of software applications, it’s easy to think that optimizing for execution time means optimizing for energy consumption.

But why? Because the relationship is:

                                                                           E  =  P  x  t

where,

• E is energy in joules,
• P is power in watts,
• t is time in seconds.

In fact, if the power is constant, this relationship holds. But this is not necessarily the case (hello, dynamic voltage-frequency scaling!). The study is therefore all the more interesting in that it shows whether the two evolve in the same direction or not!

And so… Tadam! Drum roll! The results of this study show that compiled languages are, on average, the fastest and most energy efficient. The top 5 languages in terms of execution time and energy efficiency are C, Rust, C++, Ada, and Java (the only non-compiled language).

Language affects application performance.

As you know, we at WedoLow are big fans of the C and C++ languages. In terms of popularity, these languages (along with C#) remain in the top 5, despite the overwhelming emergence of Python.

Let’s talk about Python. It’s also in the top 5… for languages that consume the most execution time and energy. The analysis was also done to determine what consumes the most energy in the execution of these programs, and it’s always mainly the CPU (the rest is consumed by dynamic memory). What can also be seen from this study is that the ranking of languages is not necessarily maintained according to the criterion analyzed, so we can say that there is indeed a specific ranking to be considered according to the criterion analyzed.

And, of course, we at WedoLow argue for our cause. We’re convinced that the choice of language has a major impact on the performance of an application. In a trend towards eco-design, it’s important to keep these performance scales in mind to make informed choices at the product/software specification stage.

Contact our team of experts to discuss the subject: sales@wedolow.com

[1] https://redmonk.com/kfitzpatrick/2021/03/02/redmonk-top-20-languages-over-time-january-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.” URL http://benchmarksgame. alioth. debian. org (2017).