Energy-Languages VS just

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

https://github.com/greensoftwarelab/Energy-Languages/issues/...

The paper authors provided a repo for the source code they used: https://github.com/greensoftwarelab/Energy-Languages

The study made their own measurements. They did not re-use measurements made by the benchmarks game.

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...

I've been trying to replicate a study on energy usage (alright, it's that study on energy usage) and I've hit a bit of a snag while trying to compile the Rust components of the project. Instead of using a Cargo.toml and building with cargo, the authors have decided to use a Makefile and manually pass flags into rustc.

Here is an issue from the repo with the code they used: https://github.com/greensoftwarelab/Energy-Languages/issues/34

just

https://github.com/just-js/just Is another for a V8 runtime, it really shows how well optimized it is. https://www.techempower.com/benchmarks/#section=data-r21

i just tried recompiling v0.0.2 (https://github.com/just-js/just/releases/tag/0.0.2) of just-js and comparing it to current. for the completely static build on ubuntu 22.04 i see following:

0.0.2 (v8 v8.4.371.18) - file size: 15.2 MB, startup RSS: 8.4 MB

Not at all. Javascript, as well as java compiled into the bytecode, but just incrementally and at the runtime. You cannot compile typescript into bytecode directly (at least it intend to be like that). You can even compile js to executable (https://github.com/just-js/just). So no, typescript transpiles to javascript, whereas scala compiles to bytecode, it's different things

Trust me, these guys are insane and go to really extreme levels and use optimization techniques which are not generally prevalent among the general programming fraternity. for eg, look at pico.v it is awesome and just-js is truly unbelievable, then there is faf, most of them combine low level programming trickery to reach those insane numbers. Also some of the code may not be useful in a production app but they actually extract the juice out of the metal at every instance. Memory optimizations, compiler optimizations, postgresql wire implmentations, rust black magic, these guys are really crazy and passionate.