Hacker News Reader

Comment by cjreyes | Hacker News Reader

Would these changes eventually make their way into node.js (through V8)?

From the linked article (OK, press release):

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.

(edited to fix code, hopefully)

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.)

What's with the Node JS architecture that makes it not suitable for compute-heavy tasks?

I'm developing an MMO server in Node JS. So this is welcome in for example Vector calculations.

The reason I choose JS is that I can write "dumbed down" code, that just anyone with JS experience can manage.

Hopefully, JS will be just as fast as optimized C++ in the near future ... First you will ignore it, then laughs at it ...

It's single threaded. Any compute-heavy task will block that single thread until it's over.

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?

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.

Edit: grammar

Reply on news.ycombinator.com