5 ms·

So we took a performance-sensitive embarrasingly-parallel problem and made it run on a slow single-threaded language? Sounds like fun ;)

by mtrimpe 13y ago

NatW 13y ago
:) well, technically they did use a web worker in their demo, so it's on a background thread, at least.
CSDude 13y ago
Computation intensive applications can be done in multithread by easily using web workers. It is been around for a long time. See the following site for a quick benchmark. [1] [1]: http://pmav.eu/stuff/javascript-webworkers/ http://pmav.eu/stuff/javascript-webworkers/ Here are my results: 8 Workers, Test: 2^1024000000 mod 97777 = 20631, 1515 ms 4 Workers, Test: 2^1024000000 mod 97777 = 20631, 2899 ms 2 Workers, Test: 2^1024000000 mod 97777 = 20631, 5773 ms 1 Worker, Test: 2^1024000000 mod 97777 = 20631, 11508 ms
- mtrimpe 13y ago
  That doesn't work with Emscriptem though because web workers don't support shared state. [1] If they manage to move FFMPEG encoding into multiple web workers I'd love to read their writeup though! [1] https://github.com/kripken/emscripten/issues/953 https://github.com/kripken/emscripten/issues/953
joeld42 13y ago
Or you could think of it as taking a compute-intensive problem and distributing it widely. Or taking a bandwidth-bound problem and completely eliminating that bottleneck. If you've got 1000 people converting videos at once, the embarrassingly parallel isn't going to help you much on the server. This does look like fun, and really a nice validation for emscripten, and there's a ton of practical application.
- Osmium 13y ago
  True; this seems a bit silly at first glance, but imagine how much money a YouTube-like site could save if videos were converted in the user's browser before upload, rather than by the server.
  - mtrimpe 13y ago
    It's also an excellent new benchmark for JavaScript VMs. If we can get near-native performance on this it'll enable a whole new class of application.
darkchasma 13y ago
So you're saying that people should never do anything unless it has an immediate useful result?
- mtrimpe 13y ago
  I said I thought it was fun! I probably should've made up and added /!s after all :)
gngeal 13y ago
If you combine fixed-point arithmetics, tiled memory access patterns, asm.js, and dynamic image processing pipeline compilation (the way that, for example, VirtualDub did it), you'll probably discover that the "slow single-threaded language" probably isn't slow at all for image processing tasks. (And WebCL is still on the horizon.)
kevingadd 13y ago
Video encoding/decoding are in fact not embarassingly parallel. Lots of modern codecs have complex interdependencies between frames and sections of frames that make it harder to do things in parallel, as I understand it.
- mtrimpe 13y ago
  It might not be truly embarrassingly parallel anymore but H264 and VP8, the web's bread-and-butter codecs, both support multithreaded encoding and will comfortably max out all your cores.

So we took a performance-sensitive embarrasingly-parallel problem and made it run on a slow single-threaded language? Sounds like fun ;)

by mtrimpe 13y ago

So we took a performance-sensitive embarrasingly-parallel problem and made it run on a slow single-threaded language? Sounds like fun ;)

NatW 13y ago

:) well, technically they did use a web worker in their demo, so it's on a background thread, at least.

CSDude 13y ago

Computation intensive applications can be done in multithread by easily using web workers. It is been around for a long time. See the following site for a quick benchmark. [1] [1]: http://pmav.eu/stuff/javascript-webworkers/ http://pmav.eu/stuff/javascript-webworkers/ Here are my results: 8 Workers, Test: 2^1024000000 mod 97777 = 20631, 1515 ms 4 Workers, Test: 2^1024000000 mod 97777 = 20631, 2899 ms 2 Workers, Test: 2^1024000000 mod 97777 = 20631, 5773 ms 1 Worker, Test: 2^1024000000 mod 97777 = 20631, 11508 ms

mtrimpe 13y ago
That doesn't work with Emscriptem though because web workers don't support shared state. [1] If they manage to move FFMPEG encoding into multiple web workers I'd love to read their writeup though! [1] https://github.com/kripken/emscripten/issues/953 https://github.com/kripken/emscripten/issues/953

joeld42 13y ago

Or you could think of it as taking a compute-intensive problem and distributing it widely. Or taking a bandwidth-bound problem and completely eliminating that bottleneck. If you've got 1000 people converting videos at once, the embarrassingly parallel isn't going to help you much on the server. This does look like fun, and really a nice validation for emscripten, and there's a ton of practical application.

Osmium 13y ago
True; this seems a bit silly at first glance, but imagine how much money a YouTube-like site could save if videos were converted in the user's browser before upload, rather than by the server.
- mtrimpe 13y ago
  It's also an excellent new benchmark for JavaScript VMs. If we can get near-native performance on this it'll enable a whole new class of application.

darkchasma 13y ago

So you're saying that people should never do anything unless it has an immediate useful result?

mtrimpe 13y ago
I said I thought it was fun! I probably should've made up and added /!s after all :)

gngeal 13y ago

If you combine fixed-point arithmetics, tiled memory access patterns, asm.js, and dynamic image processing pipeline compilation (the way that, for example, VirtualDub did it), you'll probably discover that the "slow single-threaded language" probably isn't slow at all for image processing tasks. (And WebCL is still on the horizon.)

kevingadd 13y ago

Video encoding/decoding are in fact not embarassingly parallel. Lots of modern codecs have complex interdependencies between frames and sections of frames that make it harder to do things in parallel, as I understand it.

mtrimpe 13y ago
It might not be truly embarrassingly parallel anymore but H264 and VP8, the web's bread-and-butter codecs, both support multithreaded encoding and will comfortably max out all your cores.