Energy-Languages VS rust

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

The esp-template issue might be this one: https://github.com/esp-rs/rust/issues/158. Try with --release or updating to 1.68.0 with espup update. I'll take a look at the log as soon as I can, atm Im on the phone and is not that easy to scroll through :(

Sure. Espressif maintains a fork which adds support for their microcontrollers.

I am trying to make a vaccine passport validation for my country using the ESP32 for my micro controller. I have gotten the std rust library to compile using (esp-rs)[https://github.com/esp-rs/rust], but the actual validation library that I use needs openssl which refuses to compile.

Xtensa. They've got a fork of LLVM that supports it that they're working toward getting upstreamed. The community has a fork of rustc that uses it (and a quickstart crate) while we wait for it to get upstreamed.

It only works if you have an Xtensa compiler which takes hours to compile, here: Rust Xtensa (if you don't have it). The network driver is just a function that sets the name of the driver so the Esp32 does something other that blinking.