tracygjg / enhanced-simd Goto Github PK

I think this project, as well as https://github.com/TracyGJG/sim-simd, and the two articles on dev.to, are based on some misunderstandings about what "concurrent" means.

Your article said: "JS is a single-threaded language but we can still run code, almost, concurrently using asynchronous techniques like promises and async/await, to leverage some performance gains."

The reason you can get performance gains from things like sending out multiple HTTP requests at once rather than sending out one, waiting for it to come back, then sending out the next, etc., is because the fetching of data across the internet is actually happening in parallel to the rest of your program. Ditto for things that are actually running on different hardware threads or on different machines.

JavaScript has a thread scheduler that picks which single-thread of execution to run at any given point. At start-up, it runs your main thread until your main thread yields back to the thread scheduler. At that point the thread scheduler may have had more tasks dropped on it by your code, or maybe your code told it to listen for certain events (e.g. key-presses or an HTTP response). If one of those events happened, it will call into the code that handles that event.

In this project, you are just adding a bunch of stuff to the thread scheduler, yielding the program, and then letting the thread scheduler pick up the next thing, then the next thing, and so on, until the allSettled event is satisfied, at which point it calls back into the code listening for that.

You are basically doing a heavily abstracted and computationally expensive version of adding functions to an array and calling them.

const arr = [];
arr.push(func);
arr.push(func);
arr.push(func);
arr.push(func);
arr.push(func);
arr.push(func);
arr.push(func);
arr.push(func);
arr.forEach(f => f());

There is no parallelism here. There are ways to actually get parallel threads of execution with JavaScript, like web-workers, for example. But a promise is not inherently introducing parallelism. It could, if it were actually calling into something that's actually going to run on a different hardware thread, but simply dumping a bunch of threads on the thread scheduler and telling it to do them all is not going to run them in parallel.

If you benchmarked this code, it would certainly be slower than the "naïve code" which just does all the work its supposed to without promises. Probably by an order of magnitude.

Also the "rest"/"spread" syntax in JavaScript has nothing to do with parallelism either. All it does is move the contents of an array or object into the place it is being spread. (For an iterator, it fully exhausts the iterator, putting the elements retrieved into the location in question)

[0, ...[1, 2, 3], 4] => [0, 1, 2, 3, 4]
{ a: 1, ...{ b: 2 }, c: 3} => { a: 1, b: 2, c: 3}

function foo(a, b, c) {
    // JavaScript parameters are implicitly stuffed into an array/tuple
    // so a is 1, b is 2, c is 3
}

foo(...[1, 2, 3])
// implicitly the same as:
foo.apply(globalThis, [...[1, 2, 3]])

// "rest" syntax goes the other way
function doo(...args) {
    // args is [1, 2, 3]
}

doo(1, 2, 3)
// implicitly the same as:
doo.apply(globalThis, [[1, 2, 3]])