Energy-Languages

Looking at the benchmark where C++ is worst compared to other languages, it's depending on the library used. I would guess if they used Google's re2 Regex library instead of Boost's, the result would be different. https://github.com/google/re2 https://github.com/greensoftwarelab/Energy-Languages/blob/ma...

Trawling through the wayback machine, I did find that the older pages link to https://github.com/greensoftwarelab/Energy-Languages, which does seem to provide the contents of the specific programs used and the benchmarking software. Excellent.

> … not … primarily an issue with means vs medians We're comparing averages, why would we bother so much about the cause of an outlier. > you linked directly to the C++ code for spectral-norm You had linked to the wrong C and C++ code for spectral-norm, I linked to the code that was actually used. > The time ratio of the Benchmarks Game fastest C version to the slowest C++ version is over 16x. Again, you seem to be looking at the wrong repo. The authors of "Energy Efficiency across Programming Languages, SLE’17" provided this repo — https://sites.google.com/view/energy-efficiency-languages https://github.com/greensoftwarelab/Energy-Languages

You seem to be looking at the wrong source code. The "Energy Efficiency across Programming Languages, SLE’17"authors provided this repo — https://github.com/greensoftwarelab/Energy-Languages/blob/ma... https://github.com/greensoftwarelab/Energy-Languages/tree/ma... For a single outlier (regex-redux) there's a 12x difference between the measured times of the selected C and C++ programs. Even so, that mostly messes up the results because the arithmetic mean is used rather than the median. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

> with typing syntax Programs that didn't type check were excluded. https://github.com/greensoftwarelab/Energy-Languages/issues/...

One of the JavaScript programs at least was concurrent, whereas the TypeScript equivalent was synchronous. No wonder there's a difference... Haven't looked closely at the other problems, but it's apparent to me that the solutions are not even trying to be similar, so comparing their efficiency is near useless. the problem in question was the k-nucleotide one, IIRC: https://github.com/greensoftwarelab/Energy-Languages/blob/13...

The code from this study is here: https://github.com/greensoftwarelab/Energy-Languages From looking at the code snippets, a big issue with this study becomes clear - it doesn't reflect how languages like Python are used in practice. In practice, the "hot loops" of Python are in c/c++/fortran/cython/numba/... i.e. Python code usually makes use of a vast ecosystem of optimized science/maths/data science libraries. Whereas the study code is mainly using pure Python. It's an issue with the methodology that the programs are written specifically for this study; creating an artificial situation.

https://github.com/greensoftwarelab/Energy-Languages/blob/ma... https://github.com/greensoftwarelab/Energy-Languages/blob/ma... It feels like you are arguing in bad faith.

> Your "painstakingly optimized with SIMD" doesn't apply much to those 4 year old programs. What's this then? https://github.com/greensoftwarelab/Energy-Languages/blob/ma... There are some explicit SIMD instructions, and some programs written to allow autovectorization. > Never throw the baby out with the bath water. /eyeroll There's no baby. There's no significant investment in applying equal levels of optimizations to the programs across languages. TypeScript vs JavaScript is a telling example but hardly the only one.

> > It's based on The Computer Language Benchmarks Game… > It's based on these 4 year old programs —https://github.com/greensoftwarelab/Energy-Languages Yes, that repo's blurb confirms what I said: "The complete set of tools for energy consumption analysis of programming languages, using Computer Language Benchmark Game" If you were making some other point, I missed it. As for the programs being four years old, the paper was published in 2017, so that's exactly as expected... > > … no one bothered to cp fast-solution.js fast-solution.ts. > Perhaps figuring out correct type annotations was too much of a barrier. Sure, the details don't interest me. The point is that these two languages with identical compilers (TypeScript gets translated to JavaScript, discarding you're annotations) show wildly different scores, which makes it impossible t

> Otherwise I can't explain… They provided the source code of their programs and makefiles. There's no need for guessing games — https://github.com/greensoftwarelab/Energy-Languages

> It's based on The Computer Language Benchmarks Game… It's based on these 4 year old programs — https://github.com/greensoftwarelab/Energy-Languages > … the same program ported to N languages… You can write Fortran in any language ? ---- > … no one bothered to cp fast-solution.js fast-solution.ts. Perhaps figuring out correct type annotations was too much of a barrier.

> Many of the solutions there… You are looking in the wrong place. Here are the 4 year old programs used in the "Energy Efficiency across Programming Languages" study — https://github.com/greensoftwarelab/Energy-Languages > … nobody would write code like that… When you tell us you wouldn't, we should all believe you. When you tell us nobody would, we should ask how you know.

Compilation takes place before measurement — fannkuchredux.go https://github.com/greensoftwarelab/Energy-Languages/blob/5c... fannkuchredux.java https://github.com/greensoftwarelab/Energy-Languages/blob/5c...

Nope — https://github.com/greensoftwarelab/Energy-Languages/blob/5c...