ES version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
72% Positive
Analyzed from 1902 words in the discussion.
Trending Topics
#language#energy#lua#more#code#python#ruby#languages#efficient#should
Discussion (45 Comments)Read Original on HackerNews
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.
And here is a repository with a compiler backend to generate LuaJIT bytecode and other useful tools: https://github.com/rochus-keller/ljtools/
A bit broader: I wonder how strong typing can save energy! Maybe it makes compiling more energy consuming, but a bug in production costs a lot more energy than a few extra rounds of compiling.
Very hard to get data on. But would totally change the ranking of proglangs by "efficiency".
I love C, but the shear amount of CVE and crashes are much worse in terms of global energy usage than if it were safe. I imagine the strongest strong-typing ranking that can be saved would come from Swift, where Rust's compile time would tank its ranking...
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:
(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.
Unfortunately it has continued to make the rounds for about a decade now and gets re-posted every year or so.
I'm not an expert on the internals of typescript. But your comment doesn't indicate you are an expert either.
Equivalant service in Java idles around 400mb of ram when Go service might use 70mb.
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.
Maybe a nit pick. But this isn't a basis to say you can't compare the code. The 'average' code is going to be somewhere between your two extremes. Assuming on average, the code was written by the average programmer, you can get an insight in to what the average programmer of a programming language should expect.
Now it may be that populations of programmers favour different things (speed, memory usage, ease of implementation) but that still forms a valid comparison.
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.
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?
The interpreter keeps track of globals and all stack frames. So it knows what objects are in scope.
If you're creating an object that can contain native ruby values inside it's own opaque structure, then when you define the class that wraps this structure you reference the callback functions you want to be called during GC mark and when the GC frees your object. During the mark callback you simply call rb_gc_mark on any of those internal values so the GC knows they are in scope.
In practice it's quite easy to use and you can find many examples of this. There is no equivalent I'm aware of to mark in lua, but the free callback is effectively equivalent to the __gc metamethod.
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...
https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/pap...
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.
Spend Gigawatts running data centres for LLMs.
2) There exist many, many more client devices than datacenters. And
3) Expect software on client devices to be generally less optimized than software deployed in datacenters.
In other words: measure, and do the math. And ofc Jevons' paradox may apply.
But anyway it'll devolves pretty quickly into a fallacy where you shouldn't do anything because your neighbour is a bigger problem (forget the name).
I have been compiling a list of papers that have titles with this kind of style.
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.
if you want to look at the real waste of power just open up some electron app. no good reason why we still use it for new apps in 2026 when gpui and avalonia and tauri are all options
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.
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 ..