Energy Efficiency Across Programming Languages

Post by igouy » Sat, Sep 16, 2017, 4:50 PM UTC

mncharity wrote: post #87

fnord123 wrote: post #31

Earlier quoted context omitted.

The tests come from the benchmark game. If you want to see Forth, implement the tests in Forth: http://benchmarksgame.alioth.debian.org/

@igouy points out that while the old shootout site is gone, its language files are still available[1]. There are about 70 benchmarks, in about 70 languages. I remember them as interesting multilingual browsing. Unlike the old shootout, adding languages directly to benchmarksgame.alioth.debian.org is not an option. "Because I know it will take more time than I choose. Been there; done that."[2] :) Instead, the code is…

Post by igouy » Sat, Sep 16, 2017, 5:02 PM UTC

etiene wrote: post #107

flavio81 wrote: 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…

> 5. I wonder which implementation of Lua they used. Lua can be pretty fast, one of the fastest dynamic languages out there. Apparently 5.3, but I am very skeptical of these results. Also the way the data is organised is very weird. One should not compare a JIT compiled VM (JavaScript) with interpreters (Lua, Python, Ruby...). An honest approach would have used LuaJIT, PyPy etc. or separated the languages into "famil…

Post by igouy » Sat, Sep 16, 2017, 5:56 PM UTC

rbehrends wrote: post #108

kllrnohj wrote: post #81

Earlier quoted context omitted.

> Obviously, I can construct real-world programs with pretty much arbitrary allocation rates, but especially performance-sensitive code will avoid that, if only because it hurts memory locality. That's not actually true at all. Games, for example, can have high allocation rates. But they use custom allocators to make those allocations extremely cheap using things like arena allocators for the allocations for a frame.…

> It's not apples vs. oranges at all, though. It's "how can you solve this problem in the optimal way on any given language" And for any synthetic microbenchmark, that's unlikely to reflect real-world workloads, as they tend to narrowly test just one aspect of the language (or rather, its implementation). Remember, we're talking about a peer-reviewed paper here, where the burden to show relevance is upon the authors.…

Post by int_19h » Sat, Sep 16, 2017, 11:40 PM UTC

tyoverby wrote: post #117

int_19h wrote: post #73

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. I'm also kinda surprised that OCaml scored that high, considering how high-level it is.

OCaml has an incredible optimizer, and many of the abstractions that one would use in OCaml are transparent to the optimizer. You could say the opposite about Go.

Post by etiene » Mon, Sep 18, 2017, 8:51 AM UTC

igouy wrote: post #123

etiene wrote: post #107

Earlier quoted context omitted.

> 5. I wonder which implementation of Lua they used. Lua can be pretty fast, one of the fastest dynamic languages out there. Apparently 5.3, but I am very skeptical of these results. Also the way the data is organised is very weird. One should not compare a JIT compiled VM (JavaScript) with interpreters (Lua, Python, Ruby...). An honest approach would have used LuaJIT, PyPy etc. or separated the languages into "famil…

> … but the ones in Lua weren't. Why? No mystery: someone has made the effort to contribute all those multi-process Python programs; no one has made the effort to contribute all those multi-process Lua programs.