3 ms·

This is a real cool tool and I would love to see more simple tools client-side only. However I have serious concerns about the performance. When developing a so

This is a real cool tool and I would love to see more simple tools client-side only. However I have serious concerns about the performance. When developing a solver (https://ricochetrobots.kevincox.ca/ https://ricochetrobots.kevincox.ca/) I found that compared to the native performance running it in WASM was ~2x slower. (Running it on a phone compared to a laptop was another ~2x). However I doubt the native compiler was using large amounts of SIMD. IIUC video encoding often will use a large amount of SIMD instructions so I would expect the slowdown to be worse. On the other hand SIMD support in WASM is in progress: https://www.chromestatus.com/feature/6533147810332672 https://www.chromestatus.com/feature/6533147810332672 (preview available on chromium)

londons_explore 6y ago
I too would like to know if the performance shortcomings of webassembly are inherent to its design (ie. The sandboxing mechanism), or are just due to a poor implementation. Basic things like not being able to get stuff from CPU to screen without multiple memcpy's are all problematic too...
- oscargrouch 6y ago
  Not a compiler expert, but looking at the bytecode it looked fairly limited and minimal number of opcodes. Giving it has to be universal, i imagine where a LLVM bitcode op might translate to 1, 2 or 3 native opcodes, with WebAssembly you might with much more opcodes in the native output. I mean, of course they will be able to make it better with time and effort, but i dont think we can spect a much bigger speedup in comparison with the native equivalent. Note: this is all very speculative, but by looking at it, it looked great as an accelerator, specially for math stuff, but i imagine that it will be hard even to beat the Javascript code for generic stuff giving how much it was already optimized for it. If any compiler expert here that is familiar with it want to correct in my assumptions, please feel free to do it. (Not event touching in issues like the ones you mention, like memory copy, where the compiler cannot translate the thing in a more optmized manner giving it cannot speculate about the environment and optimize for it)
cryogenicplanet 6y ago
Yeah I do think there is a performance bottleneck here with WASM being quite a bit slower than native performance. But I think the idea is that WASM performance is only going to get better as the technology keeps evolving, and that gap will be bridged. I'd say the overall performance of the tool itself is a bit mixed. There are some task where it performances really well (trimming, converting photos to montage) but some where it is horrible(transcoding to VP9)
- kevincox 6y ago
  I agree. It will keep getting better and I would much rather have these things available than not. It would be cool if the site provided the raw ffmpeg command line so that you could use it as a command builder and run it locally for large or batch jobs. Then you can choose between security and convenience or max performance. The notes you mentioned sound like fundamental ffmpeg issues rather than problems with the implementation of this tool. It can usually trim without transcoding (much of) the file and encoding VP9 is notoriously slow.
  - dylan604 6y ago
    >Then you can choose between security and convenience or max performance. How does running a transcode job in a browser provide "security and convenience" vs a native app?
    - cryogenicplanet 6y ago
      It does for non technical users or someone who wants to do a one off transcode job. Most people wouldn't be comfortable using FFmpeg in the command line. And for the people who are comfortable with that, this provide some convenience in not having to look up command(something I always do) but its never meant to be a replacement for hardcore FFmpeg users
    - kevincox 6y ago
      No need to manually install anything and sandboxing. Honestly if I had a suspicious video file I might prefer the browser option so that an ffmpeg exploit would not have access to my machine.
jelling 6y ago
I had a similar experience comparing DSP algorithms; native was faster across the board. It’s hard to get excited about WebASM if it’s slower.

londons_explore 6y ago

I too would like to know if the performance shortcomings of webassembly are inherent to its design (ie. The sandboxing mechanism), or are just due to a poor implementation. Basic things like not being able to get stuff from CPU to screen without multiple memcpy's are all problematic too...

oscargrouch 6y ago
Not a compiler expert, but looking at the bytecode it looked fairly limited and minimal number of opcodes. Giving it has to be universal, i imagine where a LLVM bitcode op might translate to 1, 2 or 3 native opcodes, with WebAssembly you might with much more opcodes in the native output. I mean, of course they will be able to make it better with time and effort, but i dont think we can spect a much bigger speedup in comparison with the native equivalent. Note: this is all very speculative, but by looking at it, it looked great as an accelerator, specially for math stuff, but i imagine that it will be hard even to beat the Javascript code for generic stuff giving how much it was already optimized for it. If any compiler expert here that is familiar with it want to correct in my assumptions, please feel free to do it. (Not event touching in issues like the ones you mention, like memory copy, where the compiler cannot translate the thing in a more optmized manner giving it cannot speculate about the environment and optimize for it)

cryogenicplanet 6y ago

Yeah I do think there is a performance bottleneck here with WASM being quite a bit slower than native performance. But I think the idea is that WASM performance is only going to get better as the technology keeps evolving, and that gap will be bridged. I'd say the overall performance of the tool itself is a bit mixed. There are some task where it performances really well (trimming, converting photos to montage) but some where it is horrible(transcoding to VP9)

kevincox 6y ago
I agree. It will keep getting better and I would much rather have these things available than not. It would be cool if the site provided the raw ffmpeg command line so that you could use it as a command builder and run it locally for large or batch jobs. Then you can choose between security and convenience or max performance. The notes you mentioned sound like fundamental ffmpeg issues rather than problems with the implementation of this tool. It can usually trim without transcoding (much of) the file and encoding VP9 is notoriously slow.
- dylan604 6y ago
  >Then you can choose between security and convenience or max performance. How does running a transcode job in a browser provide "security and convenience" vs a native app?
  - cryogenicplanet 6y ago
    It does for non technical users or someone who wants to do a one off transcode job. Most people wouldn't be comfortable using FFmpeg in the command line. And for the people who are comfortable with that, this provide some convenience in not having to look up command(something I always do) but its never meant to be a replacement for hardcore FFmpeg users
  - kevincox 6y ago
    No need to manually install anything and sandboxing. Honestly if I had a suspicious video file I might prefer the browser option so that an ffmpeg exploit would not have access to my machine.

jelling 6y ago

I had a similar experience comparing DSP algorithms; native was faster across the board. It’s hard to get excited about WebASM if it’s slower.