We Keep Coding

Why is atan2 and asin so much faster in JS than in JVM?

I have two almost identical pieces of code. One is running Scala on JVM, second is running Javascript. Both perform lots of atan and asin calls (this is extracted from the real application performing quaternion to Euler angles conversion). The Javascript implementations runs an order of magnitude faster.
The JS version takes about 1 000 ms on my machine. The Scala code takes about 10 000 ms when running on JVM, but when compiled using Scala.js it is again running for about 1000 ms (see ScalaFiddle).
What is the reason for such huge performance difference? What changes would I have to implement for the JVM code run this fast?
var size = 100000;
var input = new Array(size);
function fromQuaternion(a, b, c) {
return Math.asin(a) + Math.atan2(a, b) + Math.atan2(b, c);
}
function convert() {
var sum = 0;
for (var i = 0; i < size * 3; i += 3) {
sum += fromQuaternion(input[i], input[i+1], input[i+2]);
}
return sum;
}
for (var i = 0; i < size * 3; i += 3) {
input[i + 0] = Math.random();
input[i + 1] = Math.random();
input[i + 2] = Math.random();
}
var total = 0;
for (var i = 0; i < 10; i++) total += convert();
var start = Date.now();
for (var i = 0; i < 100; i++) total += convert();
var end = Date.now();
console.log("Duration " + (end - start));
console.log("Result " + total);
document.write("Duration " + (end - start));
val input = Array.fill(100000) {
val x = util.Random.nextDouble()
val y = util.Random.nextDouble()
val z = util.Random.nextDouble()
(x, y, z)
}
def fromQuaternion(a: Double, b: Double, c: Double): Double = {
Math.asin(a) + Math.atan2(a, b) + Math.atan2(b, c)
}
def convert = {
input.foldLeft(0.0) { (sum, q) =>
sum + fromQuaternion(q._1, q._2, q._3)
}
}
// warmup
var sum = 0.0
for (_ <- 0 until 10) sum += convert
val start = System.currentTimeMillis()
for (_ <- 0 until 100) sum += convert
val end = System.currentTimeMillis()
println(s"Duration ${end - start} ms")
println(f"Sum $sum%f")
When I measure asin and atan2 separately (with fromQuaternion containing only a single asin or a single atan2), I get following results:
JS atan2: 453 ms
JS asin 230 ms
Java Math atan2 1000 ms
Java Math asin 3800 ms
Apache FastMath atan2 1020 ms
Apache FastMath asin 1400 ms
I have tested Apache FastMath as well. While its asin is a bit faster, its performance is still way behind the one seen in the browser.
My measurements are done with Oracle Java 8 SDK 1.8.0.161 (JVM) and Chrome 78.0.3904.108 (Browser), both running on x64 Windows 10 running Intel Core i7 # 3.2 GHz with 12 GB RAM.

Javascript custom prng successive calls produces 0

I'm trying to port the old C standard rand() function over to JavaScript just for testing purposes. I don't plan to use this in a practical scenario so please don't freak out about it being insecure.
This is the C implementation of the function:
seed = seed * 1103515245 + 12345;
return (seed/65536) % 32768;
Where 32768 was RAND_MAX. So I tried porting that over to Javascript:
Random = function(p) {
this.s = p;
this.rand = function() {
this.s = this.s * 1103515245 + 12345;
return Math.floor((this.s / 65536) % 32768);
};
};
let r = new Random(Math.floor(new Date() / 1000));
console.log(r.rand()); // gives expected results
console.log(r.rand()); // second call produces 0
When I call r.rand() the first time, it produces the expected result. But then every successive call to r.rand()just gives me 0 and I'm curious as to why…

The issue was that this line this.s = this.s * 1103515245 + 12345; was dramatically increasing the value of this.s so by adding a modulus of 232 – 1 the number is restrained to produce the expected results as they would in C.
rand() {
this.seed = (this.seed*1103515245 + 12345) % 4294967295;
return (this.seed / 65536) % 32768;
}
It's probably not the best solution but it did seem to solve it.
A modulus Number.MAX_SAFE_INTEGER would work as well in this case, however since the goal was to keep it synced with C, 232 – 1 works okay.

