I prefer asm.js over NaCl, especially when NaCl has been available for years, and Google still supports the ARM architecture poorly, and as a second class citizen in NaCl.
It's unacceptable that a "browser-os" that should have no problem being architecture agnostic, still gives Intel an edge with ChromeOS, because not all NaCl apps work on ARM Chromebooks. Seriously, how crazy is that?
I can understand ARM not having a serious chance on Windows laptops because of all the legacy x86 programs, but at worst it should be equal with x86 running an OS such as Chrome OS.
I agree. asm.js has several strengths over NaCl and even PNaCl:
* It is just JavaScript, so any browser can execute asm.js code, but it can be AOT compiled by some browsers for extra performance - This means every browser supports asm.js, and supports it today
* It doesn't require a new runtime or API, merely using the existing web APIs
* It is simple for other browser vendors to implement, and isn't reliant on a single implementation
* It can interface with existing JavaScript code, so it can use JS libraries and, similarly, JS code can use asm.js libraries
* It is a completely open standard
* It is architecture-independent (so's PNaCl, though)
> It is just JavaScript, so any browser can execute asm.js code, but it can be AOT compiled by some browsers for extra performance
Or JIT-compiled with phases specifically built for the kind of JS it produces e.g. Webkit's FTL tends to work very well on asm.js code, though it's not an asm.js AOT compiler.
> It doesn't require a new runtime or API, merely using the existing web APIs
That's not entirely true, AFAIK asm.js adds at least two functions to the Math namespace (imul and fround)
> Or JIT-compiled with phases specifically built for the kind of JS it produces e.g. Webkit's FTL tends to work very well on asm.js code, though it's not an asm.js AOT compiler.
This is true, too. While I think you'd get the best results from AOT compilation, it should also compile really well under JITs since it has all the type information you normally have to guess.
> That's not entirely true, AFAIK asm.js adds at least two functions to the Math namespace (imul and fround)
That's an addition to JavaScript which isn't specific to asm.js, however, and both can be polyfilled. Math.fround, in particular, is useful outside of asm.js.
The stuff asm.js needs is all part of standard JS now, while NaCl and PNaCl require their own special API (Pepper) which only has one implementation (Google's).
I agree with these points. There is at least one major flaw, though: asm.js can probably never be made into a truly multithreading platform (without becoming a really ugly hack), where I can see that happen for NaCl. This is a pity, because multithreading is something you need for making responsive applications (GUI not hanging when a computation occurs in the background). Yes, there's webworkers, but I don't consider them a multithreading solution, because they don't allow a shared address space for inter-thread communication (only message-passing). This can be detrimental for performance, because the "structural sharing" paradigm becomes useless.
I think that a base-language without support for garbage collection would be preferable. The main advantage is that multithreading is easier to implement. (Any language built on top of this language could implement its own garbage collection, in principle.)
> There is at least one major flaw, though: asm.js can probably never be made into a truly multithreading platform
Are you sure? I believe I heard somewhere that Mozilla might be working on that by sharing a typed array across Web Workers.
I previously thought you couldn't do multi-threading, but now that I think about it, there's no real architectural reason you couldn't allow sharing a typed array between web workers, it's the DOM that's the problem.
And if you can share a typed array, you have a shared address space, as asm.js uses typed arrays for its heap.
Interesting! Yes, that would help a lot, but I'm not sure how growing heaps will be modeled then (are they allocated block by block?) And how is a growing heap communicated in practice between threads? Is every read-operation to be guarded by a check if the corresponding block is available in the current thread?
(It's unclear how that would work with heaps shared between threads, but so are most issues regarding threads - still just fairly early experimentation there, last I heard.)
What I'm wondering is what a pointer-dereference would look like. Is every pointer dereference in asm.js implemented by TWO dereferences (one to find the heap, and then one to find the index within the heap)? And are there mutexes (or other synchronization directives) used per dereference in a typical implementation?
It's still being designed, but we're unlikely to do anything that would require a double dereference or synchronization on each access -- that would be a lot og overhead. We'll likely seek a way to keep accesses fast by doing more work at heap resizing time, since heap resizing ought to be infrequent.
I guess the allocator would be able to manage blocks so you could view them as a single heap. At least, that's how I'd like to deal with memory as a "user". However, a "pointer" then has two parts: first, it should point to the block, and second it should have the index within that block. A stored pointer (a pointer stored within the heap) then would need 2 lookups for a dereference (first, determine the block-number, look up the block from a small array, and then lookup the index within that block). This sounds a little convoluted to me. Shouldn't there be a simpler and more efficient way to deal with growing memory?
That seems woefully underspecified compared to multithreading in C. Where's my test_and_set? How do I implement locking/mutexes? What's the equivalent of volatile in asmjs? Does it have a memory model like the Java Memory Model/OpenMP Memory Model? If you want to do safe, performant, multithreaded programming, these things need careful specification, especially in the context of optimizing compilers.
> That seems woefully underspecified compared to multithreading in C.
It's not even multithreading yet, it's just a means that support for it might be added.
Also, I don't see why you're complaining about it "compared to multithreading in C". To write for asm.js, you write in C. All this is implementation details for how the C compiler (emscripten, probably) will generate its code.
> Where's my test_and_set? How do I implement locking/mutexes? What's the equivalent of volatile in asmjs? Does it have a memory model like the Java Memory Model/OpenMP Memory Model?
> It is just JavaScript, so any browser can execute asm.js code, but it can be AOT compiled by some browsers for extra performance - This means every browser supports asm.js, and supports it today
I feel this point is slowly becoming disingenuous. If someone goes through the trouble of compiling their application to asm.js, they obviously really care about performance, because "normal" javascript wasn't good enough for them. Hell, elm/cljs/scala.js/js_of_ocaml/etc wasn't good enough. How many asm.js developers do you know that will go through the trouble of compiling a codebase to asm.js, without putting up an alert('This app works best on Firefox');?
Unless the barriers to entry for compiling to asm.js can be very significantly reduced, it will become a Mozilla-only ecosystem.
I'm a huge Mozilla fanboy, but I feel like they bit off more than they could chew here, and I think the effort would be better spent on standardizing a spec for a true VM instead of trying to back-compat-hack one into javascript.
asm.js is a compiler that produces portable standard JavaScript output, like CoffeeScript or Elm or ClojureScript, except that its source language is C or C++. The output works on any browser supporting JavaScript, including Chrome and IE. It works very well on Chrome and Mozilla (haven't tried IE recently - old IEs would be slow due to missing TypedArrays and friends, but it would still work).
Yes, the created JavaScript is annotated in a way that Mozilla uses to improve speed (and other browsers can, though they do not yet as far as I know) - but those annotations are still perfectly standard JavaScript that even the oldest IE is not confused by.
The main use that I'm familiar with for asm.js is to make use of an existing C/C++ codebase. See e.g. all of https://github.com/kripken/emscripten/wiki/Porting-Examples-... and especially the utilities section. Rewriting Poppler, GnuPlot, eSpeak or SQLite in JavaScript is no small undertaking - and asm.js makes this rewrite unneeded.
> Unless the barriers to entry for compiling to asm.js can be very significantly reduced, it will become a Mozilla-only ecosystem.
While using the asm.js toolchain may not be trivial (or it may be - I last tried it a long, long time ago), it is only the outputs that are meaningful for end users, and those outputs are already compatible with every other browser. The assertion about a Mozilla only ecosystem makes absolutely no sense.
> and I think the effort would be better spent on standardizing a spec for a true VM instead of trying to back-compat-hack one into javascript.
Those who ignore history are doomed to repeat it. This idea has been aired in some way or another since the early 60s. And yet, every single implementation has failed to deliver on the goals of a "one true VM" (yes, including the CLR, JVM, UCSD p-Code, and tens of other that did gain some traction). The best "true VM" we have today is, surprisingly, x86 and AMD64 bytecode. It has a hardware implementation, which makes it wicked fast compared to all the others - and it is also significantly lower level than any "true VM" proposed to date.
Luckily, Mozilla is learning from history and not ignoring it.
> I feel this point is slowly becoming disingenuous. If someone goes through the trouble of compiling their application to asm.js, they obviously really care about performance, because "normal" javascript wasn't good enough for them.
...what? asm.js is a compiler target for C code. It's not intended to be hand-written. It's also the default compiler target for C code on the web. You wouldn't really want to compile to anything else, except NaCl I suppose (though that requires more porting effort).
I don't get what you mean by "going through the trouble of compiling their application to asm.js" versus ""normal" javascript wasn't good enough for them.". Why would they compile to normal JS? There's no reason to: Their codebase is in C, C++, or some other native code language. If they compile to asm.js, they get a free performance boost. If they compile to JS, they just get horrible slowness. The only difference between them, here, is a single compiler flag. I don't understand.
> Hell, elm/cljs/scala.js/js_of_ocaml/etc wasn't good enough. How many asm.js developers do you know that will go through the trouble of compiling a codebase to asm.js, without putting up an alert('This app works best on Firefox');?
Why would normal JS developers be writing in asm.js? Do you even understand why asm.js exists?
> Unless the barriers to entry for compiling to asm.js can be very significantly reduced, it will become a Mozilla-only ecosystem.
What barriers to entry? You download the emscripten SDK and you compile your existing C/C++ app to asm.js.
> I'm a huge Mozilla fanboy, but I feel like they bit off more than they could chew here, and I think the effort would be better spent on standardizing a spec for a true VM instead of trying to back-compat-hack one into javascript.
If Opera/Dolphin/Safari/whatever don't ever implement optimizations for asm.js, its not really cross-platform anymore. Sure, theoretically they can execute the code, but the performance will be so far from the expectations of the developer that they will just end up telling the user to switch to Firefox (maybe Chrome if they can ever catch up).
> Why would normal JS developers be writing in asm.js? Do you even understand why asm.js exists?
Normal JS developers would use asm.js if they needed extra performance. I occasionally need extra performance out of javascript, so I use heavily optimized clojurescript, which helps for some applications. If I had exhausted those options, I would try programming in C and compiling to asm.js.
> What barriers to entry? You download the emscripten SDK and you compile your existing C/C++ app to asm.js.
Ha. You obviously haven't tried to do that yet. asm.js is intended to be a compiler target for many languages. It only succeeds for two languages (C/C++), thanks to emscriptem more than asm.js, and even that is not trivial. It takes significant effort to port most C/C++ applications...otherwise they wouldn't have their own codebases, they would just be a different target on a makefile. If it were as simple as you make it out to be, we would have hundreds of languages compiling to asm.js by now; C/C++, but also every language that compiles to C/C++ or LLVM bytecode. As it is, we have maybe a couple dozen large legacy codebases that have been ported.
> It's not a VM, there's no JIT involved.
A VM does not necessarily imply JIT, but that is beside the point. A VM executes bytecode, and asm.js is an attempt to use javascript as bytecode. Javascript wasn't designed as a VM, and several of its "features" actively subvert its use as a VM, which is why asm.js relies on guarantees that you will not use those features.
If getting the performance that asm.js developers expect out of asm.js requires the use of a browser that optimizes for asm.js, then the solution isn't cross-platform. In fact, it isn't really any better than NaCL, god forbid.
> If Opera/Dolphin/Safari/whatever don't ever implement optimizations for asm.js, its not really cross-platform anymore. Sure, theoretically they can execute the code, but the performance will be so far from the expectations of the developer that they will just end up telling the user to switch to Firefox (maybe Chrome if they can ever catch up).
I'm not sure that's really true. It doesn't have to be ultra-fast, just good enough.
> If it were as simple as you make it out to be, we would have hundreds of languages compiling to asm.js by now; C/C++, but also every language that compiles to C/C++ or LLVM bytecode. As it is, we have maybe a couple dozen large legacy codebases that have been ported.
Er, well, there aren't many languages which compile to native code. People can't compile Java, C#, JavaScript, Perl, Python, Ruby, PHP, etc. to native code. C/C++ do compile to native code, however.
> Ha. You obviously haven't tried to do that yet.
Oh, I have. I realise it has some difficulty to it.
> If getting the performance that asm.js developers expect out of asm.js requires the use of a browser that optimizes for asm.js, then the solution isn't cross-platform. In fact, it isn't really any better than NaCL, god forbid.
I'm not sure what you think asm.js is the solution to. Its purpose is for running native applications in the browser. It's not for making ordinary JS apps run fast.
> Why would normal JS developers be writing in asm.js? Do you even understand why asm.js exists?
asm.js is a compiler target, true. Is it really that much C specific? Isn't it possible to compile parts of JavaScript to asm.js? For example the parts which deal with drawing - computing points of - complex things on a canvas? That would be a good reason for JS devs to use asm.js - of course via a compiler, but if that's not available, I can imagine some people doing this by hand. Remember that people used to code in real asm all the time a few centuries ago.
> asm.js is a compiler target, true. Is it really that much C specific?
No, but I'd say it's low-level language specific. C, C++, Pascal, Swift, Go, D and the like. Not C# or Java.
> Isn't it possible to compile parts of JavaScript to asm.js?
Yes... asm.js, which is a subset of JS, can be compiled to asm.js. You can compile any language to itself. There's no real point in doing so, however.
More seriously, no, not really. JS is a dynamic language. It can't be compiled ahead-of-time.
> For example the parts which deal with drawing - computing points of - complex things on a canvas?
No, you couldn't compile that to native code. If you tried, I doubt it'd be faster than your browser's existing JIT.
> That would be a good reason for JS devs to use asm.js - of course via a compiler, but if that's not available, I can imagine some people doing this by hand. Remember that people used to code in real asm all the time a few centuries ago.
You could hand-write asm.js, but it'd be difficult. Manually manipulating the heap and stack isn't fun. There's no memory allocator included. It would make far more sense to just write in C, compile it, and write glue code, or just to write easily JIT-ed JS in the first place.
> Yes... asm.js, which is a subset of JS, can be compiled to asm.js. You can compile any language to itself. There's no real point in doing so, however.
Tell this to Google Closure Compiler folks :)
> More seriously, no, not really. JS is a dynamic language. It can't be compiled ahead-of-time.
I don't think that's true. For a counter-example consider Dylan: it's AOT compiled to binary, yet it's rather dynamic. There are many AOT compiled Scheme implementations, and Scheme is rather dynamic, too. I think you can AOT compile everything, it's just a matter of how huge a runtime you'll need to provide. There's probably a point where it's more trouble than it's worth, but in principle you should be able to compile anything. Asm itself is very dynamic language, with dynamic code generation, code rewriting or dynamic evaluation all over the place, so I really don't think there's anything preventing you from doing so. Besides how impractical that would be, of course :)
But I wasn't actually thinking of JS as a whole, but of some specific, computation-related subset of it.
For example, let's assume that I'm writing a function and I promise to only use integers in certain range and arrays with elements of same type and with fixed, immutable length. I promise never to divide by 0, and never trigger overflow, and never access an array out of bonds. It seems very restricted, but actually that's rather common in some domains. Knowing these restrictions I'd probably be able to compile my function to asm.js and have it AOT compiled, bypassing JIT, avoiding some overhead and - most importantly - knowing exactly what optimizations were used (because it was optimized by my "crippled.js" -> "asm.js" compiler).
I think I saw this idea being implemented in a couple of languages, but I don't remember exactly when it was.
Oh, and I have nothing against manual memory manipulation. I rather enjoyed working with asm on some platforms and I'm very fond of Forth. But that's me, I don't expect others to like it too.
> No, but I'd say it's low-level language specific. C, C++, Pascal, Swift, Go, D and the like. Not C# or Java.
asm.js is directly relatable to something like C, yes. But languages like C# are possible as well, if you add another step. For example, Unity compile C# into C++, then C++ into asm.js.
This would be even harder for arbitrary JS, of course, as it's much more dynamic than C#. Still, it would be an interesting experiment.
> asm.js has several strengths over NaCl and even PNaCl
Why should we have to choose one or the other? Content negotiation is your friend.
Of that liast, I think only 1 and maybe 4 are real strengths.
Strength 1 means that old browsers or browsers from uncooperative vendors can still run applications at some level of performance (which might or might not be a usable level). Probably more important, tbh, is that it alters users' perceptions of who is to blame for poor support. It seems that when a site runs fast on browser A but slowly on browser B the user tends to blame browser B, but when a site runs fast on browser A but not at all on browser B the user tends to blame the site owner. When users correctly allocate blame to uncooperative browser vendors this provides the impetus for browser vendors to reform their ways and/or for users to switch browsers.
As to point 2, the fact that asm.js means that authors and tools don't have to target a new runtime language is a pretty mixed blessing, because perforce it means that they have to continue targeting the old one, which is JS. When did "here, compile to a subset of this old high-level scripting language and we'll try to get the performance back using the latest in JIT and specialisation" become a reasonable candidate for a portable assembler system? Like a dog walking on its hind legs, it's impressive that asm.js works as well as it does, but that doesn't actually make it a reasonable approach. It only makes technical sense as part of a heroic effort to provide backwards-compatibility with JS-only browsers (see strength 1).
A completely open standard? Has there been any sign that Google is frustrating or actively opposing efforts to standardise NaCl/PNaCl? It seems that there's simply been no external effort to standardise it or interest in standardising it. Since "Web standards" are, to a good first approximation, a sock-puppet for the browser-vendor oligopoly this basically means that the other browser vendors have no desire for NaCl to become standardised. So I don't see how browser vendors telling us that NaCL is bad because Mr. Socky won't approve use of it is anything other than a childish deception. Let the other vendors make a serious, good-faith effort to standardise NaCL/PNaCl then we'll talk about lack of standardisation.
EDIT: additionally, notice how "it's a black box" has quietly disappeared from the list of the other browser vendors' complaints against NaCl? C or C++ pushed through LLVM then Emscripten and ground up into asm.js is surely just as opaque to the site users as the same C or C++ pushed through LLVM and emitted as a PNaCl or NaCl binary. But it's their black box, so that's OK.
> Why should we have to choose one or the other? Content negotiation is your friend.
You don't have to choose one or the other. I'm comparing technical merits.
> Strength 1 means that old browsers or browsers from uncooperative vendors can still run applications at some level of performance (which might or might not be a usable level).
It's more than just "usable". Chrome doesn't support asm.js, but it runs asm.js apps just dandy, albeit not quite as fast as Firefox.
> As to point 2, the fact that asm.js means that authors and tools don't have to target a new runtime language is a pretty mixed blessing, because perforce it means that they have to continue targeting the old one, which is JS.
I said runtime/API, not "runtime language". I'm referring to the DOM and other Web APIs here, vs. Chrome's Pepper. It means browsers don't need yet another set of APIs, and you get access to all the benefits of the existing set of APIs.
OK, you might not find the high-level DOM and the Web APIs that nice, but you get OpenGL ES and direct blitting, raw audio, raw controller input, and so on as well.
> When did "here, compile to a subset of this old high-level scripting language and we'll try to get the performance back using the latest in JIT and specialisation" become a reasonable candidate for a portable assembler system?
I don't see how the syntax really matters. asm.js is essentially a well-supported portable bytecode. The fact it happens to be a subset of JavaScript doesn't make it bad.
> Like a dog walking on its hind legs, it's impressive that asm.js works as well as it does, but that doesn't actually make it a reasonable approach. It only makes technical sense as part of a heroic effort to provide backwards-compatibility with JS-only browsers (see strength 1).
I don't see what's unreasonable about it. You compile native code to a portable intermediate language. It runs at near-native speed in some browsers, and reasonable speed in others. Yes, it's a subset of JS. So? Why does this bother you?
> A completely open standard? Has there been any sign that Google is frustrating or actively opposing efforts to standardise NaCl/PNaCl?
Not to my knowledge. However, NaCl implements a new set of vendor-specific APIs (Pepper) and relies on single, specific implementations (LLVM, Pepper), making it difficult, if not impossible, for other browser vendors to implement it. You can't really standardise PNaCl for the same reason you could't reasonably standardise WebSQL.
> It's more than just "usable". Chrome doesn't support asm.js, but it runs asm.js apps just dandy, albeit not quite as fast as Firefox.
Chrome is hardly the most likely problem child; older versions of IE are more likely to taking up the rear when it comes to performance.
> I don't see what's unreasonable about it. You compile native code to a portable intermediate language. It runs at near-native speed in some browsers, and reasonable speed in others. Yes, it's a subset of JS. So? Why does this bother you?
Well, the biggest and most obvious reason to be bothered (though not the only one) is the concern that the journey through JS (as opposed to generating slightly-shackled native code and running that on the client) is going to impose a performance burden that the browser's JS engine won't be able to fully eliminate, at least in some cases. If you're telling me that asm.js now consistently runs at roughly-as-good-as-native-code speeds across the board, then that is surprising but great news. It certainly didn't seem to be the case three years ago, when we were assured that it was impossible to efficiently implement bignums in code compiled to JS, but I suppose things have been moving quickly in this area. Unfortunately OP doesn't seem to fully support that idea, as it seems to imply that IonMonkey requires significant processor time to make the JS run fast. (Shuffling that overhead off to another thread may effectively remove the performance burden when running single-threaded code on a machine which has two or more idle cores and is plugged into the wall, but it comes back in other cases, including the case where several tabs are all running asm.js programs at the same time.)
> Chrome is hardly the most likely problem child; older versions of IE are more likely to taking up the rear when it comes to performance.
Older versions of IE won't run normal JS fast either. I hardly see why this is a problem.
> Well, the biggest and most obvious reason to be bothered (though not the only one) is the concern that the journey through JS (as opposed to generating slightly-shackled native code and running that on the client) is going to impose a performance burden that the browser's JS engine won't be able to fully eliminate, at least in some cases.
Are you aware of how asm.js is actually designed to function? In Firefox, asm.js is slightly-shackled native code. It's not JavaScript at all.
> In Firefox, asm.js is slightly-shackled native code. It's not JavaScript at all.
Doesn't it also has to be valid JS with the same semantics? That has to be a pretty significant constraint surely. It's not like being free to define a runtime and then sending the bytecode as JSON or something. Even leaving that aside, there's the added constraint that asm.js has to be architecture-independent, so it can't map all that closely to the native code for any particular processor. That would put it on about the same level as PNaCL, which is (or at least was) supposed to be the slower fall-back version of NaCl, rather than "native Native Client".
> Doesn't it also has to be valid JS with the same semantics?
That's correct, yes.
> That has to be a pretty significant constraint surely.
I don't think it's a terribly problematic constraint. Anything that can be done in C can be done in JS.
> Even leaving that aside, there's the added constraint that asm.js has to be architecture-independent, so it can't map all that closely to the native code for any particular processor. That would put it on about the same level as PNaCL, which is (or at least was) supposed to be the slower fall-back version of NaCl, rather than "native Native Client".
This is true. It's not quite native code or assembly, but it's very close. I suppose asm.js is better compared to C than it is to assembly.
NaCL isn't creating the expectation that it will run on IE, by saying "it's just JS, it'll run everywhere", you're creating a false expectation that it will. You're appealing to this to justify why it's better than NaCL without considering the fact that it's not relevant to whether or not it's usable wherever JS runs.
Game developers already have enough problems with CPU, RAM, and GPU fragmentation, and do this, you want to add another variable, which is they don't even get to control how their code is compiled before it runs. It's a recipe for a customer support headache.
> NaCL isn't creating the expectation that it will run on IE, by saying "it's just JS, it'll run everywhere", you're creating a false expectation that it will.
It's not a false expectation that asm.js code runs on IE, because it does. It doesn't run as fast as in Firefox, but it runs. It runs in Chrome too.
> You're appealing to this to justify why it's better than NaCL without considering the fact that it's not relevant to whether or not it's usable wherever JS runs.
At least going by benchmarks, asm.js is very much usable in non-Firefox browsers, such as Chrome and IE11. For many applications, 100% of native performance isn't needed... if it's 3x slower in IE, then it's not a problem, at least it works. For games, sure, won't run your blockbuster titles, but neither will NaCl just now. It will, however, run plenty of smaller games. The Humble Mozilla Bundle is a good demonstration of this: it works in Firefox, and it works in Chrome
> Game developers already have enough problems with CPU, RAM, and GPU fragmentation, and do this, you want to add another variable, which is they don't even get to control how their code is compiled before it runs. It's a recipe for a customer support headache.
I wasn't talking about games, I'm talking more generally. I don't like (P)NaCl because it reminds me of ActiveX: it is harmful to the open web. But if we are talking about games: I don't see why NaCl is really any less of a headache.
Only one thing is remaining - forbidding manually-written JS running in browsers as "unsafe", so that industry can focus on creating the good tool-chains for modern languages compiling to asm.js.
I'm often dismissive of Mozilla, for being so all-over-the-map and unfocused sometimes. However, I'm grateful for them being the only browser player that really does seem interested in progressing JavaScript.
All of the other players seem more focused on transpiling solutions, which are really about replacing JavaScript with something else under their control. Mozilla is pretty much the only player that genuinely works to improve JavaScript without another agenda.
asmjs is a transpiling solution. No one is going to rewrite UnityEngine in hand-written asmjs. The vast majority of asmjs code is going to be transpiled, you can literally see it in the name: asm
I think by a "transpiling solution," he means something that is transpiled from (like coffeescript or dart), as opposed to something that is transpiled to, which is asm.js.
The problem with transpiled languages is that each transpiled solution is just one language. Many of them are nice, and almost all of them are improvements on JavaScript, but they're still just languages. Asm.js basically lets you use anything you want, which is an entirely different category of solution. In particular, it lets you use languages that already exist, for which you have experience and tools and libraries and standards and whatnot.
Yes, it is a transpiling solution, but it's one that's a subset of JavaScript. This means it's compatible with all JS engines and lives in the same ecosystem.
It's quite different from, say, NaCl or Dart, which introduce a completely new language with a new set of APIs.
Dart the platform is compatible with all JS engines, Dart2JS.
I could rightly claim that DartVM is just a specialized two-stage compiler that kicks in to give a speed boost.
Compatible != portable. In the real world, performance matters. If I deploy my new triple-A game to the Web, and I'm only going to get 60fps on 25% of the browsers, and 15fps on the rest of them, do I really consider it the same ecosystem?
> If I deploy my new triple-A game to the Web, and I'm only going to get 60fps on 25% of the browsers, and 15fps on the rest of them, do I really consider it the same ecosystem?
This was always an issue on the web. Browsers have always had speed differences on that scale - either due to browser optimizations, or running on much weaker hardware (a phone vs. a powerful desktop). We've never had consistency the way consoles do, which is why AAA games run best there.
> Dart the platform is compatible with all JS engines, Dart2JS.
Not quite. Most of Dart (though not all) can compile to JS, and you can then use the JS version or the Dart version depending on browser support. That doesn't mean existing JS engines can run Dart code, it's just you can choose to fall back to Dart compiled to JS.
I don't think it's fair to characterize Traceur or TypeScript as plays to put Javascript under their author's control. Both have been useful for developing ES6, which Firefox has also been a leading implementer of. From my perspective almost all of the browser makers doing lots of cool stuff to push forward javascript and the web.
A bit of an assumption yes, here's my reasoning though. Traceur and Typescript (and perhaps Flow and AtScript) are similar efforts made by different players that require transpilation and are potential visions for a direction javascript could go in. This combined with the author's quote "All of the other players..." made me think that's the family of solutions they were referring to.
NaCl and Dart are both by a single player and there's nothing else like them that I know about but Mozilla's asm.js, which the author is praising here, so they didn't seem like likely candidates.
To me it's just the opposite. Other browser players seem willing to support a diverse ecosystem of browser languages. Mozilla is the one that wants to limit everyone to Javascript (and while you can argue how much they "control" it, it's a language that was invented for the project that's now Mozilla and has many of the same people involved).
Got 2,984 running Chrome 38 and 8,778 on Firefox 33, but I think now it's just fair to wait for couple of iterations of Chrome to identify bottlenecks and fix them.
It's not uncommon for benchmarks to focus on some particular strength/weakness that is easily fixable. The same happened with Firefox and Octane 2.0.
I'm not sure if Chrome is ever going to catch up to Firefox here. It's been slower than Firefox at asm.js ever since it was announced, because Chrome doesn't do AOT compilation for it.
EDIT: Although I suppose JIT compilers would love asm.js as it has all the type info they want, but there's probably tons of overhead there thus explaining how Chrome has worse results.
Chrome is currently slower, but the v8 team is working on a new optimizing compiler called TurboFan. There are indications in the source code that it detects asm.js code as a compiler hint of some form, hopefully this means it will eventually get quite fast on that type of content.
I don't really understand how asm.js is any different...
you've still got applications compiled into binary blob, the difference between NaCl and asm.js being that asm.js just happens to be binary encoded as executable JavaScript.
It's a blob transpiled from C, not exactly how people imagined the Web working a few years ago. It's a non-W3C/TC39 approved set of compiler intrinsics/pragmas that switches on special behavior in one particular environment.
When Dart was introduced years ago, Brendan Eich was all over HN complaining about how Dart2JS doesn't solve the problem, because DartVM would be more performance, and introduce a tendency to optimize JS VMs towards those semantics. Well, here we have a different problem. If asmjs takes off and everyone starts writing Web apps by transpiling C code, Mozilla will have forced a sea change in the Web, forcing all other vendors into ahead-of-time compilation to compete, and forcing JS VMs to optimize for this particular kind of code.
Now, maybe that's not such a bad thing. I'm not arguing it isn't, but I think arguing "it's just JS, the syntax is the same, therefore it's open!" is somewhat disingenuous. ASMJS, if super successful, would create an implicit implementation spec for everyone. It will have in essence, created a language with identical syntax to Javascript, but with completely different expected execution semantics.
Why? Because developers would come to depend on ahead-of-time compilation, depend on apps that basically use emulated malloc'ed heaps, etc.
Imagine I took the Java language, removed "new" and forced all code to allocate DirectBuffers, and then said, all classes must consist of static final methods (no polymorphism), and can't have any fields or constructors.
Call this ASMJAVA. I now assert, this is "Just java", hey, it runs in any JVM. Except, I'm shipping a new VM called "SuperExpresso" that does ahead-of-time compilation for my mobile platform based on this, and I'm telling people they don't need to use native SDKs, they can just transpile C code to Java. Did I create a new standard? I think I just did.
Arguably, you can say the same thing about Android 4.4/5.0 "ART" runtime, or GWT which I work on. They use the Java "language", but the runtime behavior is completely different, and at least for GWT, we make no bones about this.
So, this is not an attack on asmjs, but I do think there is a distinction between "reusing the syntax" of a language, and creating expectations of new semantics. Languages carry with them implicit sets of runtime performance characteristics, even bugs, that developers tend to treat holistically.
Not many people care about what the specs say. They care about how it runs in the real world.
> It's a blob transpiled from C, not exactly how people imagined the Web working a few years ago.
It's not readable, nicely-formatted JS, sure, but neither is the optimised, minified JS most sites served. It is, however, valid JavaScript. It uses open standards (ECMAScript, the various web APIs). It's already supported by all browsers.
> It's a non-W3C/TC39 approved set of compiler intrinsics/pragmas that switches on special behavior in one particular environment.
It's not "special behaviour". It's a performance optimisation. It still behaves exactly like JavaScript.
> If asmjs takes off and everyone starts writing Web apps by transpiling C code, Mozilla will have forced a sea change in the Web, forcing all other vendors into ahead-of-time compilation to compete, and forcing JS VMs to optimize for this particular kind of code.
I don't see why people would write Web apps by transpiling C code, the main advantage is for the existing codebases written in C. And other vendors don't necessarily need to implement asm.js with AOT compilation. asm.js-conformant code works well very with JIT compilers.
> Now, maybe that's not such a bad thing. I'm not arguing it isn't, but I think arguing "it's just JS, the syntax is the same, therefore it's open!" is somewhat disingenuous. ASMJS, if super successful, would create an implicit implementation spec for everyone. It will have in essence, created a language with identical syntax to Javascript, but with completely different expected execution semantics.
No, it has identical execution semantics. It uses a static subset of JS, yes, but it's still JavaScript. If I remove the "use asm" pragma, the code still does exactly the same thing.
> Why? Because developers would come to depend on ahead-of-time compilation, depend on apps that basically use emulated malloc'ed heaps, etc.
Is that bad? Bear in mind that, without asm.js existing, this was the case anyway. asm.js wasn't created so that people could compile native code to run in the browser. It was created because people were already doing so, and by detecting the code patterns commonly used by compilers, they could make it run faster.
> Call this ASMJAVA. I now assert, this is "Just java", hey, it runs in any JVM. Except, I'm shipping a new VM called "SuperExpresso" that does ahead-of-time compilation for my mobile platform based on this, and I'm telling people they don't need to use native SDKs, they can just transpile C code to Java. Did I create a new standard? I think I just did.
Sure, you made a new standard. It's a backwards-compatible one that doesn't rupture the ecosystem, though.
I got 2,996 in Firefox and 1,277 in Chrome (2013 MacBook Air 13").
Interestingly, Chrome had much worse performance for float32 than float64... yet Firefox had slightly better performance. I guess the Chrome team implemented Math.fround yet none of the optimisations which make it useful!
It's unacceptable that a "browser-os" that should have no problem being architecture agnostic, still gives Intel an edge with ChromeOS, because not all NaCl apps work on ARM Chromebooks. Seriously, how crazy is that?
I can understand ARM not having a serious chance on Windows laptops because of all the legacy x86 programs, but at worst it should be equal with x86 running an OS such as Chrome OS.