4 ms·

Unfortunately SIMD is still not supported on any browsers and with the move away from SIMD.js it looks like this might take a while. We've been working on port

Unfortunately SIMD is still not supported on any browsers and with the move away from SIMD.js it looks like this might take a while. We've been working on porting over our fairly large barcode scanner library to WebAssembly. While the performance is close to what we have on other platforms ( http://websdk.scandit.com http://websdk.scandit.com ), the major bottleneck for now is not being able to use optimized code relying on SIMD (and not having an existing C fallback as all other platforms we target have SIMD support)

steveklabnik 9y ago
My understanding is that SIMD support has a proposal that most people are happy with, and will be landing in 2018.
- titzer 9y ago
  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.
zurn 9y ago
SIMD is like the kids version of GLSL, which works today :)
- tomxor 9y ago
  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).
  - zurn 9y ago
    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.
    - tomxor 9y ago
      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.
      - zurn 9y ago
        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.
        tomxor 9y ago
        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.
- exDM69 9y ago
  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.
  - baybal2 9y ago
    >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
    - wereHamster 9y ago
      > shoddily written JS Blame the OS, graphics card drivers, or the browser, but not JS!
  - deleted 9y ago
    [deleted]
Klathmon 9y ago
Have you tested performance on older and lower spec devices? Does it still hold up?
- chkuendig 9y ago
  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.
  - Klathmon 9y ago
    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.
    - 9y ago
Seanny123 9y ago
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.
- tom_wilde 9y ago
  www.nengo.ai wow, this is really cool! thx for sharing :]
noir_lord 9y ago
The barcode scanner is really impressive, it worked well on my G5 plus running FF. I'm excited for WebAssembly.
josteink 9y ago
> 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?
- mastax 9y ago
  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.
- zurn 9y ago
  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.

steveklabnik 9y ago

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

titzer 9y ago
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.

zurn 9y ago

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

tomxor 9y ago
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).
- zurn 9y ago
  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.
  - tomxor 9y ago
    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.
    - zurn 9y ago
      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.
      - tomxor 9y ago
        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.
exDM69 9y ago
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.
- baybal2 9y ago
  >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
  - wereHamster 9y ago
    > shoddily written JS Blame the OS, graphics card drivers, or the browser, but not JS!
- deleted 9y ago
  [deleted]

Klathmon 9y ago

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

chkuendig 9y ago
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.
- Klathmon 9y ago
  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.
  - 9y ago

Seanny123 9y ago

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.

tom_wilde 9y ago
www.nengo.ai wow, this is really cool! thx for sharing :]

noir_lord 9y ago

The barcode scanner is really impressive, it worked well on my G5 plus running FF. I'm excited for WebAssembly.

josteink 9y ago

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

mastax 9y ago
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.
zurn 9y ago
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.