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

71–78 of 78 posts

Re: Introducing SIMD.js

#71

Post by anon1385 »

pcwalton wrote: post #26
general_failure wrote: post #24

Earlier quoted context omitted.

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

>Making a thread-safe GC perform as well as today's highly-optimized single-threaded GCs is hard.

That is entirely a problem of your own making. You decided to bet hard on single threaded dynamic Javascript being a suitable model for all end user software. It turns out it isn't, but it's too late now.

This kind of thing is exactly why Javascript isn't a good choice as a general purpose VM platform. Which you are presumably aware of because you aren't writing the next generation of Firefox in Javascript, you are creating Rust. But apparently what isn't good enough for Mozilla is good enough for everybody else…

Which brings us to the real problem with the web - everybody except the browser vendors is a second class citizen.

Re: Introducing SIMD.js

#72

Post by anon1385 »

ndesaulniers wrote: post #28
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

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.

Re: Introducing SIMD.js

#73

Post by maccard »

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.

Simd optimisations aren't very minor. For games anyway, we have a 90-10 rule (90% of time is spent inside 10% of the code) I'm sure that exists in other areas too. One of the most common operations performed is multiplying 4x4 matrices, which can get 300% speed ups with the correct simd operations. To get that speed up in the most called parts of your code is anything but minor

Re: Introducing SIMD.js

#75

Post by tedmielczarek »

anon1385 wrote: post #72
ndesaulniers wrote: post #28

Earlier quoted context omitted.

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

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.

This is demonstrably untrue, as we've implemented a number of specs that originated elsewhere. (WebAudio, WebRTC). Just because something has a spec doesn't mean it is sensible to implement, however. As Vlad points out, there's no mobile implementation of that technology, so it doesn't make sense for us to push it, especially when there's an alternative spec that does have traction.

As for image formats, there was a table going around Twitter that I can't find now showing implementation of new image formats by browser. Basically Google implemented WebP, Microsoft implemented JPEG XR, and Apple implemented JPEG2000 (IIRC). There is no consensus in that space.

Re: Introducing SIMD.js

#76

Post by cliffbean »

J_Darnley wrote: post #74

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

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.

Re: Introducing SIMD.js

#77

Post by anon1385 »

tedmielczarek wrote: post #75
anon1385 wrote: post #72

Earlier quoted context omitted.

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.

This is demonstrably untrue, as we've implemented a number of specs that originated elsewhere. (WebAudio, WebRTC). Just because something has a spec doesn't mean it is sensible to implement, however. As Vlad points out, there's no mobile implementation of that technology, so it doesn't make sense for us to push it, especially when there's an alternative spec that does have traction. As for image formats, there was a…

>As for image formats, there was a table going around Twitter that I can't find now showing implementation of new image formats by browser. Basically Google implemented WebP, Microsoft implemented JPEG XR, and Apple implemented JPEG2000 (IIRC). There is no consensus in that space.

There is no consensus because Mozilla have spent the last 15 years rejecting every proposed format. Mozilla (repeatedly) rejected JPEG2000 long before Chrome even existed, so you can hardly cite Chrome's lack of support as an excuse for your inaction.

Re: Introducing SIMD.js

#78

Post by legulere »

sanxiyn wrote: post #69
legulere wrote: post #54

Earlier quoted context omitted.

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.

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/

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

Post reply on HN