4 ms·

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 fas

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.

trgv 9y ago
> 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.
- batmansmk 9y ago
  > 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.
- fenwick67 9y ago
  > 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.
CyberDildonics 9y ago
> 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.
jpambrun 9y ago
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.
- IvanK_net 9y ago
  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.
  - jpambrun 9y ago
    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..
    - IvanK_net 9y ago
      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?
      - jpambrun 9y ago
        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..

trgv 9y ago

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

batmansmk 9y ago
> 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.
fenwick67 9y ago
> 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.

CyberDildonics 9y ago

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

jpambrun 9y ago

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.

IvanK_net 9y ago
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.
- jpambrun 9y ago
  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..
  - IvanK_net 9y ago
    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?
    - jpambrun 9y ago
      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..