According to their normalized "global" results, something interesting i see:<p>1. Pascal, surprisingly, the most memory efficient of all. I should take a look at the implementation they used.<p>2. Rust a good alternative to C which leads in "energy efficiency" and speed.<p>3. Common Lisp most energy-efficient <i>and</i> fastest <i>and</i> smallest memory footprint of <i>all</i> the dynamic programming languages in the list -- like Python, Ruby, Lua, Perl, and even Racket (which fares pretty well)<p>4. PHP, JRuby, Ruby, Typescript, Perl, Python, being <i>massively</i> slow than the fastest languages, for example Ruby being 59 times slower than Rust or C.<p>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.)<p>5. I wonder which implementation of Lua they used. Lua can be pretty fast, one of the fastest dynamic languages out there.
I can't believe they used the Computer Language Benchmarks Game. Those benchmarks don't reflect real-world workloads at all, and the contest has fairly arbitrary rules about implementations and widely differing implementation quality between languages. This should have been rejected by peer review.
For a bunch of years i was writing in Java and driving V8. Now i'm back to native (C++) and am driving Prius these days. I guess that it is my eco-consciousness that is making me shudder in disgust every time i look at Python... pretty much the same way like when looking at Hummers. While of course i love Perl, an M1 Abrams which gets things done despite anything :)
A real shame that Forth wasn't included in the tested languages. Chuck Moore has been an advocate for more energy efficient computation for a while now.
Note: The PDF of the paper has the a lot more detailed listing of the results (with graphs, explanation, etc) than the results web page: <a href="http://greenlab.di.uminho.pt/wp-content/uploads/2017/09/paperSLE.pdf" rel="nofollow">http://greenlab.di.uminho.pt/wp-content/uploads/2017/09/pape...</a>
Rust is fairly competitive with C, but it's memory use was 50 percent higher. I bet if they focus on getting the memory usage down it will perform better too.
I'm kinda surprised to see Go score so low on some of these, given that it's AOT-compiled to native code, and that its memory model and safety guarantees are optimization-friendly.<p>I'm also kinda surprised that OCaml scored that high, considering how high-level it is.
On of the things with the C set is they didn't use Intel's icc. On our main application (which involved a lot of heavy duty number crunching) it speeds up our application by 100% over the best we can get out gcc.
I'm suprised at the Java-C# comparaison. When are this numbers from?<p>The following blogspot explains how the author improved C# implementations after seeing defavorable C# results.<p><a href="https://anthonylloyd.github.io/blog/2017/08/15/dotnetcore-performance" rel="nofollow">https://anthonylloyd.github.io/blog/2017/08/15/dotnetcore-pe...</a>
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?
I'd love to see some scatter plots of CPU-time and energu-time, I expected a fairly linear correlation but there looks to be quite a lot of outliers, some but not all are explained with parallelism. Memory seems all over the place too.