search

wingman-jr-addon / wingman_jr

This is the official repository (https://github.com/wingman-jr-addon/wingman_jr) for the Wingman Jr. Firefox addon, which filters NSFW images in the browser fully client-side: https://addons.mozilla.org/en-US/firefox/addon/wingman-jr-filter/ Optional DNS-blocking using Cloudflare's 1.1.1.1 for families! Also, check out the blog!
https://wingman-jr.blogspot.com/
Other
35 stars 6 forks source link

Option to choose between webgl and wasm #90

Closed abdullahezzat1 closed 3 years ago

abdullahezzat1 commented 3 years ago

It would be great to have this option because I prefer to use wasm.

wingman-jr-addon commented 3 years ago

Based on your comment, did 2.0.1 switch you to the WebGL backend rather than the WASM one then? I'm mostly trying to trust TF.js to load the best backend - but if that's not what it's doing please let me know about it more.

Also, for what it's worth, I'm starting to experiment around a bit more with the processing methods because I have more flexibility with the new message passing architecture. You might be interested in this line for example.

abdullahezzat1 commented 3 years ago

That's exactly what I'm talking about. TF is trying to choose the "best" backend, but it's never really the right choice for everyone. For me, wasm is so much faster even on firefox 83. I'm still using v1.3 for that reason.

wingman-jr-addon commented 3 years ago

Hmmm, I've been thinking about this a bit. There are a lot of people who are not technical but who might want to use this plugin. There are many reasons that TF.js can't even try to pick the right backend, but a lot of it comes down to there not being one "right" backend for every situation. However, this code has a much more limited scope, such that it may be possible to "test" and see which one is faster. Would you find any value in something like that?

abdullahezzat1 commented 3 years ago

Testing is possible of course, but what I had in mind was just an "advanced" option that gives the freedom of choice.

abdullahezzat1 commented 3 years ago

You can do both. The default would be auto and that's when you can test. If the user specifies the backend then that's the choice.

wingman-jr-addon commented 3 years ago

@abdullahezzat1 I did not realize until tonight that SIMD - while on by default in Firefox Nightly - is off by default in the release channel. Might be something to try if you haven't already and you're looking for a speed boost. (javascript.options.wasm_simd)

wingman-jr-addon commented 3 years ago

@abdullahezzat1 So I was curious about this and decided to see how the performance stacks up when I enabled or disabled SIMD for WASM.

  1. With WASM, it is about 3300ms/img.
  2. With WASM+SIMD, it is about 800ms/img.
  3. With WebGL, it is about 74ms/img.

Huge performance boost for WASM+SIMD over WASM! I wonder how performance compares on your box? In particular, I'd be curious if you had any rough idea between WASM vs. WASM+SIMD.

abdullahezzat1 commented 3 years ago

I didn't know about SIMD but it did make a huge difference. Another thing I realized was that webgl was not hardware accelerated on my firefox so I did that as well.

WASM: 230ms/img WASM + SIMD: 125ms/img WebGL: 145ms/img

The "best" backend will differ though depending on the hardware, I think.

wingman-jr-addon commented 3 years ago

Hey thanks for the performance numbers! It is good to see the gap between our numbers as well as the relative performance on your box. You see, one of the things that I've contemplated is actually spinning up both WebGL and WASM backends as two different processors working together cooperatively. This is something the 2.x architecture finally allows me to do. On my box, the performance has been poor enough with the WASM backend that it wouldn't make a lot of sense - I would literally get maybe 1 in 10 images processed compared to WebGL. But on your box, it seems like that would potentially be a big win.

There is also something special about two types of content: the currently implemented HTML scanner for base 64 images and the future video support. Both of these are a bit special in that they use one processor for their block of work, which is often much more than one image. So generally you would want processing of that content to always go to your "fast" processor.

So maybe this would actually turn into four options:

I think that approach would be flexible enough to support current and forward-going scenarios pretty well. What do you think @abdullahezzat1 ?

abdullahezzat1 commented 3 years ago

Looks good! Keep up the good work :heart:

wingman-jr-addon commented 3 years ago

Note this is going to land on master soon - the secondary processors won't do anything yet but they will load.

wingman-jr-addon commented 3 years ago

@abdullahezzat1 This is released now in 3.0.0!

abdullahezzat1 commented 3 years ago

Works great! Thank you :heart: