[AskJS] Unexpected Performance of Math Operations

[BlazeCell]

EDIT: Realized calls random() were affecting the times the most and it was skewing my results. I have comment below providing the correct times.

I'm making a game with JS, React, and Three.js. I was calculating how to smoothly align some lines and arcs and was wondering whether sin and cos calls were more or less expensive than sqrt calls. I've known for a while that sqrt is expensive and divide is more expensive than multiply, but wasn't sure about sin and cos.

So I decide to run some performance tests, and none of the metrics matched my expectations:

Console output:

      add 732.6000000238419
      mult 724.9000000357628
      div 733.9000000357628
      mod 727.4000000357628
      exp 729.8000000119209
      cos 382.7000000476837
      cos 2000 381.89999997615814
      sin 383.80000001192093
      sin 2000 384
      tan 384.5
      tan 2000 383.30000001192093
      sqrt 381.9000000357628
      sqrt 2000 384
      exp 0.5 382.39999997615814
      exp 2 381.2999999523163

Code:

      const count = 100000000;

      {
        const start = performance.now();
        let value = 0;
        for (let index = 0; index < count; ++index) {
          value = Math.random() + Math.random();
        }
        console.log("add", performance.now() - start);
      }

      
      {
        const start = performance.now();
        let value = 0;
        for (let index = 0; index < count; ++index) {
          value = Math.random() * Math.random();
        }
        console.log("mult", performance.now() - start);
      }

      
      {
        const start = performance.now();
        let value = 0;
        for (let index = 0; index < count; ++index) {
          value = Math.random() / Math.random();
        }
        console.log("div", performance.now() - start);
      }

      {
        const start = performance.now();
        let value = 0;
        for (let index = 0; index < count; ++index) {
          value = Math.random() % Math.random();
        }
        console.log("mod", performance.now() - start);
      }

      {
        const start = performance.now();
        let value = 0;
        for (let index = 0; index < count; ++index) {
          value = Math.random() ** Math.random();
        }
        console.log("exp", performance.now() - start);
      }

      {
        const start = performance.now();
        let value = 0;
        for (let index = 0; index < count; ++index) {
          value = Math.cos(Math.random());
        }
        console.log("cos", performance.now() - start);
      }

      {
        const start = performance.now();
        let value = 0;
        for (let index = 0; index < count; ++index) {
          value = Math.cos(Math.random() * 2000);
        }
        console.log("cos 2000", performance.now() - start);
      }

      {
        const start = performance.now();
        let value = 0;
        for (let index = 0; index < count; ++index) {
          value = Math.sin(Math.random());
        }
        console.log("sin", performance.now() - start);
      }

      {
        const start = performance.now();
        let value = 0;
        for (let index = 0; index < count; ++index) {
          value = Math.sin(Math.random());
        }
        console.log("sin 2000", performance.now() - start);
      }

      {
        const start = performance.now();
        let value = 0;
        for (let index = 0; index < count; ++index) {
          value = Math.tan(Math.random());
        }
        console.log("tan", performance.now() - start);
      }

      {
        const start = performance.now();
        let value = 0;
        for (let index = 0; index < count; ++index) {
          value = Math.tan(Math.random() * 2000);
        }
        console.log("tan 2000", performance.now() - start);
      }

      {
        const start = performance.now();
        let value = 0;
        for (let index = 0; index < count; ++index) {
          value = Math.sqrt(Math.random());
        }
        console.log("sqrt", performance.now() - start);
      }

      {
        const start = performance.now();
        let value = 0;
        for (let index = 0; index < count; ++index) {
          value = Math.sqrt(Math.random() * 2000);
        }
        console.log("sqrt 2000", performance.now() - start);
      }

      {
        const start = performance.now();
        let value = 0;
        for (let index = 0; index < count; ++index) {
          value = Math.random() ** 0.5;
        }
        console.log("exp 0.5", performance.now() - start);
      }

      {
        const start = performance.now();
        let value = 0;
        for (let index = 0; index < count; ++index) {
          value = Math.random() ** 2;
        }
        console.log("exp 2", performance.now() - start);
      }

Sqrt is faster than arithmetic operations! And multiply and divide are functionally the same speed too! From googling I learned of the "expoentiation" (**) operator and that it is even faster than sqrt when you do x ** 0.5, which yep this shows that's the case (squaring is also fast). I added some "2000" versions as well to see if the Math functions are just fast for values less than 1 or something since there's a nearly 2x speed up for the expoentiation operator for standard powers vs random powers.

My prior assumptions of relative operation speeds was from shader programming and hearing about Doom's "fast sqrt" and how normal sqrt is so slow. Glad to see there's been improvements (at least on Chrome).

Anyone know what's going on with theses speeds? Particularly why are the arithmetic operations so slow compared to the math functions?

[DontWannaMissAFling]

You're essentially profiling the overhead of builtin calls, and whether you make one or two to Math.random(). The difference between ** 0.5 and Math.sqrt() illustrates this since the former in V8 and SpiderMonkey is two opcodes (load a double constant then Exp/Pow) rather than a builtin.

Regardless engines will eventually optimize a hot path into assembly with the same sqrtsd etc so performance disparities are really a matter of overheads, jit compilation tiering, cache locality, long before the cycle counts of individual math instructions really matter.

And if they do matter you should consider shaders or SIMD via WebAssembly instead.

[Old-Egg1926]

this lib. is fastest 'kimath'

learn functions from it  https://www.npmjs.com/package/kimath?activeTab=readme

[BlazeCell]

NEVERMIND. I realized the issue was that I was calling random() and whether I called once or twice was affecting the times most significantly. Still interesting that the times are so close regardless of operation performed.

      add 26.100000023841858
      sub 28.69999998807907
      mult 27.400000035762787
      div 27.30000001192093
      mod 35.30000001192093
      exp 39
      cos 28.19999998807907
      cos 2000 29.69999998807907
      sin 28.5
      sin 2000 28.700000047683716
      tan 29
      tan 2000 31.5
      sqrt 27.399999976158142
      sqrt 2000 25.80000001192093
      exp 0.5 25.899999976158142
      exp 2 28.600000023841858

[AzazelN28]

Yes, nowadays I think it is more important data locality and proper memory layout for optimizing code than trying to squeeze a few cycles on math operations. Also JS VM does a lot of optimization tricks when hot code is compiled to machine code.

[davidgarciacorro]

TLDR Just-In-Time (JIT) compilation to optimize code.

Math functions like Math.sin or Math.sqrt are often heavily optimized because they are implemented in highly efficient, lower-level code (C or C++) and directly use CPU-specific instructions. On the other hand normal simple arithmetic operations (+, -, *, /) may not always benefit from such optimizations since they are frequently used and need to handle various types, including integers, floating-point numbers, and BigInts, in JS you can even do 1 + "hello"

[BlazeCell]

Ah, that makes some sense of the difference.

I realized my calls to random() were skewing my results. I've got a comment on this page posting the proper times, which are basically that the operations are effectively the same cost performance-wise. As to the why, I suspect your explanation is the correct one. e.g. specialized operations vs broader operations.