perf: avoid slow exponentiation and repeated element reads

[lpatiny]

Speeds up the hot loops of the distance and similarity functions.

Algorithmic changes

• kumarJohnson: prod ** 1.5 → prod * Math.sqrt(prod). No engine specializes a 1.5 exponent, so this is the biggest win, on V8 and JavaScriptCore alike.
• minkowski: special-case p = 1 and p = 2. V8 sends x ** 1 through generic pow at ~9x the cost of a plain read; p = 2 is worth ~1.5x when called monomorphically.
• similarity.pearson: drop the two arrays it allocated only to mean-centre before calling cosine, folding the work into two passes.

Measured with beforeAfter.js, before → after, per element (n = 10000, Float64Array, node 24):

function	before	after
kumarJohnson	15.50 ns	2.41 ns	6.4x
similarity.pearson	19.06 ns	3.23 ns	5.9x
minkowski(p=1)	11.51 ns	2.02 ns	5.7x

For the other functions defining const like for example from:

  for (let i = 0; i < a.length; i++) {
    ans +=
      a[i] * Math.log((2 * a[i]) / (a[i] + b[i])) +
      b[i] * Math.log((2 * b[i]) / (a[i] + b[i]));
  }

to

 for (let i = 0; i < a.length; i++) {
    const ai = a[i];
    const bi = b[i];
    const sum = ai + bi;
    ans += ai * Math.log((2 * ai) / sum) + bi * Math.log((2 * bi) / sum);
  }

has no impact, neither with bun or with nodeJS except in the case of polymorphism (once a typed array, once a number array for example) and in this case we win a factor 1.5

But as a side observation changing the type of an array is really a bad idea and we are loosing a factor 2 in speed. I wonder if we can reach this kind of issue in some of our projects.

So practically I would still make this 'const' definition even if we win speed only in case of polymorphism. @targos WDYT ?

[targos]

The specialized changes LGTM but I would avoid to change all methods. I've run the benchmarks myself and I am not convinced that anything is meaningfully improved.

➤ node elementReads.js
Float64Array only  before      5.47 ns/element  ±5.1%
Float64Array only  after       5.54 ns/element  ±4.3%
Array only         before      5.28 ns/element  ±5.8%
Array only         after       5.45 ns/element  ±4.9%
both kinds         before      5.65 ns/element  ±3.5%
both kinds         after       5.41 ns/element  ±5.7%

gain from caching the element reads:
  Float64Array only  0.99x
  Array only         0.97x
  both kinds         1.04x

[lpatiny]

Here is another benchmark that shows this 1.5 factor on the polymorphism (and does not rely on another library). But for sure the real issue is polymorphism and we need to think about it because even if we define const we still loose a factor 2 if we change of type.

A single switch of the type at the end of the warm-up has a full impact on the number of operation per seconds.

measured warm-up cached direct
array array 1506 M/s 1533 M/s
array typed 704 M/s 464 M/s <- 2.1x / 3.3x slower
typed array 694 M/s 458 M/s <- 2.1x / 3.6x slower
typed typed 1437 M/s 1645 M/s
mixed mixed 711 M/s 493 M/s

8401b5f

distance [faster-distances●] % bash benchmark/arrayKinds.sh

  (ai * bi) / (ai + bi) on 10000 elements, arguments swapped at each call

  kind             cached         direct      ratio
  -------- -------------- -------------- ----------
  array           1558 M/s        1571 M/s      0.99x
  typed           1488 M/s        1679 M/s      0.89x
  mixed            740 M/s         506 M/s      1.46x

[targos]

It seems to show that the code is faster when there is no polymorphism, so do we really want to lose this?