Asm.js in Firefox Nightly

VB uses garbage collection. You can't compile it to the JS subset of asm.js.

>the notion that GC somehow can't be implemented is nonsensical

http://asmjs.org/faq.html

"The asm.js model provides a model closer to C/C++ by eliminating dynamic type guards, boxed values, and garbage collection."

Sure, nothing stops you from emulating a complete CPU. Of course you can do anything.

However, how large will that JavaScript file be? Also, will it be fast enough to be usable?

I think the difficulty of implementing GC would be the lack of access to stack primitives, something that would be impossible to provide in a way that was backward compatible.

By that I mean the ability to inspect the stack and determine the values present there and determine whether or not they point to 'heap' allocated memory.

When the 'competition' is being advertised as an easy migration path for old software, then "backward compatible with IE6" means everything - it's just another way of measuring how much pain is involved in migrating some software over, only here instead of having to switch your entire corp and customers to Chrome, the change is mostly restricted to the developer toolchain.

You're continuing to perpetuate the notion that asm.js only has implications for high performance software, despite replying to a comment where I gave you a very real use case that has nothing to do with performance. And as I suspect you already know, since you seem knowledgeable, GC can easily be implemented in about a million different ways using an emulated heap on top of a typed array, so yes, even a naive implementation of VB4 could easily be made to work.

It doesn't make IE6 any faster, but the code will still run. I suspect that's what they mean by "backward compatible": it can't work miracles, but will at least do no harm.

You're missing the point. The current optimized-for-normal-javascript Chrome takes a 6x hit on asm.js code, compared to odinmonkey. That's kind-of crappy but it's not a killer, and it could get asmjs support (maybe, who knows). The fear I was talking about was browsers which are already much slower than Chrome , and have no chance in hell of ever getting asmjs support, hence the mention of IE6.

A highly obfuscated and minified JS application like GMail has about the same level of introspectability as Java bytecode. I have little problem consuming Java bytecode written 18 years ago by companies that went out of business.

Leaving aside binary format representation of portable VM code, there's also the issue that NaCl supports multithreading and asm.js doesn't. WebWorkers/Isolates are a poor substitute for high performance games.

> But it's not, by your logic a compiler producing machine-generated K&R C in the late 70s would also be a blob.

Seeing as generated C is essentially unmaintainable and unsuitable to serve as a source language, then yes.

> Native Client proponents and similar such "VM fundamentalists" are effectively claiming that we can invent such a format, when it has never been done before in the history of computer science.

I'm confused. Asm.js is an ASCII bytecode. We have plenty of other examples of abstract bytecode throughout the history of computer science, but they tend to be binary, not ascii.

Other than asm.js using a silly encoding for backwards compatibility purposes, what's the difference?

> (Pre-emptively rejecting boring VM counterexamples like Java for reasons that can be extrapolated from what I just described)

Huh? Now I'm even more confused. Are you arguing against Java's virtual machine specification, the constraints of its bytecode as defined, or what?

Notably, Android converts stack-based Java bytecode to register-based Dalvik bytecode; it's not as if the JVM bytecode strictly defines all conventions in an immutable way, or even that asm.js is all that different in practice.

I wanted to address this one last, since it's a bit of a tangent, but it demonstrates the issues of "architecture agnosticism" fairly well:

> Those C source files do not, for example, make assumptions about Harvard/von Neumann architecture, stack layout, calling conventions, the presence or absense of SIMD instructions, and so on.

That's not exactly true. If pure C is output, then yes, this is the case. In reality, especially with Harvard and modified Harvard architectures, one must take into account architecture differences to achieve reasonable performance, especially on the hardware as developed in the late 70s.

For example, there is often limited RAM, in which case one might want to store data in program space. However, C pointers do not, in any standardized way, support annotating the memory space (program, data) in which they live, and code itself can not necessarily portably extract data from program space as to operate on it as if it was in data space.

So, for a Harvard architecture, you often either wind up writing non-portable C, or you deal with inefficiencies -- some of which may not be possible to overcome, as there's only so much RAM or data storage to work with.

> Only as anyone mining the web for esoteric code will attest, anything written in standard C since probably the mid 80s and using only the ANSI C standard library can still be fed to a compiler today and produce perfectly functioning code, taking advantage of every advancement in compiler technology in the 30 years that have followed.

Have you ever actually tried this? It doesn't work.

I'm reading Eich's tweet differently. Here's the twitter exchange:

https://twitter.com/BrendanEich/status/302897797827530752

=====

Alias Cummins ‏@no_other_alias

@BrendanEich So would I be right in thinking that the point of asm.js is to tie together all the universally supported bits of JS?

BrendanEich @BrendanEich

@no_other_alias No, all of JS (ES3) is "universally supported". http://asmjs.org/ is a no-GC-pause well-typed compiler target language.

=====

