4 ms·

> You seem to have excluded the first part of that sentence: Sure, but they shouldn't repeat misinformation, regardless of if they used it for decision-making

> You seem to have excluded the first part of that sentence: Sure, but they shouldn't repeat misinformation, regardless of if they used it for decision-making or not. > How did you measure "representative"? Generally, I can't, but the CLBG solutions often rely on FFI, unsafe code, and hand-written SIMD intrinsics, which I don't use very much, and I am not aware of anyone who would for application programming.

igouy 4y ago
> … misinformation… Please quote the author's words which you say are misinformation — so we don't waste time guessing what you mean — and then explain what you think is wrong. > … often rely on FFI, unsafe code, and hand-written SIMD intrinsics… That wording seems to be copied from the current benchmarks game website but the author is talking about a 2017 study. What you say has to be about what was used by that independent study 5 years ago, not about whatever the benchmarks game website shows today.
- hayley-patton 4y ago
  > TypeScript is apparently far more energy-hungry (and we're not likely to use pure JavaScript). The implication, I believe, is that plain JavaScript is more energy efficient than TypeScript, which is what was reported in the paper. But this is a very odd observation, as TypeScript generates normal JavaScript code, which would be run on the same JavaScript implementation. > That wording seems to be copied from the current benchmarks game website but the author is talking about a 2017 study. I wrote that wording myself, so I guess I got lucky if it's the same as what's on the benchmarks game website. But that was my observation some years ago. It seems pertinent for the state of CLBG in 2017 too: https://web.archive.org/web/20170526092655/http://benchmarksgame.alioth.debian.org/u64q/program.php?test=pidigits&lang=java&id=2 https://web.archive.org/web/20170526092655/http://benchmarks... just FFIs out to GNU MP. https://web.archive.org/web/20170619103241/http://benchmarksgame.alioth.debian.org/u64q/program.php?test=mandelbrot&lang=sbcl&id=1 https://web.archive.org/web/20170619103241/http://benchmarks... uses "inline assembly" of a sort, and disables safety checks entirely.
  - igouy 4y ago
    > The implication, I believe, is that plain JavaScript is… No, the author actually tells us the reason — "And, we could well have chosen JavaScript for our Node.js code, though we're not likely to do this due to TypeScript being much more convenient to work with by comparison." Given the title is "We're choosing Rust, and not Go, C++, or Node.js" the plain reading was always that "TypeScript is apparently far more energy-hungry" than Rust, Go, C++. > … the state of CLBG in 2017… The author does not mention the benchmarks game. What you say has to be about what was used by that independent study 5 years ago, not about whatever the benchmarks game website showed 5 years ago.
    - hayley-patton 4y ago
      > What you say has to be about what was used by that independent study 5 years ago, not about whatever the benchmarks game website showed 5 years ago. The study tested the benchmarks game programs. Page 2 of the paper [0] explicitly states "our case study to analyze the energy efficiency of software languages is based on the CLBG" and proceeds to describe the programs tested. [0] https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sle...
      - igouy 4y ago
        That could be relevant if the study tested every one of the programs shown on the benchmarks game website on some particular day. In other words if the set of programs tested by the study was identical to the set of programs shown on the benchmarks game website. Does the paper claim that?
        hayley-patton 4y ago
        There is a list of benchmarks used; including the Mandelbrot and pidigits benchmarks I cite. They also claim "they gathered the most efficient (i.e. fastest) version of the source code"; and I cited the fastest programs. This is legitimately painful to discuss, as this information is readily available in the paper, and seemingly we are getting nowhere by picking at how I made my observations; so I am going to do something more enjoyable, somewhere very far away from you.

igouy 4y ago

> … misinformation… Please quote the author's words which you say are misinformation — so we don't waste time guessing what you mean — and then explain what you think is wrong. > … often rely on FFI, unsafe code, and hand-written SIMD intrinsics… That wording seems to be copied from the current benchmarks game website but the author is talking about a 2017 study. What you say has to be about what was used by that independent study 5 years ago, not about whatever the benchmarks game website shows today.

hayley-patton 4y ago
> TypeScript is apparently far more energy-hungry (and we're not likely to use pure JavaScript). The implication, I believe, is that plain JavaScript is more energy efficient than TypeScript, which is what was reported in the paper. But this is a very odd observation, as TypeScript generates normal JavaScript code, which would be run on the same JavaScript implementation. > That wording seems to be copied from the current benchmarks game website but the author is talking about a 2017 study. I wrote that wording myself, so I guess I got lucky if it's the same as what's on the benchmarks game website. But that was my observation some years ago. It seems pertinent for the state of CLBG in 2017 too: https://web.archive.org/web/20170526092655/http://benchmarksgame.alioth.debian.org/u64q/program.php?test=pidigits&lang=java&id=2 https://web.archive.org/web/20170526092655/http://benchmarks... just FFIs out to GNU MP. https://web.archive.org/web/20170619103241/http://benchmarksgame.alioth.debian.org/u64q/program.php?test=mandelbrot&lang=sbcl&id=1 https://web.archive.org/web/20170619103241/http://benchmarks... uses "inline assembly" of a sort, and disables safety checks entirely.
- igouy 4y ago
  > The implication, I believe, is that plain JavaScript is… No, the author actually tells us the reason — "And, we could well have chosen JavaScript for our Node.js code, though we're not likely to do this due to TypeScript being much more convenient to work with by comparison." Given the title is "We're choosing Rust, and not Go, C++, or Node.js" the plain reading was always that "TypeScript is apparently far more energy-hungry" than Rust, Go, C++. > … the state of CLBG in 2017… The author does not mention the benchmarks game. What you say has to be about what was used by that independent study 5 years ago, not about whatever the benchmarks game website showed 5 years ago.
  - hayley-patton 4y ago
    > What you say has to be about what was used by that independent study 5 years ago, not about whatever the benchmarks game website showed 5 years ago. The study tested the benchmarks game programs. Page 2 of the paper [0] explicitly states "our case study to analyze the energy efficiency of software languages is based on the CLBG" and proceeds to describe the programs tested. [0] https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sle...
    - igouy 4y ago
      That could be relevant if the study tested every one of the programs shown on the benchmarks game website on some particular day. In other words if the set of programs tested by the study was identical to the set of programs shown on the benchmarks game website. Does the paper claim that?
      - hayley-patton 4y ago
        There is a list of benchmarks used; including the Mandelbrot and pidigits benchmarks I cite. They also claim "they gathered the most efficient (i.e. fastest) version of the source code"; and I cited the fastest programs. This is legitimately painful to discuss, as this information is readily available in the paper, and seemingly we are getting nowhere by picking at how I made my observations; so I am going to do something more enjoyable, somewhere very far away from you.