Why isn't this code working to find the sum of multiples of 3 and 5 below the given number?

I've started with some problems on HackerRank, and am stuck with one of the Project Euler problems available there.
The problem statement says: Find the sum of all the multiples of 3 or 5 below N
I've calculated the sum by finding sum of multiple of 3 + sum of multiples of 5 - sum of multiples of 15 below the number n
function something(n) {
n = n-1;
let a = Math.trunc(n / 3);
let b = Math.trunc(n / 5);
let c = Math.trunc(n / 15);
return (3 * a * (a + 1) + 5 * b * (b + 1) - 15 * c * (c + 1)) / 2;
}
console.log(something(1000)); //change 1000 to any number
With the values of num I've tried, it seems to work perfectly, but with two out of five test cases there, it returns a wrong answer (I can't access the test cases).
My question is what is the problem with my code? as the logic seems to be correct to me at least.
Edit: Link to problem page

Some of the numbers in the input are probably larger than what javascript can handle by default. As stated in the discussion on the hackkerrank-site, you will need an extra library (like: bignumber.js) for that.
The following info and code was posted by a user named john_manuel_men1 on the discussion, where several other people had the same or similar problems like yours
This is how I figured it out in javascript. BigNumber.js seems to store the results as strings. Using the .toNumber() method shifted the result for some reason, so I used .toString() instead.
function main() {
var BigNumber = require('bignumber.js');
var t = new BigNumber(readLine()).toNumber();
var n;
for(var a0 = 0; a0 < t; a0++){
n = new BigNumber(readLine());
answer();
}
function answer() {
const a = n.minus(1).dividedBy(3).floor();
const b = n.minus(1).dividedBy(5).floor();
const c = n.minus(1).dividedBy(15).floor();
const sumThree = a.times(3).times(a.plus(1)).dividedBy(2);
const sumFive = b.times(5).times(b.plus(1)).dividedBy(2);
const sumFifteen = c.times(15).times(c.plus(1)).dividedBy(2);
const sumOfAll = sumThree.plus(sumFive).minus(sumFifteen);
console.log(sumOfAll.toString());
}
}

Javascript - Get minimum integer solution of computer equation

I am having a problem trying to solve an equation in programming.
Imagine I have this line of code:
Math.round(((x / 5) + Math.pow(x / 25, 1.3)) / 10) * 10;
Given x = 1000, the result is 320.
Now, how can I solve this equation given a result?
Imagine given the result 320 I want to get the minimum integer value of x that resolves that line of code.
/*320 =*/ Math.round(((x / 5) + Math.pow(x / 25, 1.3)) / 10) * 10;
I am having some hard time because of the Math.Round. Even thought that expression is a linear equation, the Math.Round makes way more solutions than one for x, so I want the minimum integer value for my solution.
Note that x is a integer and if I set x = 999 the result is still 320.
If I keep lowering x I can see that 984 (atleast in Chrome 64.0.3282.186) is the correct answer in this case, because is the lowest value of x equals to 320 in that expression/programming line.

Solving the equation with the Math.round just introduces boundary conditions.
If:
Math.round(((x / 5) + Math.pow(x / 25, 1.3)) / 10) * 10 = 320
Then:
Math.round(((x / 5) + Math.pow(x / 25, 1.3)) / 10) = 32
By dividing both sides by 10. Now you have:
Math.round(expression) = 32
Which can be expressed as an inequality statement:
31.5 < expression < 32.4999..
The expression being equal to 31.5 represents one boundary, and the expression being equal to 32.499.. represents the other boundary.So solving for the boundaries would require solving for:
expression = 31.5 and expression = 32.49999...
((x / 5) + Math.pow(x / 25, 1.3))/10 = 31.5 and
((x / 5) + Math.pow(x / 25, 1.3))/10 = 32.4999
Solving these two for x will give you the range of valid values for x. Now that's just algebra which I'm not going to do :)

