I don't know what this table is supposed to measure but it doesn't check out.
(C, C++) and (JS, TS) are almost source-compatible, chances are you can rename test.c to test.cpp and test.js to test.ts and you're done. Yet they're showing massive differences?
Also most of the compiled languages with no runtime should get results that are very close to each other: good compilers should produce similar object-code for this type of microbenchmark.
Not to mention this is really measuring the implementation, you can't measure a language. Mike Pall wouldn't be down there, and JS/TS wouldn't be up there without V8 and friends.
I imagine you would want to test "idiomatic" code for these comparisons. It doesn't make much sense to compile with C++ and write everything in C.
The methodology used in this paper was extremely bad. There is no reason there should be any disparity between a TypeScript and JavaScript benchmark.
Unfortunately it has continued to make the rounds for about a decade now and gets re-posted every year or so.
Any comparison with Lua that doesn't include LuaJit also shouldn't include any JavaScript (or rather, should test it with some super inefficient ancient runtime instead of V8)
Why didn't they include assembly? IMO this should be the benchmark, not C
Assembly has no idiomatic way to do things. Creating an optimized assembly comparison is another paper in itself.
I have to say I am surprised that Java is better than Go in terms of energy/time.
This paper is not really relevant, it's based on the "Computer Language Benchmark Game", so what it measures is a mix of the efficiency/speed of the language and the attention that practitioners of that language gave to the Computer Language Benchmark Games.
What is measured in that table is neither naive code nor the absolute limit you can reach with each language, which means you can't really then compare languages between themselves the way the paper implies.
I think picking professionals at random that practice those languages and ask them to write Computer Language Benchmark Games code would be maybe a bit more representative, but even there you face huge biases.
Interesting results. Particularly they barely found a speed-up of newer compared to older LuaJIT versions (rather the contrary). Maybe they should have used the Are-we-fast-yet suite instead of the (random looking) set of microbenchmarks. I did measurements of Lua and LuaJIT some time ago based on Are-we-fast-yet and saw significant differences in LuaJIT performance (see http://software.rochus-keller.ch/are-we-fast-yet_LuaJIT_2017...).
The nice thing about Lua is that it can easily be combined with compiled languages. If you identify the hot path in your program, you can implement them in a more efficient language.
The C interface to ruby is just superb. It provides a very simple and first class access to the entire runtime and all it's features. It's absolutely my favorite language to write extensions in.
Lua is probably my second favorite. It's marred by it's initial creation as a stack based interpreter and requires more calls and contortions to achieve the same effects as you would in any other language; however, once you understand a handful of useful primitives it's quite easy to intuit the correct set of calls for any use case.
The blend of dynamic language with underlying compiled extensions is vastly underappreciated. I suspect it has a lot to do with the difficulty of packaging and distributing these extensions into current virtualized and cloud environments. Which is a pity given the extreme combination of flexibility and efficiency that it otherwise unlocks.
> The C interface to ruby is just superb.
How does it handle garbage collection? AFAIK GC is the main reason behind Lua's stack-based API: it's designed so that C code never needs to hold a pointer to a Lua object, which means an object will never be garbage-collected while C code is still trying to use it.
OTOH Python does allow C code to hold such pointers - so it requires that code to perform error-prone manual reference-counting.
How does Ruby solve this problem?
Energy efficiency as a "my language is better than yours" point was not on my bingo card for 2026.
JIT as an energy saver intuitively makes sense, and is probably the model most languages need to think about for "shipping to prod". I'm aware Python has started developing this, and given the install base, it's encouraging that results like this show it could have significant benefits for users.
Save a few watts per device making the client-side code a bit more efficient.
Spend Gigawatts running data centres for LLMs.
Share this article on LinkedIn and you'll have countless managers talking about how they initiated a company wide policy to convert all Python scripts into Lua using Claude
As Earth stakeholders, saving watts is not just good business sense—it’s a Kantian imperative.
Most environmental chatter in a nutshell.
I'd like to see a study that compares Python and Ruby, against (1) Rust, (2) C, (3) C++, (4) Zig, (5) Go, (6) a JVM language (like Scala or Kotlin or Clojure), and (7) the main CLR language (C#).
I would imagine that all 7 of them absolutely trounce Python and Ruby.
Python and Ruby have been an immense environmental (and type safety) disaster.
JS though (via V8 and other engines) has been surprisingly fast. I've always wondered why Python and others couldn't copy some of the tricks V8 uses to be fast...
Energy Efficiency across Programming Languages:
How Does Energy, Time, and Memory Relate?
Is the title "The Green Side of the Lua" a pun/parodic allusion to something?
I have been compiling a list of papers that have titles with this kind of style.
Have you published the list yet?
Not yet, I will update you when I do.
I guess it alludes to “The Dark Side of the Moon”
“Lua” is “moon” in Portuguese, so it’s a reference to Dark Side of the Moon.
Ah - wonderful. Thanks
Is a paper that publishes a 0.01% improvement of something at the cost of 5 times more power really an improvement? I believe that every single computer science measurement metric should have Joules or Watts in the denominator. If you are training a model I want to see performance per total energy consumed. If you are measuring inference accuracy, measure PER WATT.
I've always been a bit confused by the apparent tendency of the computer science field to mostly ignore energy and power. We are too often satisfied with the idea that software and programs exist in a perfect whiteboard world of xkcd 505 abstract compute.
This kind of article keeps coming back, I've seen similar articles on LinkedIn where the bottom line is to switch from Python to C.
The reasoning, in a nutshell, is that if a language allows you to waste fewer CPU cycles, it is more energy efficient, hence greener.
This completely ignores the fact that such a language might be more difficult to master because it uses fewer higher abstractions; CPU efficient languages tend to be closer to the machine domain and further away from the mathematical and real world.
So while in theory the language lets you write very efficient code, you might well miss the opportunity and it could even be that using some off the shelve abstraction in a higher level language, your code would have been more efficient.
To drive that point to the extreme: the ultimate CPU efficient language is the language of the CPU itself: assembly. Try writing an efficient highly scalable webserver in assembly alone, good luck with that.
Then there is something else that all these articles conveniently ignore: development speed. Most of us write software for commercial enterprises. Product owners want the new feature tomorrow, not next year. They don't want a clever and amazingly fast application that might crash in production, they don't want security holes by missed buffer overflows.
Also, most of us work in a team where colleagues come and go, including yourself. Your colleagues won't be happy with you when you leave them some amazingly cleverly and efficiently written software that nobody understands or can maintain.
TL;DR; while all else being equal, the point of the article is true: it has little to no meaning in the real world. Yet, with phrasing like 'green languages', 'reduce the carbon footprint', these articles will catch on to an uninformed audience again and again.
As someone who has shipped Lua as a solution to many an embedded dilemma, this is highly interesting work.
I wonder if there will be motivation in the future to address energy consumption in future JIT work .. in fact I wonder whether other languages are going to face a similar optimization path. It would be grand to see progress being made on this at a more general scale. I'm looking at you, Python ..
This paper is relevant:
Energy Efficiency across Programming Languages: How Does Energy, Time, and Memory Relate?
https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/pap...
This is the main summary table:
I don't know what this table is supposed to measure but it doesn't check out.
(C, C++) and (JS, TS) are almost source-compatible, chances are you can rename test.c to test.cpp and test.js to test.ts and you're done. Yet they're showing massive differences?
Also most of the compiled languages with no runtime should get results that are very close to each other: good compilers should produce similar object-code for this type of microbenchmark.
Not to mention this is really measuring the implementation, you can't measure a language. Mike Pall wouldn't be down there, and JS/TS wouldn't be up there without V8 and friends.
I imagine you would want to test "idiomatic" code for these comparisons. It doesn't make much sense to compile with C++ and write everything in C.
The methodology used in this paper was extremely bad. There is no reason there should be any disparity between a TypeScript and JavaScript benchmark.
Unfortunately it has continued to make the rounds for about a decade now and gets re-posted every year or so.
Any comparison with Lua that doesn't include LuaJit also shouldn't include any JavaScript (or rather, should test it with some super inefficient ancient runtime instead of V8)
Why didn't they include assembly? IMO this should be the benchmark, not C
Assembly has no idiomatic way to do things. Creating an optimized assembly comparison is another paper in itself.
I have to say I am surprised that Java is better than Go in terms of energy/time.
This paper is not really relevant, it's based on the "Computer Language Benchmark Game", so what it measures is a mix of the efficiency/speed of the language and the attention that practitioners of that language gave to the Computer Language Benchmark Games.
What is measured in that table is neither naive code nor the absolute limit you can reach with each language, which means you can't really then compare languages between themselves the way the paper implies.
I think picking professionals at random that practice those languages and ask them to write Computer Language Benchmark Games code would be maybe a bit more representative, but even there you face huge biases.
Interesting results. Particularly they barely found a speed-up of newer compared to older LuaJIT versions (rather the contrary). Maybe they should have used the Are-we-fast-yet suite instead of the (random looking) set of microbenchmarks. I did measurements of Lua and LuaJIT some time ago based on Are-we-fast-yet and saw significant differences in LuaJIT performance (see http://software.rochus-keller.ch/are-we-fast-yet_LuaJIT_2017...).
I also compared different PUC Lua versions in an earlier measurement (see http://software.rochus-keller.ch/are-we-fast-yet_lua_results...) and found similar significant differences between versions.
The nice thing about Lua is that it can easily be combined with compiled languages. If you identify the hot path in your program, you can implement them in a more efficient language.
The C interface to ruby is just superb. It provides a very simple and first class access to the entire runtime and all it's features. It's absolutely my favorite language to write extensions in.
Lua is probably my second favorite. It's marred by it's initial creation as a stack based interpreter and requires more calls and contortions to achieve the same effects as you would in any other language; however, once you understand a handful of useful primitives it's quite easy to intuit the correct set of calls for any use case.
The blend of dynamic language with underlying compiled extensions is vastly underappreciated. I suspect it has a lot to do with the difficulty of packaging and distributing these extensions into current virtualized and cloud environments. Which is a pity given the extreme combination of flexibility and efficiency that it otherwise unlocks.
> The C interface to ruby is just superb.
How does it handle garbage collection? AFAIK GC is the main reason behind Lua's stack-based API: it's designed so that C code never needs to hold a pointer to a Lua object, which means an object will never be garbage-collected while C code is still trying to use it.
OTOH Python does allow C code to hold such pointers - so it requires that code to perform error-prone manual reference-counting.
How does Ruby solve this problem?
Energy efficiency as a "my language is better than yours" point was not on my bingo card for 2026.
JIT as an energy saver intuitively makes sense, and is probably the model most languages need to think about for "shipping to prod". I'm aware Python has started developing this, and given the install base, it's encouraging that results like this show it could have significant benefits for users.
Save a few watts per device making the client-side code a bit more efficient.
Spend Gigawatts running data centres for LLMs.
Share this article on LinkedIn and you'll have countless managers talking about how they initiated a company wide policy to convert all Python scripts into Lua using Claude
As Earth stakeholders, saving watts is not just good business sense—it’s a Kantian imperative.
Most environmental chatter in a nutshell.
I'd like to see a study that compares Python and Ruby, against (1) Rust, (2) C, (3) C++, (4) Zig, (5) Go, (6) a JVM language (like Scala or Kotlin or Clojure), and (7) the main CLR language (C#).
I would imagine that all 7 of them absolutely trounce Python and Ruby.
Python and Ruby have been an immense environmental (and type safety) disaster.
JS though (via V8 and other engines) has been surprisingly fast. I've always wondered why Python and others couldn't copy some of the tricks V8 uses to be fast...
Energy Efficiency across Programming Languages: How Does Energy, Time, and Memory Relate?
https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/pap...
Is the title "The Green Side of the Lua" a pun/parodic allusion to something?
I have been compiling a list of papers that have titles with this kind of style.
Have you published the list yet?
Not yet, I will update you when I do.
I guess it alludes to “The Dark Side of the Moon”
“Lua” is “moon” in Portuguese, so it’s a reference to Dark Side of the Moon.
Ah - wonderful. Thanks
Is a paper that publishes a 0.01% improvement of something at the cost of 5 times more power really an improvement? I believe that every single computer science measurement metric should have Joules or Watts in the denominator. If you are training a model I want to see performance per total energy consumed. If you are measuring inference accuracy, measure PER WATT.
I've always been a bit confused by the apparent tendency of the computer science field to mostly ignore energy and power. We are too often satisfied with the idea that software and programs exist in a perfect whiteboard world of xkcd 505 abstract compute.
This kind of article keeps coming back, I've seen similar articles on LinkedIn where the bottom line is to switch from Python to C. The reasoning, in a nutshell, is that if a language allows you to waste fewer CPU cycles, it is more energy efficient, hence greener.
This completely ignores the fact that such a language might be more difficult to master because it uses fewer higher abstractions; CPU efficient languages tend to be closer to the machine domain and further away from the mathematical and real world. So while in theory the language lets you write very efficient code, you might well miss the opportunity and it could even be that using some off the shelve abstraction in a higher level language, your code would have been more efficient.
To drive that point to the extreme: the ultimate CPU efficient language is the language of the CPU itself: assembly. Try writing an efficient highly scalable webserver in assembly alone, good luck with that.
Then there is something else that all these articles conveniently ignore: development speed. Most of us write software for commercial enterprises. Product owners want the new feature tomorrow, not next year. They don't want a clever and amazingly fast application that might crash in production, they don't want security holes by missed buffer overflows.
Also, most of us work in a team where colleagues come and go, including yourself. Your colleagues won't be happy with you when you leave them some amazingly cleverly and efficiently written software that nobody understands or can maintain.
TL;DR; while all else being equal, the point of the article is true: it has little to no meaning in the real world. Yet, with phrasing like 'green languages', 'reduce the carbon footprint', these articles will catch on to an uninformed audience again and again.
As someone who has shipped Lua as a solution to many an embedded dilemma, this is highly interesting work.
I wonder if there will be motivation in the future to address energy consumption in future JIT work .. in fact I wonder whether other languages are going to face a similar optimization path. It would be grand to see progress being made on this at a more general scale. I'm looking at you, Python ..
O lado verde da Moon.