6 ms·

The way I understand it, WebAssembly is all about the size of the binary and parsing overhead. Or, at a higher level, about enabling a level playing field betwe

The way I understand it, WebAssembly is all about the size of the binary and parsing overhead. Or, at a higher level, about enabling a level playing field between more languages than just JavaScript. Speed improvements from a common runtime and bytecode are certainly welcome, but if they are possible with WebAssembly, they are also be possible with plain JavaScript, and therefore shouldn't be visible in a comparison between the two. I, for one, hope that WebAssembly will enable, say, Lua as a first class citizen on the web.

rnikhil275 10y ago
Lua is already on the web. Check out the Sailor MVC Framework.
- etiene 10y ago
  Sailor author here. They probably mean on the front-end! :) For that we have Starlight (http://starlight.paulcuth.me.uk http://starlight.paulcuth.me.uk), which I use on Sailor as well. Very excited for the day we can run Lua natively on the browser!
  - rnikhil275 10y ago
    Yes. You are correct. I totally misunderstood the context.
singularity2001 10y ago
>> "but if they are possible with WebAssembly, they are also be possible with plain JavaScript" only with asm.js not with 'plain' JavaScript EDIT: sorry I completely missed the content of the OP! Wow
crocodileJS 10y ago
Javascript doesn't have the same type information as WASM, also it lacks a native 64-bit integer. The JIT can do some type inference to use integers internally in some cases, but it's not optimal. Predicting what sort of Javascript turns into what kind of native code on different JIT implementations is far from simple, too. Even if in theory, an equivalent result should be possible in some cases, it's unrealistic to expect that in practice.
hacker_9 10y ago
> Speed improvements from a common runtime and bytecode are certainly welcome, but if they are possible with WebAssembly, they are also be possible with plain JavaScript Nope, a static language will execute faster than a dynamic language, because the runtime knows precisely what type everything is and how much space to allocate. Additionally no faffing around with dictionaries for dynamic types. Currently JS engines will have to figure out the types dynamically at runtime, but even then can't always be sure so have to keep to slower dictionary lookups. Once we have a static language -> webasm, it should execute an order of a magnitude faster than JS -> webasm. Edit: Additionally, browsers will finally consume less power, CPU time and memory, because the execution runtime process will be so streamlined.
- deleted 10y ago
  [deleted]
- TeMPOraL 10y ago
  > Edit: Additionally, browsers will finally consume less power, CPU time and memory, because the execution runtime process will be so streamlined. Don't worry, the software industry (and adtech) will find new cool ways to bloat the websites so that their resource usage will be back to usual high, while offered features stay more-less the same. That's pretty much how desktop, mobile and web all have been evolving so far.
  - majewsky 10y ago
    This can also be seen the other way around. Given the speed at which websites pile on unnecessary shit, just imagine how websites would perform if browser vendors weren't busy optimizing all day long.
    - TeMPOraL 10y ago
      That only matters if browser vendors stay ahead of the bloat curve (which I'm not so sure). Otherwise, one could say that for given performance point of the system (hardware platform + browser), there's a set level of bloat software sticks at, making the perceived performance constant.
fmap 10y ago
JavaScript is JIT compiled, it has to be parsed, typechecked, interpreted and eventually compiled. WebAssembly is parsed and then translated to machine code (with a much simpler compilation pipeline). Typical JavaScript VMs have a lot of fast paths for small scripts which also benefits small benchmarks like this. For more realistic workloads, parsing and compiling takes a significant amount of time and you could skip (almost) all of it by precompiling to WebAssembly (not at the moment, since you can't generate JavaScript objects from WebAssembly yet, but that'll happen eventually). JavaScript in particular also has the problem that its semantics is an utterly horrifying mess... This forces the generated code to be very conservative and include a lot of dynamic checks and escape hatches to the interpreter. If anything, the situation is worse than with Lua, and let me remind you that LuaJIT doesn't actually compile said "escape hatches" because of code size. There are just that many of them.
exDM69 10y ago
> WebAssembly is all about the size of the binary and parsing overhead. I don't think this is a good assessment. WebAssembly needs to pass through a complete compiler backend before it can be executed. WASM needs to be parsed, an in-memory representation is produced (probably LLVM IR), data flow and control flow graphs generated, a whole bunch of optimizations take place after which normal instruction selection, scheduling and register allocation and assembly take place. This task is comparable in complexity to a JavaScript interpreter with a JIT compiler. However, JavaScript engines have optimized for a fast startup where the interpreter quickly starts running the program (while JIT'ing and optimizing in the background). WASM has (or should have) two motivators: enabling near-native performance and allowing other languages to be compiled and executed in a browser. Based on this article, there's still a long way to go with performance. Most browser APIs are not accessible from WASM without some wrappers, so there's still work to be done before other languages become a viable replacement for JS.
- bzbarsky 10y ago
  > I don't think this is a good assessment. It's not so much an assessment as one of the main stated goals of the project. The initial point of WebAssembly is to do what asm.js does but with a smaller on-the-wire size and much less processing overhead to get from the on-the-wire format to executable code. And more cross-vendor buy-in, so the results are more reliable. > an in-memory representation is produced (probably LLVM IR), It's not LLVM IR in either Firefox or Chrome, fwiw. In the case of Firefox, it's the IR that Ion (the "fastest" tier of the JIT) uses. I expect this to be a pretty common approach across browsers, actually; it lets you leverage your existing code generation infrastructure. Safari actually tried using using LLVM for this sort of thing. They stopped. See https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/ https://webkit.org/blog/5852/introducing-the-b3-jit-compiler... for details. > This task is comparable in complexity to a JavaScript interpreter with a JIT compiler. Not really. Once you've got the IR you just use your existing codepaths for it; the IR generation from webasm is a much simpler task than IR generation from JS, complete with runtime instrumentation and whatnot.
hajile 10y ago
> I, for one, hope that WebAssembly will enable, say, Lua as a first class citizen on the web. I can think of several languages I'd like to use on the web, but never really considered Lua. I'm curious. Why Lua?
- rch 10y ago
  Apart from general fitness for embedding and extending, I like the versatility of Lua tables: https://www.lua.org/pil/3.6.html https://www.lua.org/pil/3.6.html In particular, to initialize a table to be used as a record: a = {x=0, y=0} which is equivalent to: a = {}; a.x=0; a.y=0 and: a.x = nil -- removes field "x" But I think Guido's right about 0-based indexing: http://python-history.blogspot.com/2013/10/why-python-uses-0-based-indexing.html http://python-history.blogspot.com/2013/10/why-python-uses-0...
  - strainer 10y ago
    local a = {x=0,y=0} --lua table definition is very similar to var a ={x:0,y:0} //javascript object definition Lua is great but that 1-based indexing is very unfortunate - works fine in itself but clashes badly with the norm.
- Derbasti 10y ago
  Most popular dynamic programming languages are well-loved because they have huge standard libraries, which can largely not be ported to a browser sandbox. This is why I don't see how, say, Python or Ruby would be good sources of WebAssembly. Lua, on the other hand, is a tiny language. It is remarkably well-designed, with a very simple type system, a very simple syntax, but nevertheless, Lua is extremely flexible. I have spent a few years with Lue, and I have come to admire it, for it feels as flexible as Ruby, but at the same time more consistent than Python, and faster and simpler than either of those. And, needless to say, none of the inconsistencies of JavaScript. Lua's stated goal is embeddability. The whole language including the parser and the standard library fit in a few hundred Kb. The bytecode only has a handful of very simple instructions. The source code is exceedingly well-structured and easy to understand. I think Lua could be a very simple drop-in replacement for JavaScript, doing exactly the same thing that JS does today, but using a much nicer programming language. And it already comes with an object system, modules, and a string manipulation library. I like Lua.

rnikhil275 10y ago

Lua is already on the web. Check out the Sailor MVC Framework.

etiene 10y ago
Sailor author here. They probably mean on the front-end! :) For that we have Starlight (http://starlight.paulcuth.me.uk http://starlight.paulcuth.me.uk), which I use on Sailor as well. Very excited for the day we can run Lua natively on the browser!
- rnikhil275 10y ago
  Yes. You are correct. I totally misunderstood the context.

singularity2001 10y ago

>> "but if they are possible with WebAssembly, they are also be possible with plain JavaScript" only with asm.js not with 'plain' JavaScript EDIT: sorry I completely missed the content of the OP! Wow

crocodileJS 10y ago

Javascript doesn't have the same type information as WASM, also it lacks a native 64-bit integer. The JIT can do some type inference to use integers internally in some cases, but it's not optimal. Predicting what sort of Javascript turns into what kind of native code on different JIT implementations is far from simple, too. Even if in theory, an equivalent result should be possible in some cases, it's unrealistic to expect that in practice.

hacker_9 10y ago

> Speed improvements from a common runtime and bytecode are certainly welcome, but if they are possible with WebAssembly, they are also be possible with plain JavaScript Nope, a static language will execute faster than a dynamic language, because the runtime knows precisely what type everything is and how much space to allocate. Additionally no faffing around with dictionaries for dynamic types. Currently JS engines will have to figure out the types dynamically at runtime, but even then can't always be sure so have to keep to slower dictionary lookups. Once we have a static language -> webasm, it should execute an order of a magnitude faster than JS -> webasm. Edit: Additionally, browsers will finally consume less power, CPU time and memory, because the execution runtime process will be so streamlined.

deleted 10y ago
[deleted]
TeMPOraL 10y ago
> Edit: Additionally, browsers will finally consume less power, CPU time and memory, because the execution runtime process will be so streamlined. Don't worry, the software industry (and adtech) will find new cool ways to bloat the websites so that their resource usage will be back to usual high, while offered features stay more-less the same. That's pretty much how desktop, mobile and web all have been evolving so far.
- majewsky 10y ago
  This can also be seen the other way around. Given the speed at which websites pile on unnecessary shit, just imagine how websites would perform if browser vendors weren't busy optimizing all day long.
  - TeMPOraL 10y ago
    That only matters if browser vendors stay ahead of the bloat curve (which I'm not so sure). Otherwise, one could say that for given performance point of the system (hardware platform + browser), there's a set level of bloat software sticks at, making the perceived performance constant.

fmap 10y ago

JavaScript is JIT compiled, it has to be parsed, typechecked, interpreted and eventually compiled. WebAssembly is parsed and then translated to machine code (with a much simpler compilation pipeline). Typical JavaScript VMs have a lot of fast paths for small scripts which also benefits small benchmarks like this. For more realistic workloads, parsing and compiling takes a significant amount of time and you could skip (almost) all of it by precompiling to WebAssembly (not at the moment, since you can't generate JavaScript objects from WebAssembly yet, but that'll happen eventually). JavaScript in particular also has the problem that its semantics is an utterly horrifying mess... This forces the generated code to be very conservative and include a lot of dynamic checks and escape hatches to the interpreter. If anything, the situation is worse than with Lua, and let me remind you that LuaJIT doesn't actually compile said "escape hatches" because of code size. There are just that many of them.

exDM69 10y ago

> WebAssembly is all about the size of the binary and parsing overhead. I don't think this is a good assessment. WebAssembly needs to pass through a complete compiler backend before it can be executed. WASM needs to be parsed, an in-memory representation is produced (probably LLVM IR), data flow and control flow graphs generated, a whole bunch of optimizations take place after which normal instruction selection, scheduling and register allocation and assembly take place. This task is comparable in complexity to a JavaScript interpreter with a JIT compiler. However, JavaScript engines have optimized for a fast startup where the interpreter quickly starts running the program (while JIT'ing and optimizing in the background). WASM has (or should have) two motivators: enabling near-native performance and allowing other languages to be compiled and executed in a browser. Based on this article, there's still a long way to go with performance. Most browser APIs are not accessible from WASM without some wrappers, so there's still work to be done before other languages become a viable replacement for JS.

bzbarsky 10y ago
> I don't think this is a good assessment. It's not so much an assessment as one of the main stated goals of the project. The initial point of WebAssembly is to do what asm.js does but with a smaller on-the-wire size and much less processing overhead to get from the on-the-wire format to executable code. And more cross-vendor buy-in, so the results are more reliable. > an in-memory representation is produced (probably LLVM IR), It's not LLVM IR in either Firefox or Chrome, fwiw. In the case of Firefox, it's the IR that Ion (the "fastest" tier of the JIT) uses. I expect this to be a pretty common approach across browsers, actually; it lets you leverage your existing code generation infrastructure. Safari actually tried using using LLVM for this sort of thing. They stopped. See https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/ https://webkit.org/blog/5852/introducing-the-b3-jit-compiler... for details. > This task is comparable in complexity to a JavaScript interpreter with a JIT compiler. Not really. Once you've got the IR you just use your existing codepaths for it; the IR generation from webasm is a much simpler task than IR generation from JS, complete with runtime instrumentation and whatnot.

hajile 10y ago

> I, for one, hope that WebAssembly will enable, say, Lua as a first class citizen on the web. I can think of several languages I'd like to use on the web, but never really considered Lua. I'm curious. Why Lua?

rch 10y ago
Apart from general fitness for embedding and extending, I like the versatility of Lua tables: https://www.lua.org/pil/3.6.html https://www.lua.org/pil/3.6.html In particular, to initialize a table to be used as a record: a = {x=0, y=0} which is equivalent to: a = {}; a.x=0; a.y=0 and: a.x = nil -- removes field "x" But I think Guido's right about 0-based indexing: http://python-history.blogspot.com/2013/10/why-python-uses-0-based-indexing.html http://python-history.blogspot.com/2013/10/why-python-uses-0...
- strainer 10y ago
  local a = {x=0,y=0} --lua table definition is very similar to var a ={x:0,y:0} //javascript object definition Lua is great but that 1-based indexing is very unfortunate - works fine in itself but clashes badly with the norm.
Derbasti 10y ago
Most popular dynamic programming languages are well-loved because they have huge standard libraries, which can largely not be ported to a browser sandbox. This is why I don't see how, say, Python or Ruby would be good sources of WebAssembly. Lua, on the other hand, is a tiny language. It is remarkably well-designed, with a very simple type system, a very simple syntax, but nevertheless, Lua is extremely flexible. I have spent a few years with Lue, and I have come to admire it, for it feels as flexible as Ruby, but at the same time more consistent than Python, and faster and simpler than either of those. And, needless to say, none of the inconsistencies of JavaScript. Lua's stated goal is embeddability. The whole language including the parser and the standard library fit in a few hundred Kb. The bytecode only has a handful of very simple instructions. The source code is exceedingly well-structured and easy to understand. I think Lua could be a very simple drop-in replacement for JavaScript, doing exactly the same thing that JS does today, but using a much nicer programming language. And it already comes with an object system, modules, and a string manipulation library. I like Lua.