3 ms·

> But some of those implementations might be unsuitable for the study, just as (at least) one was, in their case. Unsuitable because?

• pvg 8y ago
  Because it's a different implementation that happens to be 15 times slower than the implementation used in the straight JS version. That's fine for the benchmark game, it's a garbage input to a 'how energy efficient are these languages' study. Let's say I want to measure the 'energy efficiency' of x86 assembly and JS. I'll use sorting an array of 1000 integers. In my JS implementation, I call Array.sort. In my x86 implementation, I randomly shuffle the array and check if it's sorted, if not repeat until it is. Does measuring the execution times of these tell me anything about the 'energy efficiency' of Javascript vs x86 assembly?
  • igouy 8y ago
    > a different implementation that happens to be 15 times slower A few TypeScript versions later, that happens to be only 1.6 times slower. There are good questions to ask about how to handle possible outliers in a study that takes a snapshot of a changing situation and then seeks to make more general claims.
    • pvg 8y ago
      It doesn't matter what happened in the benchmark game later, it's not a study about the benchmark game. It's not 'good questions', it's a huge fuckup by the authors of the study. You're simply wrong to keep saying otherwise.
      • igouy 8y ago
        Supposedly you are right and others are wrong, which doesn't leave much to be discussed.