Hacker News Reader

Comment by IvanK_net | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com