Assembling WebAssembly

Post by jfbastien » Wed, Jun 07, 2017, 4:13 AM UTC

zurn wrote: post #39

dwg wrote: post #20

Earlier quoted context omitted.

As I understand it, potential performance gains are higher than 2x, and we're still in a pretty early stage. It depends on your application. Also, as has been mentioned by others, WebAssembly could perhaps evolve to take a greater role, leading to a greater potential impact of performance gains. Finally, if the complexity does in fact outweigh the benefit, the idea would eventually fade away. So far it looks promisin…

Where does even the 2x come from? Currently it looks very much like 1x vs integer hinted JS code like generated by asm.js.

Post by zurn » Wed, Jun 07, 2017, 4:22 AM UTC

jfbastien wrote: post #41

zurn wrote: post #39

Earlier quoted context omitted.

Where does even the 2x come from? Currently it looks very much like 1x vs integer hinted JS code like generated by asm.js.

That is incorrect. See: https://github.com/WebAssembly/spec/blob/master/papers/pldi2... These are already old numbers, and section 7.3 says 33.7% more efficient. Were one to run updated numbers, and use more than Chrome and Firefox, I'm pretty sure the numbers would be better still.

Post by DLudwig » Wed, Jun 07, 2017, 4:29 AM UTC

flavio81 wrote: post #40

pizlonator wrote: post #14

Earlier quoted context omitted.

> I've seen numerous discussions about integrating WebAssembly with the JavaScript heap. That might not require full GC; ownership semantics might suffice (such that either wasm or JS can own the object at any given time, and within the wasm world it can use wasm memory management). Those discussions have not resulted in a proposal. Ownership semantics are most likely not going to work. The options being considered a…

> So long as this is the pattern, WebAssembly will necessarily take longer to load than JS because the same program written in wasm will be bigger than its JS variant. Binary bytecode, which is what webassembly apps are, is often, generally, almost always smaller than source code. Except for really small programs. Also, js code needs to be parsed previously. Webassembly code does not. Webassembly should load faster a…

Post by jfbastien » Wed, Jun 07, 2017, 4:38 AM UTC

tyingq wrote: post #46

badminton1 wrote: post #28

I hope wasm becomes the first class citizen and JavaScript becomes just one out of many languages that compiles to it. JavaScript is not bad at the high level, but at the low level it has been hell for engineers to implement a fast VM. A wasm VM is way easier to implement than a JavaScript VM.

I do like the upside, but coupled with DRM support, it's going to be used to obfuscate, hide and control things. I'm expecting a much less open web coming.

Post by jfbastien » Wed, Jun 07, 2017, 4:50 AM UTC

tyingq wrote: post #48

jfbastien wrote: post #47

Earlier quoted context omitted.

WebAssembly is as Turing-complete as JavaScript is, and has fewer APIs. The only API it has JS doesn't really is grow_memory, and even that can kinda be done with ArrayBuffer. I'm not sure what you think makes it the harbinger of closed web. As the WebAssembly CG chair, I'd be interested in understanding that.

I don't see it as THE harbinger, but one of many. Some people will use it for the same reasons that they obfuscate things today. See, for example, the dropbox client. It's python, but they go to great lengths to keep you from peeking behind the kimono. I understand WASM isn't reverse engineering proof, but it certainly raises the bar. Especially sans source maps.