6 ms·

Introducing SIMD.js

210 points by rnyman 12y ago

JetSpiegel 12y ago
It's official, Javascript is the new Assembly. I'll wait for the new Python, I never liked low level languages.
- quinnirill 12y ago
  I liked the "original" assembly more, at least it was designed for helping humans to write and read code. EDIT: That said, this is good news, in a sense.
  - espadrine 12y ago
    You make me wonder which assembly you're talking about. x86-64 feels heavy with legacy designs, many ways to get the same result, common pitfalls regarding memory management, and some surprising very specific gems to make some things fast… such as SIMD. (I know little about other instruction sets.)
    - marcosdumay 12y ago
      Before assembly, people wrote in binary machine code.
    - quinnirill 12y ago
      I'm just talking about design goals - the original assembly was introduced so that people wouldn't have to remember the numeric instructions of the processor. The instruction sets have been legacy even before that, with slight improvements occasionally, but at least the target audience was people in the beginning. With asm.js the target has been compilers to begin with. With most assembly dialects the instructions have a clear purpose, where as with asm.js you have arcane rules on what makes what stay as an integer, etc., enough so that I think most of the group of sane people would prefer writing against traditional assembly dialects than asm.js. Maybe that's a good thing, at least then the goal is that people who care about performance don't write JS. But I'd prefer to just have the compile target as numbers then since you can't read the result anyway.
- CmonDev 12y ago
  Python translated to Javascript. The fastest executing code ever.
  - corysama 12y ago
    https://rfk.id.au/blog/entry/pypy-js-faster-than-cpython/ https://rfk.id.au/blog/entry/pypy-js-faster-than-cpython/ "on a single carefully-tuned benchmark, after JIT warmup."
- gagege 12y ago
  ClojureScript already exists! So do Elm, Funscript, Purescript, Haxe, and a bunch of other things which transpile (might as well just start calling it "compile" now) to JS.
asb 12y ago
Now I'm just waiting for int64.js, which should appear when ES7 value objects come along http://www.slideshare.net/BrendanEich/value-objects2 http://www.slideshare.net/BrendanEich/value-objects2
- swartkrans 12y ago
  Not being able to have 64bit integers in node.js on a 64bit linux kernel can be a considerable issue. This fix can't come soon enough, having to wait for the version after the next is too long.
- bobajeff 12y ago
  Same here. I'm also looking forward to asm.js being a target for JVM, CLR and other garbage collected languages through Typed Objects. https://wiki.mozilla.org/Javascript:SpiderMonkey:OdinMonkey#Proposed_future_JS_features_that_would_be_useful_to_asm.js https://wiki.mozilla.org/Javascript:SpiderMonkey:OdinMonkey#... Also, am hoping 'JavaScript Shared Memory, Atomics, and Locks' gets accepted by TC-39. https://docs.google.com/document/d/1NDGA_gZJ7M7w1Bh8S0AoDyEqwDdRh4uSoTPSNn77PFk/edit?usp=sharing&pli=1 https://docs.google.com/document/d/1NDGA_gZJ7M7w1Bh8S0AoDyEq...
gopalv 12y ago
Neat, looks like JS is getting SIMD speedups because of fixed type objects. Would really love to see the speedup on fixed tuple transforms and convolution algorithms. When I saw JS speed wars originally, I started writing an adobe curve apply algorithm in JS, to apply .acv curves live using Canvas, but essentially hit CPU & shelved it. https://github.com/t3rmin4t0r/io.dine/blob/master/lib/iodine.js#L46 https://github.com/t3rmin4t0r/io.dine/blob/master/lib/iodine... http://notmysock.org/code/iodine/ http://notmysock.org/code/iodine/ I want to rewrite it using something like the newly introduced float32x4, assuming I can read out the images int o RGBA tuples. Something like a blur would actually be possible once this is fast.
- sunfish 12y ago
  That applycurve function has what appears to be a gather, which is unfortunately outside of where we expect to be with the initial iteration of SIMD.js, as there isn't widespread CPU SIMD hardware support for it yet. However, the brighten function immediately above it, for example, is supported by features in the SIMD.js spec today.
- IvanK_net 12y ago
  Hey, I have implemented Curves transform in JS too! :) You can find it at http://www.Photopea.com http://www.Photopea.com (Ctrl+M). It works pretty fast even on large images.
