Jump to content

asm.js and the future with web assembly


rich
 Share

Recommended Posts

There are negatives though. I can think of a couple straight away and I'm not convinced the benefits outweigh them.

I'm not exactly sure of all the ins and outs technically but being able to 'peek' at whatever code your client is executing is beneficial in a number of ways. An open web means exactly that, its open, people can 'peek', closed runtimes have come, but, ultimately, gone on the web. This is slightly different though but the prospect of a 'closed' web I find a very scary one.

Another negative is that build processes and moving away from JIT inherently means that development and debugging becomes harder and more time consuming. A big advantage of JS programming that is often overlooked is that development is fast. 

There are likely some technical constraints too, the article mentions something about asm being limited, so I'd guess that would cause issues, at least in the short term.

There is also the very real argument that the web platform should stop adding features for a while.

Link to comment
Share on other sites

Asm.js is not a feature though @mattstyles at least in it being a subset of Javascript that can (and is, on browser's like Chrome) parsed with the JIT. I don't want the Internet closed, but these are not the threats of big companies anti-net neutrality or walled gardens (seriously Internet.org wtf?) or censorship. I don't see a problem with compiled code any more than I see a problem with transpiled or obsfucated code.

Will everyone want to jump aboard the c++ band wagon, no of course not but choice is not a bad thing.

The other side of this is people wanting to use these technologies incorrectly because they have bought into the hype and don't care for the practical details - I have already tried to be the voice of reason on a few such discussions on this very site, but that doesn't mean I am against the technologies of\r the benefits they promise now (the time seems right to consider Asm.js where applicable) or in the future! (in the case of Web Assembly)

Link to comment
Share on other sites

I don't see any real benefits here, not for JS developers anyway.... OK, supposedly it's going to make things a bit faster, and a bit harder to understand what a piece of software is doing under the hood.

However:

  1. In the vast majority of cases, the speed boost is going to be irrelevant. Execution of actual JS code is almost never the bottleneck in real world scenarios, especially on the powerful hardware of tomorrow (not just for games, this is true for most apps too). Typically the bottleneck is drawing to your screen (whether it's canvas, webgl or dom). When it isn't that, it's the network speed or memory management, or some type of CPU/GPU synchronization problem. As I understand it, this solution won't address any of these, it will just make fast code a little bit faster, so no big deal.
  2. If you are relying on code obfuscation to protect your work, you're doing it wrong. Better obfuscation won't change this.

Not saying it's a bad idea altogether, there may be specific cases where it's beneficial. Perhaps your C++ programs automatically translated to JS will start running at an acceptable speed. I wouldn't do that (if I make a web app, I don't write it in C++), but some people will. Whether they should or not is debatable.

Link to comment
Share on other sites

4 hours ago, mattstyles said:

There are negatives though. I can think of a couple straight away and I'm not convinced the benefits outweigh them.

I'm not exactly sure of all the ins and outs technically but being able to 'peak' at whatever code your client is executing is beneficial in a number of ways. An open web means exactly that, its open, people can 'peak', closed runtimes have come, but, ultimately, gone on the web. This is slightly different though but the prospect of a 'closed' web I find a very scary one.

Another negative is that build processes and moving away from JIT inherently means that development and debugging becomes harder and more time consuming. A big advantage of JS programming that is often overlooked is that development is fast. 

There are likely some technical constraints too, the article mentions something about asm being limited, so I'd guess that would cause issues, at least in the short term.

There is also the very real argument that the web platform should stop adding features for a while.

I was thinking about that as well. Wouldn't debugging be a PITA? Exactly how would it even work?  I'm still tinkering around this 'asm' stuff so apologizes for all the questions!

Edit: Oops double post, sorry.

Edit2: I also have no problem people seeing my clientside code to be honest. Uglyfying it is enough for me, time is gold. (For the hacker, and for me spending time converting to this asm stuff). But, if there is a noticeable performance increase by using asm for a game or whatnot, I think that's very appealing.  

Link to comment
Share on other sites

The point of Web Assembly is surely not just to 'hide your code', it's about being able to code in C, compile to bytecode and then theoretically run that on any target platform at near-native speed. And, technical restrictions aside, it sounds like it's pretty close to being able to do that.

The problem is I've seen a number of threads here (and I've even thought it myself) that assumed you could perhaps compile a Box2D lib via Web Assembly, and then use that from your JS game to gain lots of extra speed - but that just isn't the case at all. The entire game needs to be compiled and run from WA, not just a part of it.

Link to comment
Share on other sites

8 hours ago, chg said:

Will everyone want to jump aboard the c++ band wagon, no of course not but choice is not a bad thing.

 

Yep, I agree the choice is a good thing, I'm just not sure I'm totally comfortable (not yet) about how it could change the landscape. I'm not against the idea, and I think it is inevitable anyway.

I think Gio has a point about JS not really being the bottleneck in most applications, but, more coding power is rarely a bad thing and opens up more possibilities. Particularly gaming of course that traditionally/usually does stress the compute power.

I guess another advantage is that it attracts more developers to the web platform, bringing new (and old) ideas and driving the platform ever forward.

Quote

The problem is I've seen a number of threads here (and I've even thought it myself) that assumed you could perhaps compile a Box2D lib via Web Assembly, and then use that from your JS game to gain lots of extra speed - but that just isn't the case at all. The entire game needs to be compiled and run from WA, not just a part of it.

