WebDSP Media Library and WebAssembly Video Editor Demo | Hacker News Reader

WebDSP Media Library and WebAssembly Video Editor Demo

github.com

85 pointsindescions_201715 comments

Note, that these simple image filters could be made with WebGL and run like 50 times faster than WASM or JS.

Also, you can not just say that "a language is faster than another language". In current modern web browsers, you can write JS programs, that are equally perfromant, as the WASM program (WASM would be at most 10 - 20 percent faster). So if you see JS being slower in this case, maybe it just was not written properly.

So, in my opinion, the true benefit of WASM is the ability to compile into it from other low-level languages, but not the preformance.

> So, in my opinion, the true benefit of WASM is the ability to compile into it from other low-level languages, but not the preformance.

That may be true for now, but there are other advantages that have at least something to do with performance.

For one thing, wasm bytecode can be decoded much faster than JavaScript can be parsed. I'm not really aware of situations when parsing speed is an issue, but I imagine there are situations where this is nice.

In general, it will be easier to add new features to wasm compared to JavaScript. Presumably this means features like threads will land in wasm much sooner than in JavaScript, but we'll see.

> For one thing, wasm bytecode can be decoded much faster than JavaScript can be parsed

True, but as long as you have space for cache, it only goes faster once. Wasm is also loaded by JS itself and of limited usage right.

I think the first comment is actually accurate about the state of wasm. It only brings value to people compiling from C/C++ to the web. It is not a technology of the future, but a retrofit for the past.

> I'm not really aware of situations when parsing speed is an issue, but I imagine there are situations where this is nice.

When it's a big transpiled application (ex: games, the "Run Windows 95 in Your Browser" demos), it has a real impact since the binary is just so large. This is probably the biggest jump between asm.js and WebAssembly.

> you can write JS programs, that are equally perfromant, as the WASM program (WASM would be at most 10 - 20 percent faster). So if you see JS being slower in this case, maybe it just was not written properly.

I think that is a pretty bold claim without anything to back it up. I've never seen anything that indicates that while having seen a lot to the contrary.

You can skip type checks, avoid unboxing performance hits, avoid changing map deoptimization, use integer for math heavy computation instead of doubles and the list goes on.. The potentials for speedups is significant.

It all sounds quite complex when you say it like this. But current JS engines can already do it and they do it very well (and efficiently). They even use integer arithmetic when it is possible.

By the speedup, I expect you mean the "preparation" speedup, not the execution speedup. It depends on what you do. But in most of cases, the preparation speedup will not be so significant.

I meant faster execution. Browsers don't do that and can't do that because of the dynamic nature of JS.

Chrome can do 31bit signed integer computation when it seems it possible, but it still needs to be converted to 64bit doubles most of the time.

I work on a very compute intensive application and have profiled JS under Chrome down to the generated bytecode for countless hours..

I think you have no idea what you are talking about. Browsers do that and can do that. What do you mean by a "dynamic nature of JS" and why is it a problem?

Integers are not converted to doubles when it is not necessary. Can you show me what bytecode do you mean?

I obviously also feel you have no idea what you are talking about and so far you have provided no supporting evidence or justification to your argument. Nor did you elaborate on your experience on the topic.

I don't care enough about you or this argument to pursue it further. Please, do your own research..

This is a great example of how much faster WebAssembly can be for some applications!

On the topic of video editing, though, this will be even faster still once WebAssembly supports threads[1]

[1] https://github.com/WebAssembly/design/issues/1073

My observation on their demo, with 64-bit Firefox Nightly for Windows on a Surface Book (i7-6600U, using integrated graphics):

• For most of the filters, WebAssembly averages 10–40% slower than JavaScript;

• For some of the filters, WebAssembly averages −10%–40% faster than JavaScript;

• For Super Edge, WebAssembly averages 10–20× faster than JavaScript;

• Beards look even cooler than normal with Super Edge (though I wouldn’t want my beard to look like that in real life).

What I always found interesting is the (psychological) asymmetry

+50% means 50% slower

-50% means twice as fast

(or with stocks, going down 50% means you lose half of your money, going back to the original value means you double your investment (for new investors) which I think basically drives stock market investments)

Also, one reason I am excited about WebAssembly is because it is a low-level target for compiled languages that is also cross-platform. I know others exist, too, but I think this being the web will cause more and more people to get into writing compiled languages :)

And SIMD: https://github.com/WebAssembly/design/issues/1075

Reply on news.ycombinator.com