TypeScript fannkuch-redux implementation skews results in paper

[akx]

This is tangentially related to #3.

The 2017 paper (linked today in an article in Finland's largest newspaper about the energy efficiency of IT) implies that TypeScript is about 16 times less energy-efficient with the fannkuch-redux benchmark.
It seems that this is down to the fact that the TypeScript implementation of the program itself is inefficient.

Running hyperfine against the transpiled JavaScript for the TypeScript program (which, naturally, is just JavaScript, so should exactly match the performance of JavaScript), shows this:

$ hyperfine "node TypeScript/fannkuch-redux/fannkuchredux.js 11" "node JavaScript/fannkuch-redux/fannkuchredux.node-4.js 11"
Benchmark 1: node TypeScript/fannkuch-redux/fannkuchredux.js 11
  Time (mean ± σ):      4.518 s ±  0.079 s    [User: 4.490 s, System: 0.016 s]
  Range (min … max):    4.409 s …  4.630 s    10 runs

Benchmark 2: node JavaScript/fannkuch-redux/fannkuchredux.node-4.js 11
  Time (mean ± σ):      2.516 s ±  0.031 s    [User: 2.497 s, System: 0.012 s]
  Range (min … max):    2.454 s …  2.559 s    10 runs

Summary
  'node JavaScript/fannkuch-redux/fannkuchredux.node-4.js 11' ran
    1.80 ± 0.04 times faster than 'node TypeScript/fannkuch-redux/fannkuchredux.js 11'

(I ran these with parameter 11 because I didn't have the patience to wait for Hyperfine to finish all trials at parameter 12 as used in the scripts in the repository, but it seems the performance gap between the programs grows more and more.)

[igouy]

If you look at the fannkuch-redux, it seems to be a console.log within the loop in the typescript version, which isn't in the JS version.

        while (go) {
            if (r == n) {
                console.log(checksum);
                return flips;
            }

Here's what that console.log outputs:

3968050

Once.

Now look at all the other program differences.

[RobinBlomberg]

There shouldn't be a separate TypeScript implementation at all. The TypeScript directory is completely unnecessary.

If you rename the JS implementation to .ts and compile it back to JS, the performance difference is exactly zero.

Benchmark 1: node js.js 11
  Time (mean ± σ):      1.502 s ±  0.012 s    [User: 1.492 s, System: 0.005 s]
  Range (min … max):    1.494 s …  1.532 s    10 runs

Benchmark 2: node js-ts.js 11
  Time (mean ± σ):      1.506 s ±  0.013 s    [User: 1.496 s, System: 0.005 s]
  Range (min … max):    1.489 s …  1.533 s    10 runs

Summary
  node js.js 11 ran
    1.00 ± 0.01 times faster than node js-ts.js 11

This is completely unsurprising, by the way, as it compiles to the exact same JavaScript.

[igouy]

--strict --noEmitOnError

[igouy]

Seems like there was a problem with the particular version of TypeScript back in 2017.

Here are measurements from web.archive.org:

1,234.81 secs
Version 2.4.1
node.js v8.1.3
Wed, 05 Jul 2017 23:02:15 GMT
fannkuch-redux TypeScript

1,204.93 secs
Version 2.4.1
node.js v8.1.3
Wed, 05 Jul 2017 23:24:25 GMT
fannkuch-redux TypeScript # 2

147.23 secs
Version 2.6.2
node.js v9.4.0
Wed, 10 Jan 2018 20:22:43 GMT
fannkuch-redux TypeScript

139.53 secs
Version 2.6.2
node.js v9.4.0
Wed, 10 Jan 2018 20:25:24 GMT
fannkuch-redux TypeScript # 2