Energy-Languages

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.