JS-SIMD | Hacker News Reader

JS-SIMD

sunfishcode.github.io

69 pointsndesaulniers21 comments

JS SIMD will support the ARM Neon instructions. Here is the spec http://esdiscuss.org/notes/2014-07/simd-128-tc39.pdf

> Intel, Google, and Mozilla are working together to propose this SIMD API for standardization.

Here's hoping they wind up doing this for "JavaScript Shared Memory, Atomics, and Locks" (aka Pthreads)

People on HN complain about Emscripten being the devil's work, and now here is someone asking for pthread support? I need to go sit down...

All of those people work on Chrome.

With SIMD in JS, PNaCl and Dart VM become increasingly irrelevant. Now all that stands in the way is shared memory.

>> Now all that stands in the way is shared memory.

Also a legacy language people are forced to use.

For a legacy language people are forced to use, take a look at the implementation languages of these browser engines.

SIMD makes JS a better compile target. The Dart VM is still more "lightweight" (it has to generate a lot less native code) and it offers much faster startup (10x). There also aren't deoptimization traps scattered all over the place. The performance is very predictable.

As far as the VM itself is concerned, it doesn't really matter if other browser start to support Dart natively. The VM is extremely useful for development, you can embed it in native applications, and you can use it to write web servers and other command line tools.

Startup compared to v8. v8 compiles all JS to bytecode first, which is where it gets poorer startup time compared to SpiderMonkey's interpreter, or JavaScriptCore's handwritten assembly interpreter.

How many people are using the Dart VM outside of Dartium? Is it a meaningful amount that I should be worried?

Worried about what?

It's not like SpiderMonkey starts up instantaneously. Also, an interpreter is of course slower than the quick and dirty native code generated by V8.

JSC doesn't seem to have an advantage in the extremely short-running SunSpider benchmark suite.

Dart's snapshots are also something you just can't do with JavaScript, because the program structure is created imperatively with JS. You have to run quite a bit of code before you can actually run the program itself.

> Is it a meaningful amount that I should be worried?

Worried about what? Why would you care anyways? Do you also get worried if some game uses a Lua VM?

I use Dart for pretty much everything. Command line tools, web servers, and client-side scripting. It's an excellent choice for the things I do and the things I want to do.

It's a better fit than Java, C#, JavaScript, Python, or PHP. I still do use those languages occasionally, but Dart is my primary language now.

Mike Pall would disagree with you about interpreter vs compiler.

And here I was hoping it would be JS that would become irrelevant.

That's not going to happen any time soon. Would you break the web?

JS already broke the web....

Insert rant about how javascript is a terrible bytecode

Is it? It seems to be working quite well.

"Working" ≠ "working well"

Does ARM have any say in this standardization?

ARM's not working with them, but the JS-SIMD standards are being developed such that pretty much and SIMD unit will work with little to no work. Instead of making the commands 256 bits wide like current Intel SIMD ops, they're using 128 bits, which will work with ARM's neon as well with no problem.

The Dart SIMD API [1], which this work is based off of, is supported on ARM chips with NEON. I'm sure the JavaScript API will be too.

[1]: https://www.dartlang.org/articles/simd/#implementation-statu...

Reply on news.ycombinator.com