general_failure 12y ago
Contrary to popular opinion, I think this is actually a terrible idea. By doing this, we are basically adding SIMD to the JS 'virtual machine'. IMO, we shouldn't standardize on API for things which are so low level and this is really like an implementation detail in the virtual machine. I would suggest two alternate approaches: 1. First come with a standard SIMD specification across CPUs. In some ways like the GL specification (for GPU) or even the webrtc stuff (for p2p connections). Once you have done that, define a JS API. 2. Identify proper use cases. The example are quite bogus currently. They show a mandelbrot. Well, all this is done in the GPU. Image manipulation is done best with css level filters. Once we identify the use cases, we can them maybe add APIs to specifically address them if it's important for the web in general. In it's current form, this is really a 'because we can' API. Where does this end? What if we just expose raw socket and networking API instead of a webrtc style API? What about pixel manipulation of images? Also see: http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg25237.html http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg2.... The apple guys are saying they can do all this even without the API.
- simonster 12y ago
  I'm also not so sure about this. I admit to having limited compiler design experience, but the WebKit FTL guys do, and they seem to be saying that many things that can be done with SIMD primitives can be done better with automatic vectorization, since you can specialize code for the specific processor it's being executed on. On top of that, it's easier for the programmer if they can write ordinary code and get SIMD performance. Are there cases where algorithms simply cannot be expressed in a way that automatic vectorization could transform them into SIMD instructions? Or is this just a way to avoid implementing automatic vectorization in JavaScript engines?
  - pcwalton 12y ago
    Autovectorization has been an area of intense compiler effort for a decade or more and by and large the primary customers of it (games, video codecs, etc.) prefer the intrinsics. It's perceived as too unreliable and brittle to be relied upon, and it's easy to see why: given a choice between having to think about what the compiler's alias analysis, overflow analysis, loop trip count analysis, etc. will do and just writing an intrinsic and calling it a day, programmers will choose the latter. This applies regardless of how good the autovectorization really is: it's in a weird catch-22 kind of space where adding more and more features to your autovectorizer can actually reduce its perceived reliability, by making the answer to "will this vectorize?" harder and harder for a programmer to answer at a glance. <xmmintrin.h> has a lot of problems, but it's reliable, and at the end of the day that's what history has shown that game devs and video codec authors want.
ecesena 12y ago
Neat! Is anyone playing with js crypto and this new stuff?
jonstewart 12y ago
Oh. Dear. God. JavaScript is going to become the x86 of our time, i.e., the historically awful patchwork of kludges that gets passed onto each generation to kludge anew which also runs the entire world. JavaScript: we don't have integers, but, dammit, we have vector instructions. FML. Maybe it's not too late to take up painting.
- ndesaulniers 12y ago
  > JavaScript: we don't have integers More like "we don't have 64b ints, yet."
  - general_failure 12y ago
    Don't hold your breath. http://www.slideshare.net/BrendanEich/value-objects2 http://www.slideshare.net/BrendanEich/value-objects2
- eukaryotia 12y ago
  It's rapidly moving into hardware development as well, eg: https://tessel.io/ https://tessel.io/ https://www.kickstarter.com/projects/gfw/espruino-javascript-for-things https://www.kickstarter.com/projects/gfw/espruino-javascript... http://nodebots.io/ http://nodebots.io/ This is what programming is now.
  - msds 12y ago
    No, it's rapidly moving into toy hardware platforms targeted at web developers.
- ep103 12y ago
  >SIMD.js is originally derived from the Dart SIMD specification I am so ungodly sick of Google pushing DART technologies everywhere. I really am starting to think their strategy is embrace, enhance, exterminate.
  - pcwalton 12y ago
IvanK_net 12y ago
What we really need is to spread WebCL - https://www.khronos.org/registry/webcl/specs/1.0.0/ https://www.khronos.org/registry/webcl/specs/1.0.0/ 1. It is already standardized language and API. There exist a lot of code for WebCL. 2. WebCL engines can run on CPU, they can use all CPU cores, SIMD etc., while still being a part of web browser (no special drivers required). It will give us much better performance, than asm.js, SIMD.js, Google's Native Client or any other "unstandardizible" things.
- deleted 12y ago
  [deleted]
