6 ms·

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'

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.
  - ndesaulniers 12y ago
    > "will this vectorize?" Yes, but _will it blend?_
  - jallmann 12y ago
    > (games, video codecs, etc.) prefer the intrinsics Nit: Most of the projects I'm familiar with (libav/ffmpeg, x264, etc) prefer to break out the SIMD into hand-written functions, instead of relying on intrinsics or even inline asm. This avoids problems with register allocation and code gen, consistency/portability between compilers, etc. Otherwise, yes, autovectorization is hard, both for application developers and compiler writers. Application code needs to be structured in a very precise way, and the correctness of C -> SIMD transformations needs to be proven. Intrinsics and hand-written SIMD aren't going away.
    - pcwalton 12y ago
      > This avoids problems with register allocation and code gen, consistency/portability between compilers, etc. Yup. Which just goes to show: reliability is king.
  - simonster 12y ago
    I appreciate that autovectorization is hard to do well. However, I think the world of JS is different from the world of C/C++. JS optimization is already pretty unpredictable, since the language is dynamic (both in terms of typing and e.g. object memory layout, with the exception of typed arrays); JS primitives are farther from the metal; the optimizations that JS engines perform are implementation-specific, rarely well-documented and always in flux; and it's difficult to see what machine code actually runs for a given JS function. SIMD instructions may make some sense for JS as a compiler target, but they seem to make less sense for JS as a language that doesn't have integers or 32-bit floating point numbers. On top of that, most users of vectorization are targeting a specific architecture or even CPU, whereas JS code is meant to run anywhere. It doesn't seem like there's been much work to alter the language or tools to make it easier for programmers to reason about other sources of unpredictability, so why so much emphasis on SIMD? I'll admit some ignorance here, but it also seems to me that a JIT may also have some advantages WRT autovectorization as compared with a static compiler, since you can collect runtime information about aliasing and loop trip count before choosing to vectorize. But if the point is to make performance easier to reason about, why not start with the rest of the language before worrying about vectorization?
- viraptor 12y ago
  I think it's wrong to show it as an either-or situation. Compilers can and do use both explicit operations and auto-vectorisation in the same program. GCC for example does some automation on the loops, but also allows you to use the primitives directly. Why wouldn't we want the same in JS?
azakai 12y ago
I think you're rushing to judgement pretty quickly here. For example, > 2. Identify proper use cases. The example are quite bogus currently. They show a mandelbrot. That's just one tiny demo. See the github repo discussions for lots of debate on use cases, https://github.com/johnmccutchan/ecmascript_simd/issues https://github.com/johnmccutchan/ecmascript_simd/issues This has been discussed very intensively, with input from people from Intel, Mozilla, and Google. Feel free to join in as well. In general, while I sympathize to some extent with you and the Apple position here, you are fighting a strong trend in the industry. C has a SIMD API, C# has SIMD API, Dart has a SIMD API, etc. - all those were created for good reasons. Autovectorization would be great - hopefully Apple can prove it beats the API approach - but no compiler has proven it thus far, hence SIMD APIs in all those languages I mentioned.
- general_failure 12y ago
  Thanks for the link! I tried going through the issues (randomly clicking) but I am not seeing use cases. https://github.com/johnmccutchan/ecmascript_simd/issues/89 https://github.com/johnmccutchan/ecmascript_simd/issues/89 https://github.com/johnmccutchan/ecmascript_simd/issues/85 https://github.com/johnmccutchan/ecmascript_simd/issues/85 https://github.com/johnmccutchan/ecmascript_simd/issues/84 https://github.com/johnmccutchan/ecmascript_simd/issues/84 They are good technical discussions. What I am looking for is use cases for people to use in websites.
  - pcwalton 12y ago
    Vertex skinning [1] (code at [2]) is a classic example. (This code is not vectorized, but it could easily be and is usually vectorized via intrinsics in games.) Any 3D game that wants to animate human characters over a long period of time is likely to be using this technique. Since we want games to run on the Web, of course, this is a use case for Web sites. [1]: http://en.wikipedia.org/wiki/Skeletal_animation http://en.wikipedia.org/wiki/Skeletal_animation [2]: https://github.com/h4writer/arewefastyet/blob/master/benchmarks/asmjs-ubench/skinning.cpp https://github.com/h4writer/arewefastyet/blob/master/benchma...
    - 12y ago
