
Energy Efficiency in Programming Languages - ingve
https://github.com/greensoftwarelab/Energy-Languages#energy-efficiency-in-programming-languages
======
winter_blue
Previous discussion on HN, 3 days ago:
[https://news.ycombinator.com/item?id=15249289](https://news.ycombinator.com/item?id=15249289)

------
exabrial
I've always suspected using "like really productive" languages creates it's
own scalability problem in production. Ruby/Python/Node/PHP consuming anywhere
from 2x to 15x the amount of energy and time as a language like Java/C# comes
as no surprise, which likely means you'll need a corresponding increase in
servers for particular use cases.

What's not a surprise is C stomping everything with a lead boot. I _am_
surprised that Fortran is a lower than it is (considering its role in
HPC/research). It's no surprise to see Java leading the virtual machine pack
on speed, I thought it'd take a larger hit on energy consumption due to JIT.

But Rust, WOW. Have we finally created the perfect language? Always something
I've wanted to learn, now I think I have a good reason!

------
kilovoltaire
Here's the paper - [http://greenlab.di.uminho.pt/wp-
content/uploads/2017/09/pape...](http://greenlab.di.uminho.pt/wp-
content/uploads/2017/09/paperSLE.pdf)

 _On average, compiled languages consumed 120J to execute the solutions, while
for virtual machine and interpreted languages this value was 576J and 2365J,
respectively._

~~~
melling
Does this mean for mobile devices like phones, tablets. watches, VR/AR
headsets, etc, would should prefer compiled languages?

~~~
darkhorn
Linux and Darwin is written with C. They are the OSs of Android and iOS.

But would be nice to have some mobile apps written with C.

~~~
mpweiher
Lots of mobile apps are written in Objective-C, and Objective-C is C. A
superset of C to be exact.

Since it's a single hybrid language, it's trivial to remove slower features
fro, performance-intensive parts.

See my UIKonf talk
[https://www.youtube.com/watch?v=kHG_zw7%205SjE&feature=youtu...](https://www.youtube.com/watch?v=kHG_zw7%205SjE&feature=youtu.be)

Or my book:
[https://www.amazon.com/gp/product/0321842847/ref=as_li_tl?ie...](https://www.amazon.com/gp/product/0321842847/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=0321842847&linkCode=as2&tag=metaobject-20&linkId=4f7c355096938fece9d7c880e6916ce8)

------
majewsky
Before all of you go out taking these results as definite truth, remember that
a language benchmark is only as good as the particular implementations. A
$LANGUAGE fanboy can easily game the benchmark by overoptimizing the $LANGUAGE
implementations into unmaintainable atrocities that perform extremely well,
thus making people think that average $LANGUAGE programs will exhibit the same
performance/efficiency/resource usage characteristics.

There's no easy way to guard against this problem when you're only a handful
of researchers. If you have a large team with a background in a lot of
languages, you can have them write and peer-review implementations that are
idiomatic (i.e. representative of the language's practical usage).

~~~
mjburgess
And before you all go out taking the possibility of scepticism as an actual
motivation to be sceptical, remember that conclusions do not need to be proven
beyond all doubt to be reasonably believed.

------
mrks_
It's nice to see that some newer languages like Rust and Swift are performing
well!

~~~
teamhappy
Well, Rust and Go are performing very well. Swift performs worse than
languages like Java, Haskell, OCaml, C# and Lisp.

\-- Edit --

My bad, I only looked at the paper. The results
([https://sites.google.com/view/energy-efficiency-
languages/re...](https://sites.google.com/view/energy-efficiency-
languages/results)) show that Swift and Go are doing about as well as Java.
(Which means they're right behind C, C++, Rust and Fortran).

~~~
jws
The summary results for Swift do not reflect the individual tests. There is a
single anomalous test, reflex-redux, where the Swift implementation sucks
badly.

Anecdotally, Swift string handling makes it easy to do the right thing when
handling Unicode strings, but also makes it easy to burn up several orders of
magnitude too much CPU when you use those functions for simple tasks. I once
saved three orders of magnitude clock time by dropping to POSIX IO and C run
time library string handling for an application that needed to read a text
file containing 10000 lines of 81 digits at launch and process them as single
digits.

------
CalChris
I don't intuitively understand why Go was so space efficient (#2 and ahead of
C) but then so time+energy inefficient wrt C (3.23 and 2.83 vs 1.00 and 1.00).

Any clues?

~~~
Lev1a
My guess would be that Go's GC (which is supposedly pretty good) takes care of
space but pushes up time and CPU usage anyway.

~~~
iainmerrick
No, GC shouldn't take that much time.

~~~
Lev1a
I assume it just adds up in these kinds of "benchmark" tests.

------
noipv4
I hope C/C++ programming picks up again.

~~~
xfer
Picks up? C/C++ never went anywhere(except you know web stuff).