- ndesaulniers 12y ago
  WebCL is DOA: https://bugzilla.mozilla.org/show_bug.cgi?id=664147#c30 https://bugzilla.mozilla.org/show_bug.cgi?id=664147#c30
  - IvanK_net 12y ago
    Well that's what Microsoft said about Android in 2008. No wonder that Firefox is loosing popularity, when they refuse to innovate.
    - ndesaulniers 12y ago
      I'm taking my crayons and going home!
  - azakai 12y ago
    I wouldn't say DOA (which is final). As the comment there says, it doesn't make sense currently. But that could change.
  - anon1385 12y ago
    Non-Mozilla technologies are not welcome in Firefox and never have been. That is why we have been stuck for 15 years without a lossy image format that supports transparency (meanwhile they put lots of effort into supporting an animated png format that was invented by Mozilla that nobody else in the world cares about or uses). Mozilla's NIH syndrome holds back the web.
hajile 12y ago
And this is why we need to simply switch to LLVM. It gives us a sane bytecode, allows any language, allows real pre-browser optimization, etc. Mozilla's moving that direction with Rust and Servo. Google has already experimented with it via pnacl, and webkit/apple already actively compiles JS to llvm. For backward compatibility, just use and extend emscripten. As a bonus, this would allow the DOM interface to be reworked so we can get it right.
- legulere 12y ago
  Well LLVM heavily relies on not having forward compatibility (new versions spew out LLVM IR that can't be used by older versions) and backward compatibility is merely an afterthought.
  - hajile 12y ago
    That's a standards issue. If w3c froze a particular version as the "one true version", then whatever experimentation the llvm guys want to do with whatever other versions doesn't matter. Another solution is to version your code <script type="llvm" src="foo.ll" version="3.6.1" /> I'm already of the belief that w3c needs to require versioning of js code instead of stuff like 'use strict' (if it's bad, just remove it in new versions and move on). For backwards compatibility, if there's no version, assume ECMAScript3.
  - sanxiyn 12y ago
    Khronos Group standardized LLVM IR 3.2 as SPIR(Standard Portable Intermediate Representation). It is an existence proof that standardizing LLVM IR is possible. https://www.khronos.org/spir/ https://www.khronos.org/spir/
    - legulere 12y ago
      I actually work a bit with SPIR. They standardized a subset of LLVM IR 3.2 as SPIR 1.2 SPIR 2.0 on the other hand already is based off LLVM IR 3.4
- bobajeff 12y ago
J_Darnley 12y ago
Where are the Bytex16 types? Or the Wordx8 types? Who the hell is using floats for every data value?
- cliffbean 12y ago
  They're coming. The initial code for them is written; it's just waiting for a few other things to get checked in first. Also, quite a lot of people use floats for every data value.

Introducing SIMD.js

210 points by rnyman 12y ago

JetSpiegel 12y ago

It's official, Javascript is the new Assembly. I'll wait for the new Python, I never liked low level languages.

quinnirill 12y ago
I liked the "original" assembly more, at least it was designed for helping humans to write and read code. EDIT: That said, this is good news, in a sense.
- espadrine 12y ago
  You make me wonder which assembly you're talking about. x86-64 feels heavy with legacy designs, many ways to get the same result, common pitfalls regarding memory management, and some surprising very specific gems to make some things fast… such as SIMD. (I know little about other instruction sets.)
  - marcosdumay 12y ago
    Before assembly, people wrote in binary machine code.
  - quinnirill 12y ago
    I'm just talking about design goals - the original assembly was introduced so that people wouldn't have to remember the numeric instructions of the processor. The instruction sets have been legacy even before that, with slight improvements occasionally, but at least the target audience was people in the beginning. With asm.js the target has been compilers to begin with. With most assembly dialects the instructions have a clear purpose, where as with asm.js you have arcane rules on what makes what stay as an integer, etc., enough so that I think most of the group of sane people would prefer writing against traditional assembly dialects than asm.js. Maybe that's a good thing, at least then the goal is that people who care about performance don't write JS. But I'd prefer to just have the compile target as numbers then since you can't read the result anyway.
CmonDev 12y ago
Python translated to Javascript. The fastest executing code ever.
- corysama 12y ago
  https://rfk.id.au/blog/entry/pypy-js-faster-than-cpython/ https://rfk.id.au/blog/entry/pypy-js-faster-than-cpython/ "on a single carefully-tuned benchmark, after JIT warmup."
gagege 12y ago
ClojureScript already exists! So do Elm, Funscript, Purescript, Haxe, and a bunch of other things which transpile (might as well just start calling it "compile" now) to JS.

asb 12y ago

Now I'm just waiting for int64.js, which should appear when ES7 value objects come along http://www.slideshare.net/BrendanEich/value-objects2 http://www.slideshare.net/BrendanEich/value-objects2