@no_other_alias is asking if asm.js is about formalizing a JS subset that's universally supported (in all browsers). Eich says no, all of JS (ES3) is universally supported (so no subsetting is required for cross-browser compabitility). Asm.js is about formalizing a JS subset that can be compiled to much faster machine code.

So I don't think Eich is making a claim about asm.js backward-compatibility here.

Sadly not, I overshot the mark slightly here (what worse an advocate for your stuff than an incorrect advocate!). Typed arrays allow for things like casting, where the same chunk of 'heap' can be seen through multiple views, and interpreted as char* by one, and float* by the other.

It can't even be shimmed on IE6, since you can't overload the array indexing operator there.

It's entirely possible and easy to implement an extension/variant of Asm.js that could legitimately target these browsers, by providing shimmable names for the array indexing operation, but diminishing returns and all that..

Note nnethercote (parent comment) is one of Mozilla's engineering ninjas and author of Valgrind, it's pretty likely he knows what he's talking about here.

When you say 'dumping a new spec and VM on the community' are you referring to NaCL and Dart? Because asm.js isn't a new vm, and it already works in other browsers, like I said.

If a particular device can only run Java applications in an interpreter, that doesn't mean Java doesn't work on that device, or that Java isn't cross-platform. It just means the vendor hasn't done the work to implement a high-performance JIT (or can't).

In this case, nothing is stopping other vendors from providing high performance for ASM.js applications: The spec is being developed in the open with involvement from interested parties - not by a bunch of stakeholders at one private company - and it produces JS that works in any JS runtime. You could, if you chose, simply make ASM.js applications faster by making all JS applications faster; many of the same optimizations apply.

Any suggestion of 'support' is entirely missing the point: It's Just JavaScript. REALLY. That's it. The point is that it's JavaScript that conforms to rules (enforced on the ASM.js compiler, not the JS runtime) that enable runtimes to apply additional optimizations. Some of these rules can (and probably already do) enable a runtime to apply additional optimizations even if it is unaware of asm.js.

The most obvious example of this is the 'n | 0' pattern. When you're doing some integer arithmetic in JS, you can and probably will write this:

    var z = x * y;

But an ASM.js compliant compiler will, if x and y are both integral, write something like this [1]:

    var z = (x * y) | 0;

These both achieve the same result, but the latter provides more information to any JS runtime - not just an ASM.js one - that enables more optimizations. And in fact if you benchmark properly right now, the | 0 hint produces better performance for integer arithmetic in builds of Firefox that do not have asm.js.

[1] Technically I think it might actually spit out a call to Math.imul, and not an actual use of the mul operator. But I digress.

The dart people should make dartjs generate asm.js code.

Dart has been developed in the open as well. It's not even released in Chrome yet, it's been fully in the open for 2 years, which is most of its existence and has undergone massive revision since the original seeding of the project based on community contributes. Yes, my comment was snarky.

No matter how you slice it, adding a pragma, and requiring code to be written in an idiomatic format to gain maximum advantage by a conforming VM implementation is essentially introducing a new set of semantics to the VM. The fact that you can sneak it into the existing grammar (x|0) instead of needing to extend the grammar (int x), is a neat trick.

I fully support what asm.js is doing, I don't have any objections to it, and once the Garbage Collection support happens, I will look very hard at making GWT support it as an output format (primarily to support PlayN). But I wish Mozilla would stop peppering everyone of their press releases with a thinly veiled snipe at competitors.

> Executable != useful though. This breeds a false sense of portability.

That's already a problem with many things web though, different browsers have different performance profiles already and things leading to smooth 60fps in one browser may not do so in an other one.

The flip side for asmjs might be this: you manage 60fps on Chrome, Firefox is also at 60fps but uses less resources (since it's got special support) so you save wee birdies. That's cool.

I agree that if that were the case, it would be a problem.

However, I don't think we will see a 6x slowdown here. JavaScript engines are already very fast on compiled code, because they have already been optimizing for typed arrays and so forth for a while now. Google even added a compiled C++ benchmark to Octane, for example.

In current benchmarks, asm.js gives you a speedup of anywhere from 1x (where normal JS optimizations already got us very close to native) to 6x. So 6x is the worst case, and there are plenty of cases in the middle. A 2x-3x difference is not big enough to make something a false sense of portability, the web has tolerated 2x-3x speed differences for a long time now, and these things also change a lot in terms of who is fastest, on what, and by what.

Furthermore, I would not expect a 2x-3x difference to last very long, again, because browsers have been competing on performance of this type of code for a while now (Octane, etc.), and will continue to do so.

Well probably one could make the Dart Compiler output asm.js. Also, when you have an incompatible VM, you need to serve different content to different browsers. This, on the very least, eliminates that.

you seem to really care about standards! so basically, ActiveX is faster than dart. you should probably use that. you know. its actual native performance:)