Live data from Hacker News

Energy Efficiency Across Programming Languages

sites.google.com

1–10 of 143 posts

Re: Energy Efficiency Across Programming Languages

#2
According to their normalized "global" results, something interesting i see:

1. Pascal, surprisingly, the most memory efficient of all. I should take a look at the implementation they used.

2. Rust a good alternative to C which leads in "energy efficiency" and speed.

3. Common Lisp most energy-efficient and fastest and smallest memory footprint of all the dynamic programming languages in the list -- like Python, Ruby, Lua, Perl, and even Racket (which fares pretty well)

4. PHP, JRuby, Ruby, Typescript, Perl, Python, being massively slow than the fastest languages, for example Ruby being 59 times slower than Rust or C.

I agree that these languages (in item 4) are "acceptably fast" for many applications, but we can't say they are "close to the speed" of the fastest languages, even more if we consider the fastest dynamic+interactive languages like Lisp (Python being 21 times slower than Lisp.)

5. I wonder which implementation of Lua they used. Lua can be pretty fast, one of the fastest dynamic languages out there.

Re: Energy Efficiency Across Programming Languages

#6
post #2

According to their normalized "global" results, something interesting i see: 1. Pascal, surprisingly, the most memory efficient of all. I should take a look at the implementation they used. 2. Rust a good alternative to C which leads in "energy efficiency" and speed. 3. Common Lisp most energy-efficient and fastest and smallest memory footprint of all the dynamic programming languages in the list -- like Python, Ruby…

I have noticed a significant speedup using LuaJit, similar to PyPy compared to normal Python. I'm guessing if LuaJit & PyPy were used, the performance for Lua & Python would be similar to JS in these results.

Re: Energy Efficiency Across Programming Languages

#7
I see they monitor a complete process lifetime, not just the active workload. A quick grep of the paper didn't turn up anything discussing this. And it would seem to hurt dynamic languages and runtime-JIT languages a lot. Perhaps the active workload takes long enough that the transient is washed out. Anyone have insights?
Post reply on HN