Introducing SIMD.js
hacks.mozilla.org
Introducing SIMD.js
1–10 of 78 posts
Re: Introducing SIMD.js
#2It's official, Javascript is the new Assembly. I'll wait for the new Python, I never liked low level languages.
Re: Introducing SIMD.js
#3It's official, Javascript is the new Assembly. I'll wait for the new Python, I never liked low level languages.
I liked the "original" assembly more, at least it was designed for helping humans to write and read code.
EDIT: That said, this is good news, in a sense.
Re: Introducing SIMD.js
#4Now I'm just waiting for int64.js, which should appear when ES7 value objects come along http://www.slideshare.net/BrendanEich/value-objects2
Re: Introducing SIMD.js
#5It'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.
Re: Introducing SIMD.js
#6It's official, Javascript is the new Assembly. I'll wait for the new Python, I never liked low level languages.
ClojureScript already exists! So do Elm, Funscript, Purescript, Haxe, and a bunch of other things which transpile (might as well just start calling it "compile" now) to JS.
Re: Introducing SIMD.js
#7Neat, 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.org/code/iodine/
I want to rewrite it using something like the newly introduced float32x4, assuming I can read out the images int o RGBA tuples.
Something like a blur would actually be possible once this is fast.
Re: Introducing SIMD.js
#8It's official, Javascript is the new Assembly. I'll wait for the new Python, I never liked low level languages.
I liked the "original" assembly more, at least it was designed for helping humans to write and read code. EDIT: That said, this is good news, in a sense.
You make me wonder which assembly you're talking about. x86-64 feels heavy with legacy designs, many ways to get the same result, common pitfalls regarding memory management, and some surprising very specific gems to make some things fast… such as SIMD.
(I know little about other instruction sets.)
Re: Introducing SIMD.js
#9Neat, 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…
That applycurve function has what appears to be a gather, which is unfortunately outside of where we expect to be with the initial iteration of SIMD.js, as there isn't widespread CPU SIMD hardware support for it yet. However, the brighten function immediately above it, for example, is supported by features in the SIMD.js spec today.
Re: Introducing SIMD.js
#10Contrary 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/msg2.... The apple guys are saying they can do all this even without the API.