Earlier quoted context omitted.
You can just call toString on a function and Blob the string. You have to keep your head straight about the fact that scopes won't transfer (no closures), which is probably why the API doesn't do it for you.
I wonder if bundlers like WebPack could make life simpler here..
JavaScript in Parallel: Web Workers and SharedArrayBuffer
51–60 of 74 posts
Re: JavaScript in Parallel: Web Workers and SharedArrayBuffer
#52What do people actually use Web Workers for? The examples I've seen, including this one, seem contrived. I keep hoping they'll change it to allow background image manipulation, but I haven't seen much real progress in that front.
Basically to move as much processing client side as possible/reasonable so the server doesn't have to do it.
Re: JavaScript in Parallel: Web Workers and SharedArrayBuffer
#53Re: JavaScript in Parallel: Web Workers and SharedArrayBuffer
#54Earlier quoted context omitted.
You're talking about OffscreenCanvas. It's available in Firefox and nowhere else: https://developer.mozilla.org/en-US/docs/Web/API/OffscreenCa... Having said that, if you want fast image manipulation, you're probably better off doing direct manipulation of Uint8Clamped arrays anyway, since that can be much faster.
And if you can get away with it and don't mind a lot of bit shifting, it's even better working with the Uint32array which packs all 3 colors and alpha into one element which reduces your loops by 4X
Wouldn't most CPU's these days be smart enough to detect advancing the index by 4, and then using offsets?
So:
for(let i = 0; i Re: JavaScript in Parallel: Web Workers and SharedArrayBuffer
#55Earlier quoted context omitted.
And if you can get away with it and don't mind a lot of bit shifting, it's even better working with the Uint32array which packs all 3 colors and alpha into one element which reduces your loops by 4X
Because matching the native 32 word size is better for the prefetcher, right? Wouldn't most CPU's these days be smart enough to detect advancing the index by 4, and then using offsets? So: for(let i = 0; i
I have a feeling it's more of a JS JIT thing than a CPU prefetcher thing, but honestly I'm not really sure.
In my program I linked above, it was actually faster to use Uint32array everywhere and then use functions to pull the 4 color values from it and another function to push the 4 values back to a uint32.
Granted, it's been over a year since I last benchmarked that code, but I did reuse some of the image code recently and found iterating over a Uint32array to be significantly faster. (And funnily enough, manually unrolling the loop of Uint32array to something similar to what you wrote gave an additional small performance boost, but it was small enough to be not worth the extra weirdness in the code to me)
Re: JavaScript in Parallel: Web Workers and SharedArrayBuffer
#56Earlier quoted context omitted.
Because matching the native 32 word size is better for the prefetcher, right? Wouldn't most CPU's these days be smart enough to detect advancing the index by 4, and then using offsets? So: for(let i = 0; i
I'm honestly not sure why it is, but across all browsers on both ARM and x86_64 arches it was almost 3x faster than doing what you wrote. I have a feeling it's more of a JS JIT thing than a CPU prefetcher thing, but honestly I'm not really sure. In my program I linked above, it was actually faster to use Uint32array everywhere and then use functions to pull the 4 color values from it and another function to push the…
Re: JavaScript in Parallel: Web Workers and SharedArrayBuffer
#57Earlier quoted context omitted.
I'm honestly not sure why it is, but across all browsers on both ARM and x86_64 arches it was almost 3x faster than doing what you wrote. I have a feeling it's more of a JS JIT thing than a CPU prefetcher thing, but honestly I'm not really sure. In my program I linked above, it was actually faster to use Uint32array everywhere and then use functions to pull the 4 color values from it and another function to push the…
Thanks for the info, that might save me some benchmarking time myself in the near future ;)
At the very least it can show you some of the gotchas with bit shifting in JS (like how values often look negative until they are placed into a Uint32array then they become positive integers, and how you need to check for endianness)
Re: JavaScript in Parallel: Web Workers and SharedArrayBuffer
#58What do people actually use Web Workers for? The examples I've seen, including this one, seem contrived. I keep hoping they'll change it to allow background image manipulation, but I haven't seen much real progress in that front.
Another thing was to offload tasks such as encoding GIF frames, which is also working pretty well.
Re: JavaScript in Parallel: Web Workers and SharedArrayBuffer
#59Earlier quoted context omitted.
Thanks for the info, that might save me some benchmarking time myself in the near future ;)
If it helps, I took the class I made that converts between 4 Uint8Clamped values to a Uint32 value and vice versa into an NPM package at [0]. At the very least it can show you some of the gotchas with bit shifting in JS (like how values often look negative until they are placed into a Uint32array then they become positive integers, and how you need to check for endianness) [0] https://github.com/Klathmon/BitPacker.js
Re: JavaScript in Parallel: Web Workers and SharedArrayBuffer
#60What do people actually use Web Workers for? The examples I've seen, including this one, seem contrived. I keep hoping they'll change it to allow background image manipulation, but I haven't seen much real progress in that front.