I thought this too when I first heard of it, in fact I thought that was part of the idea, to optimise some of the hot paths. I guess it makes sense that the whole thing needs to be smashed into bytecode to execute. Actually, I just found this article by Axel that suggests the 2 must co-exist.

Quote

Asm.js is not a feature though, at least in it being a subset of Javascript that can (and is, on browser's like Chrome) parsed with the JIT

I didnt realise this either. I read something quite a while ago regarding C, emscripten and LLVM which compiled into asm.js and I thought it only ran in specific versions of Aurora which modified the JS engine i.e. it wouldnt work with regular ole V8, SpiderMonkey, Chakra etc. I've just re-read and my assumption was mostly wrong, it did require a specific version of Firefox but it was always intended to run everywhere.

Link to comment
Share on other sites

17 minutes ago, mattstyles said:

I didnt realise this either. I read something quite a while ago regarding C, emscripten and LLVM which compiled into asm.js and I thought it only ran in specific versions of Aurora which modified the JS engine i.e. it wouldnt work with regular ole V8, SpiderMonkey, Chakra etc. I've just re-read and my assumption was mostly wrong, it did require a specific version of Firefox but it was always intended to run everywhere.

Chrome and Edge and possibly Safari (?) are all optimising it now to some extent (eg. making use of the type hints). For a long time Chrome was all about NaCl/PNaCl though which was neat too (the details of how NaCl worked were truly beautiful).

Most of the emscripten compiled code I see in the wild doesn't seem to a "use asm" statement eg. http://blog.toonormal.com/2012/04/27/nook-and-emscripten-a-technical-look-at-c-gamedev-in-the-browser/ (sorry it's a beautiful Ludum Dare entry, I been waiting for an excuse to post it it's a crime it's so unnoticed imho NB: the screenshot in that blog post is a link to play the game)

As for using such technologies together, you can do this now, it's just a question of whether context switching overhead and ugly interop code outweighs the benefits (there are also alternative hybrid approaches such as to make JS use typed arrays more, or to compile c/c++ code to more regular object based javascript as in: Cheerp aka Duetto)
 

Link to comment
Share on other sites

Quote

The point of Web Assembly is surely not just to 'hide your code', it's about being able to code in C, compile to bytecode and then theoretically run that on any target platform at near-native speed.

Right, it's all about speed. But it's not just about bytecode being faster than JS. Web Assembly appears to support threading which means developers can make use of all CPU cores, not just one (yes, JS web workers allow use of multiple cores, but without shared memory they're usefulness is greatly limited). The increased processing power will be a boon to developers with CPU intensive apps, and those who have ideas for such apps.

Code obfuscation is just a bonus, if it's available at all. Bytecode can include unmunged identifiers, in which case a disassembler will restore the original source code complete with variable and function names. In fact, that is the case for both Java and C# bytecode. If Web Assembly follows that same tack then it will provide no obfuscation at all (although obfuscators will eventually become available just as they have for Java and C#).

Link to comment
Share on other sites

Quote

Wouldn't debugging be a PITA? Exactly how would it even work?

The browsers will need to create a new debugger for wasm which will probably include hooks allowing integration from the IDEs. But for developers it should be similar to JS debugging.

The compilation step would be little different than what many JS developers are already doing with TypeScript, Babel, and other transpilers.

Link to comment
Share on other sites

Quote

Not quite as cracked-up as I was expecting it to be

The article seemed to be mostly about asm.js, rather than wasm, so it would probably be unfair to judge wasm based on this article. As far as I can see asm.js is just a transpiler that converts C++ to JS. The only use cases I can see for that are 1) C++ developers who want to write web apps, but don't want to learn JS (although they might be better off using TypeScript instead), and 2) quickly porting existing C++ apps to the web.

Link to comment
Share on other sites

  • 2 weeks later...
On 1/21/2016 at 1:29 PM, rich said:

The problem is I've seen a number of threads here (and I've even thought it myself) that assumed you could perhaps compile a Box2D lib via Web Assembly, and then use that from your JS game to gain lots of extra speed - but that just isn't the case at all. The entire game needs to be compiled and run from WA, not just a part of it.

I also thought asm.js compiled versions of box2d and bullet3d blow pure js versions out of the water? So you're saying if i'd using the asm.js version in a js game does not gain performance benefits? What would be the reason for this?

Link to comment
Share on other sites

WebAssembly will gradually evolve from Asm.js as promised by Brendan Eich.  This guarantees forward compatibility.

Any c/c++ library can be compiled into an independent module and dynamically loadable into a running JS app. 

New features of Emscripten are in the pipeline that can further improve performance, including:

(1) Single Instruction Multiple Data (SIMD) optimization.

(2) Inter-thread communication which allows async select socket to be run by multiple threads (within Node.js of course).

(3) Threads can share a single static memory map.

Asm.js and WebAssembly bring to the table all benefits and no downsides.

Compiling complex high level language into a simpler language with small instruction set like assembly and asm.js can dramatically increase performance because these simple instruction set can map directly to hardware architecture and be processed in parallel pipelines by any contemporary vector processor, multiple-core or not.

The benefit of interpreted language like Javascript is its dynamic typing ability - ability to interpret a piece data as different high level object.  Information like object semantic can be dynamically assigned / associated with a set of low-level data ( variables and codes ) from the top down... which is perfect for the web, when new  'CONCEPTS', many high level objects, are often introduced over the web into the browser constantly, abstractly speaking.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...