I guess the most reliable way that works (albeit somewhat naive) is to loop through all valid numbers and check the predicate.
function getMinimumIntegerSolution(func, expectedResult){
for(let i = 0 /*Or Number.MIN_SAFE_INTEGER for -ves*/; i< Number.MAX_SAFE_INTEGER ; i++ ) {
if(func(i) === expectedResult)
return i;
}
}
Now
getMinimumIntegerSolution((x) => Math.round(((x / 5) + Math.pow(x / 25, 1.3)) / 10) * 10 , 320)
This returns what you expect, 984

Because the function defined by
f(n) = Math.round(((x / 5) + Math.pow(x / 25, 1.3)) / 10) * 10
is monotonous (in this case, increasing), you can do a binary search.
Note that I wrote the following code originally in Java, and it is syntactically incorrect in Javascript, but should hopefully be straightforward to translate into the latter.
var x0 = 0;
var x1 = 1e6;
var Y = 320d;
var epsilon = 10d;
var x = (x1 - x0) / 2d;
var y = 0;
while (Math.abs(Y - (y = f(x))) > epsilon) {
if (y > Y) {
x = (x - x0) / 2d;
} else {
x = (x1 - x) / 2d;
}
// System.out.println(y + " " + x);
}
while (f(x) < Y)
++x;
// System.out.println(Math.round(x) + " " + f(x));
Running it on my computer leaving the System.out.println uncommented:
490250.0 250000.0
208490.0 125000.0
89370.0 62500.0
38640.0 31250.0
16870.0 15625.0
7440.0 7812.5
3310.0 3906.25
1490.0 1953.125
680.0 976.5625
984 320.0
Note that the last loop incrementing x is guaranteed to complete in less than epsilon steps.
The values of x0, x1 and epsilon can be tweaked to provide better bounds for your problem.
This algorithm will fail if the value of epsilon is "too small", because of the rounding happening in f.
The complexity of this solution is O(log2(x1 - x0)).

In addition to #webnetweaver answer. If you rearrange the final equation you get a high-order polynomial (13th degree) which is difficult to solve algebraically. You can use numerical methods as Newton's method. For numerical methods in JavaScript you can use numeric.js. You also need to solve only for the lower bound (31.5) in order to find the lowest integer x because the function is monotonic increasing. See also this post on numerical equation solving in JavaScript.
Here is a solution using Newton's method. It uses 0 as initial guess. It only takes five iterations for getting the minimum integer solution.
var result = 320;
var d = result - 5;
function func(x) {
return x / 5 + 0.0152292 * Math.pow(x, 1.3) - d;
}
function deriv(x) {
return 0.2 + 0.019798 * Math.pow(x, 0.3);
}
var epsilon = 0.001; //termination condition
function newton(guess) {
var approx = guess - func(guess) / deriv(guess);
if (Math.abs(guess - approx) > epsilon) {
console.log("Guess: " + guess);
return newton(approx);
} else {
//round solution up for minimum integer
return Math.ceil(approx);
}
}
console.log("Minimum integer: " + newton(0));

Why is webAssembly function almost 300 time slower than same JS function

