Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing SIMD.js

hacks.mozilla.org

Post reply on HN
Print view View original

21–30 of 78 posts

Re: Introducing SIMD.js

#21

Post by sunfish »

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…

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

Re: Introducing SIMD.js

#22

Post by IvanK_net »

What we really need is to spread WebCL - 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.

Re: Introducing SIMD.js

#23

Post by IvanK_net »

gopalv wrote: post #7

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... http://notmysock.o…

Hey, I have implemented Curves transform in JS too! :) You can find it at http://www.Photopea.com (Ctrl+M). It works pretty fast even on large images.

Re: Introducing SIMD.js

#24

Post by general_failure »

pcwalton wrote: post #18
general_failure wrote: post #16

Earlier quoted context omitted.

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]: h…

I am no expert on this but if games is the primary target, would it make sense to make some sort of vector(ization) API? Or some tesselator API.

It's honestly baffling that we keep away from threads in javascript but do all these optimizations like SIMD which are very minor. I mean practically every CPU out there has multiple cores. Workers don't cut it because they require copying data.

Re: Introducing SIMD.js

#25

Post by azakai »

general_failure wrote: post #24
pcwalton wrote: post #18

Earlier quoted context omitted.

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]: h…

I am no expert on this but if games is the primary target, would it make sense to make some sort of vector(ization) API? Or some tesselator API. It's honestly baffling that we keep away from threads in javascript but do all these optimizations like SIMD which are very minor. I mean practically every CPU out there has multiple cores. Workers don't cut it because they require copying data.

There are experiments with threads in JS, however that would be a much bigger change to the language than adding something like a SIMD API, so it is more controversial and takes longer to sort out.

Re: Introducing SIMD.js

#26

Post by pcwalton »

general_failure wrote: post #24
pcwalton wrote: post #18

Earlier quoted context omitted.

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]: h…

I am no expert on this but if games is the primary target, would it make sense to make some sort of vector(ization) API? Or some tesselator API. It's honestly baffling that we keep away from threads in javascript but do all these optimizations like SIMD which are very minor. I mean practically every CPU out there has multiple cores. Workers don't cut it because they require copying data.

> I am no expert on this but if games is the primary target, would it make sense to make some sort of vector(ization) API? Or some tesselator API.

Both of those would be harder, and less general. Game developers are asking for SIMD; they aren't asking for specialized APIs.

> It's honestly baffling that we keep away from threads in javascript but do all these optimizations like SIMD which are very minor. I mean practically every CPU out there has multiple cores. Workers don't cut it because they require copying data.

Threads aren't easy to "just add" to JS. Making a thread-safe GC perform as well as today's highly-optimized single-threaded GCs is hard. And not even counting the engineering effort required, none of the millions of lines of JavaScript out there is thread-safe. Of course we will need a way to do threads eventually, but it's much harder than SIMD.

Re: Introducing SIMD.js

#27

Post by [deleted] »

IvanK_net wrote: post #22

What we really need is to spread WebCL - 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…

[deleted]

Re: Introducing SIMD.js

#28

Post by ndesaulniers »

IvanK_net wrote: post #22

What we really need is to spread WebCL - 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…

WebCL is DOA: https://bugzilla.mozilla.org/show_bug.cgi?id=664147#c30

Re: Introducing SIMD.js

#29

Post by ndesaulniers »

pcwalton wrote: post #15
simonster wrote: post #13

Earlier quoted context omitted.

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

> "will this vectorize?"

Yes, but _will it blend?_

Re: Introducing SIMD.js

#30

Post by Daiz »

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…

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

Post reply on HN