Hacker News Reader

Comment by kevincox | Hacker News Reader

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/) 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 (preview available on chromium)

View on HN

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)

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.

>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?

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

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.

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...

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)

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.

Reply on news.ycombinator.com