Sanity check jpeg-decoder, wasm, 36-cycles / pixel?

1

I am using jpeg_decoder - Rust v 0.2.6, compiled to wasm.

I am not using web workers for concurrency.

I am timing the time it takes to decompress 1000 1024x1024 jpegs (after the data is already in a shared array buffer). This is taking ~ 12 seconds on a 2-3 ghz machine, or around 24-36 cpu cycles per pixel.

Does this sound about right performance wise? On one hand, 12 seconds for 1 GB of data feels slow, but 24-36 cpu cycles / pixel decompression doesn't sound too unreasonable.

Thanks!

2

It sounds reasonable. JPEG decoding benefits a lot from SIMD, but probably the WASM version doesn't get it.

1 Like
3

Interesting insight.

I decided to try it via the native in browser JS api for jpeg decoding (via creating an Image elemtn, then setting the img.src to a base 64 encoded data URL).

Turns out I can't figure out how to create Image elements in WebWorkers since they do not appear to have access to the dom.document object.

4

Can you do it via the Canvas API?

EDIT: I looked at it, and it is a mess. Maybe the best solution is to try and enable the SIMD extensions in wasm.

5

This is a wasm file that runs in Chrome on client machines (and I can not pass command line options to). Is there a way to enable SIMD from just JS/wasm land ?

6

I have not tried it myself, so take a look at this:

1 Like
7

I am not willing to put in the time to modify the jpeg library -- but thanks for sharing it. I was completely unaware that (1) wasm32 now has simd support and (2) Rust has support for it. Might rewrite some internal matrix ops with this.

8

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.