3 ms·
If we're not counting the time to zero out the array, it seems that typed arrays are slower than plain javascript because it's converting to & from floats/doubl
by Matheus28 5y ago
If we're not counting the time to zero out the array, it seems that typed arrays are slower than plain javascript because it's converting to & from floats/doubles back and forth. Try the same with Float64Array. My microbenchmark says f32 is 15% slower than f64 on chrome: https://jsbench.me/gnkxxkjag8/1 https://jsbench.me/gnkxxkjag8/1
- brrrrrm 5y agoGreat catch! I assumed the JIT would identify f32 arithmetic but I guess that isn't really valid numerically. I wonder if there's a way to use Math.fround[1] on your benchmark to get expected speedups? [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/fround https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- olliej 5y agoYup, the spec requires computation to be as doubles and so any computation must be done that way as the end result is observable. I didn’t know about fround but I suspect its primary use case is for trying to catch floating point overflow during double arithmetic, because again precision difference is observable.
- greggman3 5y agoAnd as usual for me, JavaScriptCore blows away V8 in most microbenchmarks I've run Same machine, JSC (Safari) is 3x faster than Chrome https://jsbenchit.org/?src=c792550e65de1d038b1f24b446c74592 https://jsbenchit.org/?src=c792550e65de1d038b1f24b446c74592