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

61–70 of 78 posts

Re: Introducing SIMD.js

#61

Post by sunfish »

DannyBee wrote: post #53
pcwalton wrote: post #15

Earlier quoted context omitted.

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…

"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 wr…

Yes, we don't expect everyone will want to program to the bare SIMD.js API directly for everything; it's also intended to provide basic functionality that higher-level libraries and even specialized languages, like Halide, can be built on (when they aren't running on ARB_compute_shader).

Re: Introducing SIMD.js

#62

Post by DannyBee »

brigade wrote: post #60
DannyBee wrote: post #59

Earlier quoted context omitted.

It's not magic. But it's not what that blog post is talking about. On some of these processors, 128 bytes of stack or so is not really "memory" (in the sense of being stored with memory), so spilling is not that bad.

That's the magic I'm talking about because it's not true; memory is memory and stack memory isn't treated specially by the processor. What it does have is a store buffer, which applies to all memory accesses and is what store forwarding uses to bypass L1.

I'm simply going to disagree with you on this one, because i can't make my evidence public :)

Re: Introducing SIMD.js

#63

Post by pcwalton »

jallmann wrote: post #32
pcwalton wrote: post #15

Earlier quoted context omitted.

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…

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

> This avoids problems with register allocation and code gen, consistency/portability between compilers, etc.

Yup. Which just goes to show: reliability is king.

Re: Introducing SIMD.js

#64

Post by viraptor »

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…

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?

Re: Introducing SIMD.js

#65

Post by corysama »

CmonDev wrote: post #5
JetSpiegel wrote: post #2

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

Python translated to Javascript. The fastest executing code ever.

https://rfk.id.au/blog/entry/pypy-js-faster-than-cpython/ "on a single carefully-tuned benchmark, after JIT warmup."

Re: Introducing SIMD.js

#66

Post by ahoge »

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…

> What about pixel manipulation of images?

We got this years ago. You can do per-pixel stuff via the Canvas API.

Re: Introducing SIMD.js

#67

Post by spankalee »

ep103 wrote: post #46
jonstewart wrote: post #20

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.

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

Apologies, but we don't push Dart. You don't have to use it. Google writes millions of lines of JavaScript a year and wants a better language, that's all.

As pcwalton says, SIMD.js evens an advantage that was in favor of Dart, while at the same time making JavaScript a better compile target for languages like Dart and asm.js languages like C++. It's also a really clean API that fits nicely onto typed arrays. What's not to like?

Re: Introducing SIMD.js

#68

Post by bobajeff »

hajile wrote: post #52

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

Does it really allow any language? That sounds nice in theory but how many complete languages have been fully implemented on top of vanilla LLVM and which version does it need? I see many experimental frontends that may one day be complete but by then LLVM will be at a new version and will likely be using a different bytecode.

I like the idea of having a language specifically for compiling to but either way someone has to build the prototype implementation. This idea of building LLVM, JVM or CLR in to browsers might be good but code is what matters when it comes to proposing standards.

Re: Introducing SIMD.js

#69

Post by sanxiyn »

legulere wrote: post #54
hajile wrote: post #52

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

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/

Re: Introducing SIMD.js

#70

Post by implicit »

jonstewart wrote: post #20

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.

We haven't hit the insanity limit quite yet.

It looks like Alon Zakai is working on something the "Emterpreter," which is a bytecode format that Emscripten could compile to to sacrifice some runtime performance for startup time. (JS parse time is quite a big deal for Emscripten applications)

I am hoping that this effort goes really really well. So well that browser engines start natively supporting this bytecode.

Then JS can actually die.

Post reply on HN