[TazeTSchnitzel]

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)

[leoc]

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

[TazeTSchnitzel]

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

[leoc]

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

[TazeTSchnitzel]

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

[leoc]

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

[TazeTSchnitzel]

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

[cromwellian]

>Older versions of IE won't run normal JS fast either. I hardly see why this is a problem.

It's a problem for Web developers anytime there is a huge performance divergence.

[TazeTSchnitzel]

Old versions of IE also don't run NaCl. What's your point?

[masklinn]

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

[TazeTSchnitzel]

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

[amelius]

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

[TazeTSchnitzel]

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

EDIT: Aha, yes, Mozilla are working on this! https://bugzilla.mozilla.org/show_bug.cgi?id=933001

[amelius]

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?

[azakai]

Growing heaps are in progress,

http://discourse.specifiction.org/t/request-for-comments-swi...

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

[TazeTSchnitzel]

I don't know either. I'm aware that asm.js currently doesn't allow expanding the heap (it's always a fixed-size allocation), but that might change.

If you mean allocating from that heap, I imagine it'd work as it currently does: the program implements its own allocator.

[sunfish]

asm.js is indeed growing the ability to resize its heap [0]. It's already implemented in Firefox Nightly [1].

[0] http://discourse.specifiction.org/t/request-for-comments-swi... [1] https://bugzilla.mozilla.org/show_bug.cgi?id=965880

[amelius]

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?

[amelius]

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?

[cromwellian]

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.

[TazeTSchnitzel]

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

Presumably, locks would be added somehow.

[cromwellian]

pthreads exist in NaCL/PNaCL today, that's the point. There's not many big games on the market today that don't use multiple cores.

[TazeTSchnitzel]

Yes, NaCl has them today. What's your point? Yes, that means NaCl is somewhat faster for the time being. It doesn't mean it always will be.

[saosebastiao]

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

[beagle3]

You seem to have your concepts mixed.

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.

[TazeTSchnitzel]

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

It's not a VM, there's no JIT involved.

[saosebastiao]

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.

[TazeTSchnitzel]

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

[klibertp]

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

[TazeTSchnitzel]

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

[klibertp]

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

[azakai]

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

[TazeTSchnitzel]

I'm not sure you really can compile C# directly to native code. A subset, maybe, but not C# proper.

[CmonDev]

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.

[TazeTSchnitzel]

What the hell, why on earth would that be a good idea?