sunfish 12y ago
For historical reasons, every language that wanted one built their own SIMD API instead of building a language-independent API first: C++, C#, Dart, OpenCL, and so on, and it's not easy to go back and change that. However, there is a lot of commonality between the SIMD APIs in those languages, so we are following de-facto standards here. And, we certainly do have real-world use cases in mind. See [0] for one example. We're also interested in using SIMD for video codec development which can't always be done on GPUs. [0] http://blogs.unity3d.com/2014/10/07/benchmarking-unity-performance-in-webgl/ http://blogs.unity3d.com/2014/10/07/benchmarking-unity-perfo... And if, in the future, Apple can show that auto-vectorization in this domain is more successful than their attempts so far have shown it to be, then JS engines can always just go back to implementing SIMD.js via a simple polyfill which the engine can auto-vectorize, leaving very little baggage in the language or implementations.
Daiz 12y ago
>2. Identify proper use cases. SIMD is used a lot in all kinds of things dealing with video, so that's one area where it could find uses. I wouldn't mind being able to do (realtime) video processing in the browser. Some relevant reading that mentions SIMD.js briefly (though mostly that it wasn't really useful at all at the time of writing): http://tp7.pw/articles/javascript-video-filtering/ http://tp7.pw/articles/javascript-video-filtering/
- mcintyre1994 12y ago
  Physics simulation is a pretty big one too - at least it's what we used when we were learning to use SIMD intrinsics in C.
deleted 12y ago
[deleted]
Symmetry 12y ago
It looks like the vector proposals aren't tied to any particular implementations and could be used to help extract parallelism via SIMT, VLIW, microthreads, or various other techniques in addition to the SIMD units you'd find in x86 or ARM.
ahoge 12y ago
> What about pixel manipulation of images? We got this years ago. You can do per-pixel stuff via the Canvas 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.
- ndesaulniers 12y ago
  > "will this vectorize?" Yes, but _will it blend?_
- jallmann 12y ago
  > (games, video codecs, etc.) prefer the intrinsics Nit: Most of the projects I'm familiar with (libav/ffmpeg, x264, etc) prefer to break out the SIMD into hand-written functions, instead of relying on intrinsics or even inline asm. This avoids problems with register allocation and code gen, consistency/portability between compilers, etc. Otherwise, yes, autovectorization is hard, both for application developers and compiler writers. Application code needs to be structured in a very precise way, and the correctness of C -> SIMD transformations needs to be proven. Intrinsics and hand-written SIMD aren't going away.
  - pcwalton 12y ago
    > This avoids problems with register allocation and code gen, consistency/portability between compilers, etc. Yup. Which just goes to show: reliability is king.
- simonster 12y ago
  I appreciate that autovectorization is hard to do well. However, I think the world of JS is different from the world of C/C++. JS optimization is already pretty unpredictable, since the language is dynamic (both in terms of typing and e.g. object memory layout, with the exception of typed arrays); JS primitives are farther from the metal; the optimizations that JS engines perform are implementation-specific, rarely well-documented and always in flux; and it's difficult to see what machine code actually runs for a given JS function. SIMD instructions may make some sense for JS as a compiler target, but they seem to make less sense for JS as a language that doesn't have integers or 32-bit floating point numbers. On top of that, most users of vectorization are targeting a specific architecture or even CPU, whereas JS code is meant to run anywhere. It doesn't seem like there's been much work to alter the language or tools to make it easier for programmers to reason about other sources of unpredictability, so why so much emphasis on SIMD? I'll admit some ignorance here, but it also seems to me that a JIT may also have some advantages WRT autovectorization as compared with a static compiler, since you can collect runtime information about aliasing and loop trip count before choosing to vectorize. But if the point is to make performance easier to reason about, why not start with the rest of the language before worrying about vectorization?
viraptor 12y ago
I think it's wrong to show it as an either-or situation. Compilers can and do use both explicit operations and auto-vectorisation in the same program. GCC for example does some automation on the loops, but also allows you to use the primitives directly. Why wouldn't we want the same in JS?

azakai 12y ago

I think you're rushing to judgement pretty quickly here. For example, > 2. Identify proper use cases. The example are quite bogus currently. They show a mandelbrot. That's just one tiny demo. See the github repo discussions for lots of debate on use cases, https://github.com/johnmccutchan/ecmascript_simd/issues https://github.com/johnmccutchan/ecmascript_simd/issues This has been discussed very intensively, with input from people from Intel, Mozilla, and Google. Feel free to join in as well. In general, while I sympathize to some extent with you and the Apple position here, you are fighting a strong trend in the industry. C has a SIMD API, C# has SIMD API, Dart has a SIMD API, etc. - all those were created for good reasons. Autovectorization would be great - hopefully Apple can prove it beats the API approach - but no compiler has proven it thus far, hence SIMD APIs in all those languages I mentioned.

general_failure 12y ago
Thanks for the link! I tried going through the issues (randomly clicking) but I am not seeing use cases. https://github.com/johnmccutchan/ecmascript_simd/issues/89 https://github.com/johnmccutchan/ecmascript_simd/issues/89 https://github.com/johnmccutchan/ecmascript_simd/issues/85 https://github.com/johnmccutchan/ecmascript_simd/issues/85 https://github.com/johnmccutchan/ecmascript_simd/issues/84 https://github.com/johnmccutchan/ecmascript_simd/issues/84 They are good technical discussions. What I am looking for is use cases for people to use in websites.
- pcwalton 12y ago
  Vertex skinning [1] (code at [2]) is a classic example. (This code is not vectorized, but it could easily be and is usually vectorized via intrinsics in games.) Any 3D game that wants to animate human characters over a long period of time is likely to be using this technique. Since we want games to run on the Web, of course, this is a use case for Web sites. [1]: http://en.wikipedia.org/wiki/Skeletal_animation http://en.wikipedia.org/wiki/Skeletal_animation [2]: https://github.com/h4writer/arewefastyet/blob/master/benchmarks/asmjs-ubench/skinning.cpp https://github.com/h4writer/arewefastyet/blob/master/benchma...
  - 12y ago

sunfish 12y ago

For historical reasons, every language that wanted one built their own SIMD API instead of building a language-independent API first: C++, C#, Dart, OpenCL, and so on, and it's not easy to go back and change that. However, there is a lot of commonality between the SIMD APIs in those languages, so we are following de-facto standards here. And, we certainly do have real-world use cases in mind. See [0] for one example. We're also interested in using SIMD for video codec development which can't always be done on GPUs. [0] http://blogs.unity3d.com/2014/10/07/benchmarking-unity-performance-in-webgl/ http://blogs.unity3d.com/2014/10/07/benchmarking-unity-perfo... And if, in the future, Apple can show that auto-vectorization in this domain is more successful than their attempts so far have shown it to be, then JS engines can always just go back to implementing SIMD.js via a simple polyfill which the engine can auto-vectorize, leaving very little baggage in the language or implementations.

Daiz 12y ago

>2. Identify proper use cases. SIMD is used a lot in all kinds of things dealing with video, so that's one area where it could find uses. I wouldn't mind being able to do (realtime) video processing in the browser. Some relevant reading that mentions SIMD.js briefly (though mostly that it wasn't really useful at all at the time of writing): http://tp7.pw/articles/javascript-video-filtering/ http://tp7.pw/articles/javascript-video-filtering/

mcintyre1994 12y ago
Physics simulation is a pretty big one too - at least it's what we used when we were learning to use SIMD intrinsics in C.

deleted 12y ago

[deleted]

Symmetry 12y ago

It looks like the vector proposals aren't tied to any particular implementations and could be used to help extract parallelism via SIMT, VLIW, microthreads, or various other techniques in addition to the SIMD units you'd find in x86 or ARM.

ahoge 12y ago

> What about pixel manipulation of images? We got this years ago. You can do per-pixel stuff via the Canvas API.