swartkrans 12y ago
Not being able to have 64bit integers in node.js on a 64bit linux kernel can be a considerable issue. This fix can't come soon enough, having to wait for the version after the next is too long.
bobajeff 12y ago
Same here. I'm also looking forward to asm.js being a target for JVM, CLR and other garbage collected languages through Typed Objects. https://wiki.mozilla.org/Javascript:SpiderMonkey:OdinMonkey#Proposed_future_JS_features_that_would_be_useful_to_asm.js https://wiki.mozilla.org/Javascript:SpiderMonkey:OdinMonkey#... Also, am hoping 'JavaScript Shared Memory, Atomics, and Locks' gets accepted by TC-39. https://docs.google.com/document/d/1NDGA_gZJ7M7w1Bh8S0AoDyEqwDdRh4uSoTPSNn77PFk/edit?usp=sharing&pli=1 https://docs.google.com/document/d/1NDGA_gZJ7M7w1Bh8S0AoDyEq...

gopalv 12y ago

Neat, looks like JS is getting SIMD speedups because of fixed type objects. Would really love to see the speedup on fixed tuple transforms and convolution algorithms. When I saw JS speed wars originally, I started writing an adobe curve apply algorithm in JS, to apply .acv curves live using Canvas, but essentially hit CPU & shelved it. https://github.com/t3rmin4t0r/io.dine/blob/master/lib/iodine.js#L46 https://github.com/t3rmin4t0r/io.dine/blob/master/lib/iodine... http://notmysock.org/code/iodine/ http://notmysock.org/code/iodine/ I want to rewrite it using something like the newly introduced float32x4, assuming I can read out the images int o RGBA tuples. Something like a blur would actually be possible once this is fast.

sunfish 12y ago
That applycurve function has what appears to be a gather, which is unfortunately outside of where we expect to be with the initial iteration of SIMD.js, as there isn't widespread CPU SIMD hardware support for it yet. However, the brighten function immediately above it, for example, is supported by features in the SIMD.js spec today.
IvanK_net 12y ago
Hey, I have implemented Curves transform in JS too! :) You can find it at http://www.Photopea.com http://www.Photopea.com (Ctrl+M). It works pretty fast even on large images.

general_failure 12y ago

Contrary to popular opinion, I think this is actually a terrible idea. By doing this, we are basically adding SIMD to the JS 'virtual machine'. IMO, we shouldn't standardize on API for things which are so low level and this is really like an implementation detail in the virtual machine. I would suggest two alternate approaches: 1. First come with a standard SIMD specification across CPUs. In some ways like the GL specification (for GPU) or even the webrtc stuff (for p2p connections). Once you have done that, define a JS API. 2. Identify proper use cases. The example are quite bogus currently. They show a mandelbrot. Well, all this is done in the GPU. Image manipulation is done best with css level filters. Once we identify the use cases, we can them maybe add APIs to specifically address them if it's important for the web in general. In it's current form, this is really a 'because we can' API. Where does this end? What if we just expose raw socket and networking API instead of a webrtc style API? What about pixel manipulation of images? Also see: http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg25237.html http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg2.... The apple guys are saying they can do all this even without the API.

simonster 12y ago
I'm also not so sure about this. I admit to having limited compiler design experience, but the WebKit FTL guys do, and they seem to be saying that many things that can be done with SIMD primitives can be done better with automatic vectorization, since you can specialize code for the specific processor it's being executed on. On top of that, it's easier for the programmer if they can write ordinary code and get SIMD performance. Are there cases where algorithms simply cannot be expressed in a way that automatic vectorization could transform them into SIMD instructions? Or is this just a way to avoid implementing automatic vectorization in JavaScript engines?
- pcwalton 12y ago
  Autovectorization has been an area of intense compiler effort for a decade or more and by and large the primary customers of it (games, video codecs, etc.) prefer the intrinsics. It's perceived as too unreliable and brittle to be relied upon, and it's easy to see why: given a choice between having to think about what the compiler's alias analysis, overflow analysis, loop trip count analysis, etc. will do and just writing an intrinsic and calling it a day, programmers will choose the latter. This applies regardless of how good the autovectorization really is: it's in a weird catch-22 kind of space where adding more and more features to your autovectorizer can actually reduce its perceived reliability, by making the answer to "will this vectorize?" harder and harder for a programmer to answer at a glance. <xmmintrin.h> has a lot of problems, but it's reliable, and at the end of the day that's what history has shown that game devs and video codec authors want.

ecesena 12y ago

Neat! Is anyone playing with js crypto and this new stuff?

jonstewart 12y ago

