Introducing SIMD.js • Hacker News Board

Re: Introducing SIMD.js

#11

Post by swartkrans » Thu, Oct 30, 2014, 5:07 PM UTC

asb wrote: post #4

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

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.

Re: Introducing SIMD.js

#12

Post by bobajeff » Thu, Oct 30, 2014, 5:19 PM UTC

asb wrote: post #4

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

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

Also, am hoping 'JavaScript Shared Memory, Atomics, and Locks' gets accepted by TC-39. https://docs.google.com/document/d/1NDGA_gZJ7M7w1Bh8S0AoDyEq...

Re: Introducing SIMD.js

#13

Post by simonster » Thu, Oct 30, 2014, 5:25 PM UTC

general_failure wrote: post #10

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 spe…

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?

Re: Introducing SIMD.js

#14

Post by azakai » Thu, Oct 30, 2014, 5:28 PM UTC

general_failure wrote: post #10

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 spe…

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

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.

Re: Introducing SIMD.js

#15

Post by pcwalton » Thu, Oct 30, 2014, 5:32 PM UTC

simonster wrote: post #13

general_failure wrote: post #10

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 spe…

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 p…

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

Re: Introducing SIMD.js

#16

Post by general_failure » Thu, Oct 30, 2014, 5:35 PM UTC

azakai wrote: post #14

general_failure wrote: post #10

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 spe…

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 This has been discussed very intensively, with input from people from Intel, Mozilla, and Google. Feel free…

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/85 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.

Re: Introducing SIMD.js

#17

Post by ecesena » Thu, Oct 30, 2014, 5:35 PM UTC

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

Re: Introducing SIMD.js

#18

Post by pcwalton » Thu, Oct 30, 2014, 5:43 PM UTC

general_failure wrote: post #16

azakai wrote: post #14

Earlier quoted context omitted.

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 This has been discussed very intensively, with input from people from Intel, Mozilla, and Google. Feel free…

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/85 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.

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

[2]: https://github.com/h4writer/arewefastyet/blob/master/benchma...

Re: Introducing SIMD.js

#19

Post by azakai » Thu, Oct 30, 2014, 5:44 PM UTC

general_failure wrote: post #16

azakai wrote: post #14

Earlier quoted context omitted.

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 This has been discussed very intensively, with input from people from Intel, Mozilla, and Google. Feel free…

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/85 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.

There are lots of issues, can take a while to find all the use cases in them (work has been ongoing for some time). But from memory I can recall that

https://github.com/johnmccutchan/ecmascript_simd/issues/59

is interesting here, it mentions, among other things, the major SIMD-using code portion from an important real-world codebase (IMVU).

Might also be relevant discussion on the emscripten repo,

https://github.com/kripken/emscripten/issues?q=is%3Aopen+is%...

as some debate happened there while implementing code generation that emits SIMD.js.

Re: Introducing SIMD.js

#20

Post by jonstewart » Thu, Oct 30, 2014, 5:45 PM UTC

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.