My understanding is that SIMD support has a proposal that most people are happy with, and will be landing in 2018.

Right now there are SIMD prototypes in 3 engines (SpiderMonkey, ChakraCore, and V8) and the remaining work is standardization between them, tool support, and performance tuning. There will be an official SIMD proposal for WASM in 2018 and it should move through the standardization process pretty quickly.

This is precisely what I'm waiting for as well. I want to run the Nengo neural simulator in the browser, so I can share my research easily, but it looks like I'll have to wait a few years.

www.nengo.ai

wow, this is really cool! thx for sharing :]

> Unfortunately SIMD is still not supported on any browsers

Is SIMD portable though? Will it run good on mobile devices? And what about other non-Intel architectures in general?

Yes. Phones have SIMD. Hell, the cheapo MIPS in my router has SIMD. You use the portable simd instructions and they get compiled to native simd instructions for your platform. Just like any other part of webassembly.

Not really portable. Even x86 has lots of variation between supported operations and vector length. ARM similarly has variations between ARM versions. At least for the abandoned JS SIMD effort, they stuck to the least-common-denominator SIMD (SSE1/NEON-armv7), but it was still good for a noticeable speedup in many applications.

The barcode scanner is really impressive, it worked well on my G5 plus running FF.

I'm excited for WebAssembly.

Have you tested performance on older and lower spec devices? Does it still hold up?

On older mobile devices it can decrease significantly, but it's still much better then any known Javascript alternatives (e.g. quaggaJS) and works reasonably well even when only passing on a handful of frames/sec to the scanner library. (which happens on slower devices)

OTOH having SIMD would speed it up significantly and probably get them all up to speed.

That's interesting. We actually use quaggaJS quite heavily, and haven't found any large performance issues even on lower spec devices.

That being said it did take quite a lot of time to get to that point (tuning scan frequency, resolution, and a bunch of other things), and we looked into scandit recently (our company does use scandit in other products) and even though your library can detect and scan barcodes in worse conditions, it didn't really improve scan times or fix our biggest issues on web, which by the looks of it are the same issues you are running into. (iOS 11 being a pain in WebViews and sites added to the homescreen, and lack of the focus management APIs meaning you are at the mercy of the autofocus), plus the requirement for a license check at runtime is shooting our big use case in the foot (some of our users run the webapp offline for days at a time!)

But we have looked into some webassembly for some of this code, and I'm glad to hear it holds up about as well as expected on lower spec devices. I was worried about lower spec devices not being able to handle the larger "binaries" that WASM tends to produce.

And this is really off topic, but I'd love to pick your brain on how you "solved" the constraints issues on some devices with the getUserMedia stuff (flipping the aspect ratio requested, some devices rejecting all constraints except 2 or 3 "blessed" resolutions, problems with orientation affecting the returned resolution regardless of what was asked, etc...). I understand if you can't talk about it due to company secrets, but I figured I'd give it a shot! If you are open to it, my email is on my user page.

Unfortunately I can't get into details regarding the getUserMedia stuff, not only due to trade secrets but also being from the product team and not engineering :)

> plus the requirement for a license check at runtime is shooting our big use case in the foot

That should only be a problem with test licenses, ping us at [email protected] and we can help.

SIMD is like the kids version of GLSL, which works today :)

Running anything with the GPU introduces a huge amount of latency, it only makes sense when you need high throughput and have large enough workloads to justify the latency. SIMD code can be interleaved with normal native code with zero latency.

And then there's the fact that WebGL is so much behind the state of the art that it's not even funny. Sticking to an old version of GL/GLSL severely limits what you can do with it.

>have large enough workloads to justify the latency

Hashsum bruteforcing? It already appears to be picking up, I'm having quite frequent browser crashes these days because of shoddily written JS miners trying to do stuff on GPU

> shoddily written JS

Blame the OS, graphics card drivers, or the browser, but not JS!

Not sure what you mean (maybe i'm missing your point) but those two things are not very comparable. GLSL is an uncompiled GPU language and SIMD is a class of CPU instructions that exploit parallelism opportunities at the block level (apposed to core level like a GPU).

Both can be be used to accelerate the image processing application in question. GLSL is compiled on the fly to GPU instructions that exploit parallelism opportunities, but more so than SIMD because GPUs have greater internal paralllelism.

Yes, they share "parallelism" in the most abstract sense, but beyond that, they are completely different approaches in almost every other way.

You might try to use them to accelerate the same specific task but they have very different capabilities and performance limitations/advantages. Also one is fairly generalised and one is intended to be very domain specific, so don't share all the same types of potential application.

I'm still not sure why you insist they are not comparable. GPU compute vs CPU SIMD is a very standard comparison and image recognition applications, like the one discussed, frequently support both.

Well you've added some context in which they are comparable (some types of image processing), and I agree they are comparable given that specific context. I think that probably was your point that everyone else didn't get, but your original comment was void of context and implied some level of interchangeability, but you have to keep in mind that they are used for far more than image processing (even GLSL is), and will have very different results and very different implementations for the subset of tasks that can be accelerated by both.