Oh. Dear. God. JavaScript is going to become the x86 of our time, i.e., the historically awful patchwork of kludges that gets passed onto each generation to kludge anew which also runs the entire world. JavaScript: we don't have integers, but, dammit, we have vector instructions. FML. Maybe it's not too late to take up painting.

ndesaulniers 12y ago
> JavaScript: we don't have integers More like "we don't have 64b ints, yet."
- general_failure 12y ago
  Don't hold your breath. http://www.slideshare.net/BrendanEich/value-objects2 http://www.slideshare.net/BrendanEich/value-objects2
eukaryotia 12y ago
It's rapidly moving into hardware development as well, eg: https://tessel.io/ https://tessel.io/ https://www.kickstarter.com/projects/gfw/espruino-javascript-for-things https://www.kickstarter.com/projects/gfw/espruino-javascript... http://nodebots.io/ http://nodebots.io/ This is what programming is now.
- msds 12y ago
  No, it's rapidly moving into toy hardware platforms targeted at web developers.
ep103 12y ago
>SIMD.js is originally derived from the Dart SIMD specification I am so ungodly sick of Google pushing DART technologies everywhere. I really am starting to think their strategy is embrace, enhance, exterminate.
- pcwalton 12y ago

IvanK_net 12y ago

What we really need is to spread WebCL - https://www.khronos.org/registry/webcl/specs/1.0.0/ https://www.khronos.org/registry/webcl/specs/1.0.0/ 1. It is already standardized language and API. There exist a lot of code for WebCL. 2. WebCL engines can run on CPU, they can use all CPU cores, SIMD etc., while still being a part of web browser (no special drivers required). It will give us much better performance, than asm.js, SIMD.js, Google's Native Client or any other "unstandardizible" things.

deleted 12y ago
[deleted]
ndesaulniers 12y ago
WebCL is DOA: https://bugzilla.mozilla.org/show_bug.cgi?id=664147#c30 https://bugzilla.mozilla.org/show_bug.cgi?id=664147#c30
- IvanK_net 12y ago
  Well that's what Microsoft said about Android in 2008. No wonder that Firefox is loosing popularity, when they refuse to innovate.
  - ndesaulniers 12y ago
    I'm taking my crayons and going home!
- azakai 12y ago
  I wouldn't say DOA (which is final). As the comment there says, it doesn't make sense currently. But that could change.
- anon1385 12y ago
  Non-Mozilla technologies are not welcome in Firefox and never have been. That is why we have been stuck for 15 years without a lossy image format that supports transparency (meanwhile they put lots of effort into supporting an animated png format that was invented by Mozilla that nobody else in the world cares about or uses). Mozilla's NIH syndrome holds back the web.

hajile 12y ago

And this is why we need to simply switch to LLVM. It gives us a sane bytecode, allows any language, allows real pre-browser optimization, etc. Mozilla's moving that direction with Rust and Servo. Google has already experimented with it via pnacl, and webkit/apple already actively compiles JS to llvm. For backward compatibility, just use and extend emscripten. As a bonus, this would allow the DOM interface to be reworked so we can get it right.

legulere 12y ago
Well LLVM heavily relies on not having forward compatibility (new versions spew out LLVM IR that can't be used by older versions) and backward compatibility is merely an afterthought.
- hajile 12y ago
  That's a standards issue. If w3c froze a particular version as the "one true version", then whatever experimentation the llvm guys want to do with whatever other versions doesn't matter. Another solution is to version your code <script type="llvm" src="foo.ll" version="3.6.1" /> I'm already of the belief that w3c needs to require versioning of js code instead of stuff like 'use strict' (if it's bad, just remove it in new versions and move on). For backwards compatibility, if there's no version, assume ECMAScript3.
- sanxiyn 12y ago
  Khronos Group standardized LLVM IR 3.2 as SPIR(Standard Portable Intermediate Representation). It is an existence proof that standardizing LLVM IR is possible. https://www.khronos.org/spir/ https://www.khronos.org/spir/
  - legulere 12y ago
    I actually work a bit with SPIR. They standardized a subset of LLVM IR 3.2 as SPIR 1.2 SPIR 2.0 on the other hand already is based off LLVM IR 3.4
bobajeff 12y ago

J_Darnley 12y ago

Where are the Bytex16 types? Or the Wordx8 types? Who the hell is using floats for every data value?

cliffbean 12y ago
They're coming. The initial code for them is written; it's just waiting for a few other things to get checked in first. Also, quite a lot of people use floats for every data value.