It will, however, run (...) on the platforms that support SIMD. This includes both the client platforms (...) as well as servers that run JavaScript, for example through the Node.js V8 engine.
...and:
A major part of the SIMD.JS API implementation has already landed in Firefox Nightly and our full implementation of the SIMD API for Intel Architecture has been submitted to Chromium for review.
...and:
Google, Intel, and Mozilla are working on a TC39 ECMAScript proposal to include this JavaScript SIMD API in the future ES7 version of the JavaScript standard.
So, yes, there's definitely an intention there to put it into V8/Node.js/ES7 (guess, it will be in this exact order).
Considering the architecture of Node.JS is not suited to compute-heavy tasks, I wonder what kind of code are you willing to optimize in Node.JS with SIMD?
Any improvements are still welcomed of course. There are a number of people/entities that are building desktop apps on Node and those tend to do 'compute-heavy tasks', a developer whose piece of code runs in a mean of 10 seconds would also welcome a possible optimisation to run it in less than that.
Not knowing much, I think it'll be interesting to see how general purpose applications would benefit from SIMD if it's accessed from a higher level. Does that mean that if I want to loop through 103 items and run arithmetic operations on them I'd have to do the following, (let's say I'm multiplying each item in items[] by 2, and items.length % 4 !== 0):
var batch = [],
results= [],
i = 0,
j = 0,
len = items.length,
a, b = SIMD.int32x4(2, 2, 2, 2),
c;
var mod = len % 4;
items.forEach(function (item) {
if (i < mod) {
results.push(item * 2);
i++;
} else if (j < 4) {
batch.push(item);
j++;
} else {
a = SIMD.float32x4(batch[0], batch[1], batch[2], batch[3]);
c = SIMD.float32x4.mul(a, b);
results.push(c.x);
results.push(c.y);
results.push(c.z);
results.push(c.w);
batch = [];
j = 0;
}
});
Of course this is the interpretation of a non-CS graduate who taught himself JS, some of the stuff mentioned at https://01.org/node/1495 seems a bit over my head. It'd be great if V8 would (unless it already does) transparently handle creating SIMD-optimised code where one is looping through an array or the like instead.
That kind of 'pack non-SIMD into SIMD, do SIMD op, unpack back into non-SIMD' thing tends to be slower than just doing non-SIMD ops in most cases.
You'd want to convert your non-SIMD data into a big stream of SIMD data up front, then do lots of operations on it, and then after that perhaps unpack it. Most SIMD scenarios just keep data in SIMD format indefinitely.
(Sometimes a compiler can use SIMD operations on arbitrary data by maintaining alignment requirements, etc. That sort of optimization might be possible for the JS runtime, but seems unlikely for anything other than typed arrays.)
The architecture is suited just fine, it all depends on how you decide to use Node.js. If you're using it for handling lots of asynchronous IO (eg. for a webserver) then it's probably unwise to mix in lots of blocking compute-heavy tasks on the main thread. But that's not the only way to use Node.js.
For example, we have a media library that implements HTML5 canvas2d, WebGL, WebAudio, video/image/sound encode and decode and a bunch of other media related compute-heavy tasks. We've done this as a native module because it lets us control all those APIs using the same code we would use in the browser, but we run that code in Node.js as a separate worker process where we don't care about things like IO latency. It works great.
In Node JS you can spawn child processes. It's also designed to be asynchronous. But what I like about JS is that it doesn't force me into paradigms.
And when you run something heavy in Node JS the VM can use many threads. So I think it's weird to say it's single threaded. Aren't all programming languages single threaded then?