Find length of line 300* slower
First of I have read the answer to Why is my WebAssembly function slower than the JavaScript equivalent?
But it has shed little light on the problem, and I have invested a lot of time that may well be that yellow stuff against the wall.
I do not use globals, I do not use any memory. I have two simple functions that find the length of a line segment and compare them to the same thing in plain old Javascript. I have 4 params 3 more locals and returns a float or double.
On Chrome the Javascript is 40 times faster than the webAssembly and on firefox the wasm is almost 300 times slower than the Javascript.
jsPref test case.
I have added a test case to jsPref WebAssembly V Javascript math
What am I doing wrong?
Either
I have missed an obvious bug, bad practice, or I am suffering coder stupidity.
WebAssembly is not for 32bit OS (win 10 laptop i7CPU)
WebAssembly is far from a ready technology.
Please please be option 1.
I have read the webAssembly use case
Re-use existing code by targeting WebAssembly, embedded in a larger
JavaScript / HTML application. This could be anything from simple
helper libraries, to compute-oriented task offload.
I was hoping I could replace some geometry libs with webAssembly to get some extra performance. I was hoping that it would be awesome, like 10 or more times faster. BUT 300 times slower WTF.
UPDATE
This is not a JS optimisation issues.
To ensure that optimisation has as little as possible effect I have tested using the following methods to reduce or eliminate any optimisation bias..
counter c += length(... to ensure all code is executed.
bigCount += c to ensure whole function is executed. Not needed
4 lines for each function to reduce a inlining skew. Not Needed
all values are randomly generated doubles
each function call returns a different result.
add slower length calculation in JS using Math.hypot to prove code is being run.
added empty call that return first param JS to see overhead
// setup and associated functions
const setOf = (count, callback) => {var a = [],i = 0; while (i < count) { a.push(callback(i ++)) } return a };
const rand = (min = 1, max = min + (min = 0)) => Math.random() * (max - min) + min;
const a = setOf(100009,i=>rand(-100000,100000));
var bigCount = 0;
function len(x,y,x1,y1){
var nx = x1 - x;
var ny = y1 - y;
return Math.sqrt(nx * nx + ny * ny);
}
function lenSlow(x,y,x1,y1){
var nx = x1 - x;
var ny = y1 - y;
return Math.hypot(nx,ny);
}
function lenEmpty(x,y,x1,y1){
return x;
}
// Test functions in same scope as above. None is in global scope
// Each function is copied 4 time and tests are performed randomly.
// c += length(... to ensure all code is executed.
// bigCount += c to ensure whole function is executed.
// 4 lines for each function to reduce a inlining skew
// all values are randomly generated doubles
// each function call returns a different result.
tests : [{
func : function (){
var i,c=0,a1,a2,a3,a4;
for (i = 0; i < 10000; i += 1) {
a1 = a[i];
a2 = a[i+1];
a3 = a[i+2];
a4 = a[i+3];
c += length(a1,a2,a3,a4);
c += length(a2,a3,a4,a1);
c += length(a3,a4,a1,a2);
c += length(a4,a1,a2,a3);
}
bigCount = (bigCount + c) % 1000;
},
name : "length64",
},{
func : function (){
var i,c=0,a1,a2,a3,a4;
for (i = 0; i < 10000; i += 1) {
a1 = a[i];
a2 = a[i+1];
a3 = a[i+2];
a4 = a[i+3];
c += lengthF(a1,a2,a3,a4);
c += lengthF(a2,a3,a4,a1);
c += lengthF(a3,a4,a1,a2);
c += lengthF(a4,a1,a2,a3);
}
bigCount = (bigCount + c) % 1000;
},
name : "length32",
},{
func : function (){
var i,c=0,a1,a2,a3,a4;
for (i = 0; i < 10000; i += 1) {
a1 = a[i];
a2 = a[i+1];
a3 = a[i+2];
a4 = a[i+3];
c += len(a1,a2,a3,a4);
c += len(a2,a3,a4,a1);
c += len(a3,a4,a1,a2);
c += len(a4,a1,a2,a3);
}
bigCount = (bigCount + c) % 1000;
},
name : "length JS",
},{
func : function (){
var i,c=0,a1,a2,a3,a4;
for (i = 0; i < 10000; i += 1) {
a1 = a[i];
a2 = a[i+1];
a3 = a[i+2];
a4 = a[i+3];
c += lenSlow(a1,a2,a3,a4);
c += lenSlow(a2,a3,a4,a1);
c += lenSlow(a3,a4,a1,a2);
c += lenSlow(a4,a1,a2,a3);
}
bigCount = (bigCount + c) % 1000;
},
name : "Length JS Slow",
},{
func : function (){
var i,c=0,a1,a2,a3,a4;
for (i = 0; i < 10000; i += 1) {
a1 = a[i];
a2 = a[i+1];
a3 = a[i+2];
a4 = a[i+3];
c += lenEmpty(a1,a2,a3,a4);
c += lenEmpty(a2,a3,a4,a1);
c += lenEmpty(a3,a4,a1,a2);
c += lenEmpty(a4,a1,a2,a3);
}
bigCount = (bigCount + c) % 1000;
},
name : "Empty",
}
],
Results from update.
Because there is a lot more overhead in the test the results are closer but the JS code is still two orders of magnitude faster.
Note how slow the function Math.hypot is. If optimisation was in effect that function would be near the faster len function.
WebAssembly 13389µs
Javascript 728µs
/*
=======================================
Performance test. : WebAssm V Javascript
Use strict....... : true
Data view........ : false
Duplicates....... : 4
Cycles........... : 147
Samples per cycle : 100
Tests per Sample. : undefined
---------------------------------------------
Test : 'length64'
Mean : 12736µs ±69µs (*) 3013 samples
---------------------------------------------
Test : 'length32'
Mean : 13389µs ±94µs (*) 2914 samples
---------------------------------------------
Test : 'length JS'
Mean : 728µs ±6µs (*) 2906 samples
---------------------------------------------
Test : 'Length JS Slow'
Mean : 23374µs ±191µs (*) 2939 samples << This function use Math.hypot
rather than Math.sqrt
---------------------------------------------
Test : 'Empty'
Mean : 79µs ±2µs (*) 2928 samples
-All ----------------------------------------
Mean : 10.097ms Totals time : 148431.200ms 14700 samples
(*) Error rate approximation does not represent the variance.
*/
Whats the point of WebAssambly if it does not optimise
End of update
All the stuff related to the problem.
Find length of a line.
Original source in custom language
// declare func the < indicates export name, the param with types and return type
func <lengthF(float x, float y, float x1, float y1) float {
float nx, ny, dist; // declare locals float is f32
nx = x1 - x;
ny = y1 - y;
dist = sqrt(ny * ny + nx * nx);
return dist;
}
// and as double
func <length(double x, double y, double x1, double y1) double {
double nx, ny, dist;
nx = x1 - x;
ny = y1 - y;
dist = sqrt(ny * ny + nx * nx);
return dist;
}
Code compiles to Wat for proof read
(module
(func
(export "lengthF")
(param f32 f32 f32 f32)
(result f32)
(local f32 f32 f32)
get_local 2
get_local 0
f32.sub
set_local 4
get_local 3
get_local 1
f32.sub
tee_local 5
get_local 5
f32.mul
get_local 4
get_local 4
f32.mul
f32.add
f32.sqrt
)
(func
(export "length")
(param f64 f64 f64 f64)
(result f64)
(local f64 f64 f64)
get_local 2
get_local 0
f64.sub
set_local 4
get_local 3
get_local 1
f64.sub
tee_local 5
get_local 5
f64.mul
get_local 4
get_local 4
f64.mul
f64.add
f64.sqrt
)
)
As compiled wasm in hex string (Note does not include name section) and loaded using WebAssembly.compile. Exported functions then run against Javascript function len (in below snippet)
// hex of above without the name section
const asm = `0061736d0100000001110260047d7d7d7d017d60047c7c7c7c017c0303020001071402076c656e677468460000066c656e67746800010a3b021c01037d2002200093210420032001932205200594200420049492910b1c01037c20022000a1210420032001a122052005a220042004a2a09f0b`
const bin = new Uint8Array(asm.length >> 1);
for(var i = 0; i < asm.length; i+= 2){ bin[i>>1] = parseInt(asm.substr(i,2),16) }
var length,lengthF;
WebAssembly.compile(bin).then(module => {
const wasmInstance = new WebAssembly.Instance(module, {});
lengthF = wasmInstance.exports.lengthF;
length = wasmInstance.exports.length;
});
// test values are const (same result if from array or literals)
const a1 = rand(-100000,100000);
const a2 = rand(-100000,100000);
const a3 = rand(-100000,100000);
const a4 = rand(-100000,100000);
// javascript version of function
function len(x,y,x1,y1){
var nx = x1 - x;
var ny = y1 - y;
return Math.sqrt(nx * nx + ny * ny);
}
And the test code is the same for all 3 functions and run in strict mode.
tests : [{
func : function (){
var i;
for (i = 0; i < 100000; i += 1) {
length(a1,a2,a3,a4);
}
},
name : "length64",
},{
func : function (){
var i;
for (i = 0; i < 100000; i += 1) {
lengthF(a1,a2,a3,a4);
}
},
name : "length32",
},{
func : function (){
var i;
for (i = 0; i < 100000; i += 1) {
len(a1,a2,a3,a4);
}
},
name : "lengthNative",
}
]
The test results on FireFox are
/*
=======================================
Performance test. : WebAssm V Javascript
Use strict....... : true
Data view........ : false
Duplicates....... : 4
Cycles........... : 34
Samples per cycle : 100
Tests per Sample. : undefined
---------------------------------------------
Test : 'length64'
Mean : 26359µs ±128µs (*) 1128 samples
---------------------------------------------
Test : 'length32'
Mean : 27456µs ±109µs (*) 1144 samples
---------------------------------------------
Test : 'lengthNative'
Mean : 106µs ±2µs (*) 1128 samples
-All ----------------------------------------
Mean : 18.018ms Totals time : 61262.240ms 3400 samples
(*) Error rate approximation does not represent the variance.
*/

Andreas describes a number of good reasons why the JavaScript implementation was initially observed to be x300 faster. However, there are a number of other issues with your code.
This is a classic 'micro benchmark', i.e. the code that you are testing is so small, that the other overheads within your test loop are a significant factor. For example, there is an overhead in calling WebAssembly from JavaScript, which will factor in your results. What are you trying to measure? raw processing speed? or the overhead of the language boundary?
Your results vary wildly, from x300 to x2, due to small changes in your test code. Again, this is a micro benchmark issue. Others have seen the same when using this approach to measure performance, for example this post claims wasm is x84 faster, which is clearly wrong!
The current WebAssembly VM is very new, and an MVP. It will get faster. Your JavaScript VM has had 20 years to reach its current speed. The performance of the JS <=> wasm boundary is being worked on and optimised right now.
For a more definitive answer, see the joint paper from the WebAssembly team, which outlines an expected runtime performance gain of around 30%
Finally, to answer your point:
Whats the point of WebAssembly if it does not optimise
I think you have misconceptions around what WebAssembly will do for you. Based on the paper above, the runtime performance optimisations are quite modest. However, there are still a number of performance advantages:
Its compact binary format mean and low level nature means the browser can load, parse and compile the code much faster than JavaScript. It is anticipated that WebAssembly can be compiled faster than your browser can download it.
WebAssembly has a predictable runtime performance. With JavaScript the performance generally increases with each iteration as it is further optimised. It can also decrease due to se-optimisation.
There are also a number of non-performance related advantages too.
For a more realistic performance measurement, take a look at:
Its use within Figma
Results from using it with PDFKit
Both are practical, production codebases.

The JS engine can apply a lot of dynamic optimisations to this example:
Perform all calculations with integers and only convert to double for the final call to Math.sqrt.
Inline the call to the len function.
Hoist the computation out of the loop, since it always computes the same thing.
Recognise that the loop is left empty and eliminate it entirely.
Recognise that the result is never returned from the testing function, and hence remove the entire body of the test function.
All but (4) apply even if you add the result of every call. With (5) the end result is an empty function either way.
With Wasm an engine cannot do most of these steps, because it cannot inline across language boundaries (at least no engine does that today, AFAICT). Also, for Wasm it is assumed that the producing (offline) compiler has already performed relevant optimisations, so a Wasm JIT tends to be less aggressive than one for JavaScript, where static optimisation is impossible.

Serious answer
It seemed like
WebAssembly is far from a ready technology.
actually did play a role in this, and performance of calling WASM from JS in Firefox was improved in late 2018.
Running your benchmarks in a current FF/Chromium yields results like "Calling the WASM implementation from JS is 4-10 times slower than calling the JS implementation from JS". Still, it seems like engines don't inline across WASM/JS borders, and the overhead of having to call vs. not having to call is significant (as the other answers already pointed out).
Mocking answer
Your benchmarks are all wrong. It turns out that JS is actually 8-40 times (FF, Chrome) slower than WASM. WTF, JS is soo slooow.
Do I intend to prove that? Of course (not).
First, I re-implement your benchmarking code in C:
#include <math.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
static double lengthC(double x, double y, double x1, double y1) {
double nx = x1 - x;
double ny = y1 - y;
return sqrt(nx * nx + ny * ny);
}
double lengthArrayC(double* a, size_t length) {
double c = 0;
for (size_t i = 0; i < length; i++) {
double a1 = a[i + 0];
double a2 = a[i + 1];
double a3 = a[i + 2];
double a4 = a[i + 3];
c += lengthC(a1,a2,a3,a4);
c += lengthC(a2,a3,a4,a1);
c += lengthC(a3,a4,a1,a2);
c += lengthC(a4,a1,a2,a3);
}
return c;
}
#ifdef __wasm__
__attribute__((import_module("js"), import_name("len")))
double lengthJS(double x, double y, double x1, double y1);
double lengthArrayJS(double* a, size_t length) {
double c = 0;
for (size_t i = 0; i < length; i++) {
double a1 = a[i + 0];
double a2 = a[i + 1];
double a3 = a[i + 2];
double a4 = a[i + 3];
c += lengthJS(a1,a2,a3,a4);
c += lengthJS(a2,a3,a4,a1);
c += lengthJS(a3,a4,a1,a2);
c += lengthJS(a4,a1,a2,a3);
}
return c;
}
__attribute__((import_module("bench"), import_name("now")))
double now();
__attribute__((import_module("bench"), import_name("result")))
void printtime(int benchidx, double ns);
#else
void printtime(int benchidx, double ns) {
if (benchidx == 1) {
printf("C: %f ns\n", ns);
} else if (benchidx == 0) {
printf("avoid the optimizer: %f\n", ns);
} else {
fprintf(stderr, "Unknown benchmark: %d", benchidx);
exit(-1);
}
}
double now() {
struct timespec ts;
if (clock_gettime(CLOCK_MONOTONIC, &ts) == 0) {
return (double)ts.tv_sec + (double)ts.tv_nsec / 1e9;
} else {
return sqrt(-1);
}
}
#endif
#define iters 1000000
double a[iters+3];
int main() {
int bigCount = 0;
srand(now());
for (size_t i = 0; i < iters + 3; i++)
a[i] = (double)rand()/RAND_MAX*2e5-1e5;
for (int i = 0; i < 10; i++) {
double startTime, endTime;
double c;
startTime = now();
c = lengthArrayC(a, iters);
endTime = now();
bigCount = (bigCount + (int64_t)c) % 1000;
printtime(1, (endTime - startTime) * 1e9 / iters / 4);
#ifdef __wasm__
startTime = now();
c = lengthArrayJS(a, iters);
endTime = now();
bigCount = (bigCount + (int64_t)c) % 1000;
printtime(2, (endTime - startTime) * 1e9 / iters / 4);
#endif
}
printtime(0, bigCount);
return 0;
}
Compile it with clang 12.0.1:
clang -O3 -target wasm32-wasi --sysroot /opt/wasi-sdk/wasi-sysroot/ foo2.c -o foo2.wasm
And provide it with a length function from JS via imports:
"use strict";
(async (wasm) => {
const wasmbytes = new Uint8Array(wasm.length);
for (var i in wasm)
wasmbytes[i] = wasm.charCodeAt(i);
(await WebAssembly.instantiate(wasmbytes, {
js: {
len: function (x,y,x1,y1) {
var nx = x1 - x;
var ny = y1 - y;
return Math.sqrt(nx * nx + ny * ny);
}
},
bench: {
now: () => window.performance.now() / 1e3,
result: (bench, ns) => {
let name;
if (bench == 1) { name = "C" }
else if (bench == 2) { name = "JS" }
else if (bench == 0) { console.log("Optimizer confuser: " + ns); /*not really necessary*/; return; }
else { throw "unknown bench"; }
console.log(name + ": " + ns + " ns");
},
},
})).instance.exports._start();
})(atob('AGFzbQEAAAABFQRgBHx8fHwBfGAAAXxgAn98AGAAAAIlAwJqcwNsZW4AAAViZW5jaANub3cAAQViZW5jaAZyZXN1bHQAAgMCAQMFAwEAfAcTAgZtZW1vcnkCAAZfc3RhcnQAAwr2BAHzBAMIfAJ/An5BmKzoAwJ/EAEiA0QAAAAAAADwQWMgA0QAAAAAAAAAAGZxBEAgA6sMAQtBAAtBAWutNwMAQejbl3whCANAQZis6ANBmKzoAykDAEKt/tXk1IX9qNgAfkIBfCIKNwMAIAhBmKzoA2ogCkIhiKe3RAAAwP///99Bo0QAAAAAAGoIQaJEAAAAAABq+MCgOQMAIAhBCGoiCA0ACwNAEAEhBkGQCCsDACEBQYgIKwMAIQRBgAgrAwAhAEQAAAAAAAAAACECQRghCANAIAQhAyABIgQgAKEiASABoiIHIAMgCEGACGorAwAiAaEiBSAFoiIFoJ8gACAEoSIAIACiIgAgBaCfIAAgASADoSIAIACiIgCgnyACIAcgAKCfoKCgoCECIAMhACAIQQhqIghBmKToA0cNAAtBARABIAahRAAAAABlzc1BokQAAAAAgIQuQaNEAAAAAAAA0D+iEAICfiACmUQAAAAAAADgQ2MEQCACsAwBC0KAgICAgICAgIB/CyALfEQAAAAAAAAAACECQYDcl3whCBABIQMDQCACIAhBgKzoA2orAwAiBSAIQYis6ANqKwMAIgEgCEGQrOgDaisDACIAIAhBmKzoA2orAwAiBBAAoCABIAAgBCAFEACgIAAgBCAFIAEQAKAgBCAFIAEgABAAoCECIAhBCGoiCA0AC0ECEAEgA6FEAAAAAGXNzUGiRAAAAACAhC5Bo0QAAAAAAADQP6IQAkLoB4EhCgJ+IAKZRAAAAAAAAOBDYwRAIAKwDAELQoCAgICAgICAgH8LIAp8QugHgSELIAlBAWoiCUEKRw0AC0EAIAuntxACCwB2CXByb2R1Y2VycwEMcHJvY2Vzc2VkLWJ5AQVjbGFuZ1YxMS4wLjAgKGh0dHBzOi8vZ2l0aHViLmNvbS9sbHZtL2xsdm0tcHJvamVjdCAxNzYyNDliZDY3MzJhODA0NGQ0NTcwOTJlZDkzMjc2ODcyNGE2ZjA2KQ=='))
Now, calling the JS function from WASM is unsurprisingly a lot slower than calling the WASM function from WASM. (In fact, WASM→WASM it isn't calling. You can see the f64.sqrt being inlined into _start.)
(One last interesting datapoint is that WASM→WASM and JS→JS seem to have about the same cost (about 1.5 ns per inlined length(…) on my E3-1280). Disclaimer: It's entirely possible that my benchmark is even more broken than the original question.)
Conclusion
WASM isn't slow, crossing the border is. For now and the foreseeable future, don't put things into WASM unless they're a significant computational task. (And even then, it depends. Sometimes, JS engines are really smart. Sometimes.)