asm.js is the hack of the year.
Because it makes simple, to get good performance.
Probably the biggest roadblock in software development, is the cost of complexity. Many great projects fail to be realized, because of the development costs. And development costs rise exponentially with complexity. Software development needs to become simpler. The success of simple and agile programming languages, like javascript proves that. Want to learn it ? just open just browser and type some code.
This is one huge step in the right direction. It makes very easy to get good performance, on the most ubiquitous platform, the web. It makes many things possible, at lower costs. And this is the same big reason why, a platform like firefoxOS has the potential to be awesome. Because it makes things simpler.
Now I wish that the same thing done here to javascript, were also done to html, CSS, the dom, etc. The web needs simpler bases. And modularity on top of it.
I agree 100%. If only we could see similar progress in the speed of DOM updates/manipulation life would be great. The fact is that most webapp performance issues aren't JS dependent, the bottleneck is the DOM.
At that point, the only difference between "asm.js" and a "blob" is that asm.js is unreadable ascii, which the blob is unreadable binary.
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.
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. C is called "high level assembler" for a reason, just as "asm.js" is called "asm.js" for a reason.
Even if we had some standard binary format for describing software available since the 80s, it would almost certainly lack sufficient descriptive power to capture constructs that could be vectorized, or otherwise transformed using more modern compilation techniques that simply didn't exist at the time. Lowering to a binary form throws all that semantic information away. And the more you add back the more the binary form starts to look like a pointless transformation of the original source code.
Then there is the idea that such a format could ever have been designed in the 80s that would have lasted us to present day. 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.
(Pre-emptively rejecting boring VM counterexamples like Java for reasons that can be extrapolated from what I just described. Every comment on this thread brings it closer to HN's "controversiality" scoring penalty, and I'd very much like for this link to stay on the front page all day)
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.
Have you ever actually tried this? It doesn't work.
Because it isn't? It's a perfectly normal set of semantics in a language form on top of regular JS.
>in order to achieve those performance levels that you see in Mozilla, you have to interpret JavaScript as something that is not JavaScript, which requires having a spec in hand, dealing with potentially ambiguous encodings, and interpreting the asm.js as a bytecode, rather than as standard JavaScript.
All of them observations that are BESIDE the point if asm.js is a blob or not.
This leads to the question of whether (when?) someone will try to port Narcissus to it, potentially leading to a practical self-hosted JavaScript engine. "MonkeyMonkey", they could call it.
As long as the runtime is ignored though, if Chrome gets a 6x perf hit I can't even imagine how unusably slower IE6 would run.
This is basically the reason d'etre for NaCl as far as I can tell: it was at various points advertised as for games and other 'high performance' stuff, but the more probable commercial reason for it is to leverage companies on to a non-Microsoft platform through an easy migration path. So I think the hypothetical VB4 compiler comparison (or a million similar "business app migration" examples) is pretty fair.
[edit: per subsequent comment, the notion that GC somehow can't be implemented is nonsensical]
"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?
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.
Q. Can asm.js serve as a VM for managed languages, like the JVM or CLR? A. Right now, asm.js has no direct access to garbage-collected data; an asm.js program can only interact indirectly with external data via numeric handles. In future versions we intend to introduce garbage collection and structured data based on the ES6 structured binary data API, which will make asm.js an even better target for managed languages.
Problem is, it's way too large and way too slow. People aren't doing these things because they simply aren't feasible.
If you could compile Python directly into that asm.js subset of JavaScript, things would be okay. However, emulating a whole CPU and running some Python interpreter on top of that won't be okay. Even if you would magically reach 100% of the regular speed, it just would be way too fat.
After executing 5 million statements, IE will ask you if you want to continue. It will ask you many times. You'll probably sit there all day long clicking the whatever button.
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.
This stuff is only ES3 compatible because it didn't need anything from ES5. A low-level compiler target doesn't need any of these things: http://kangax.github.com/es5-compat-table/
Who said Chrome gets a 6x perf hit?
You just have the numbers with asm.js.
If Chrome hasn't been optimized for asm.js style code, then those numbers would either be what Chrome already achieves with JS (e.g plain old V8 speed), or slightly faster than regular JS (because of the more streamlined, easy to JIT nicely asm code).
Now imagine the browser vendors finally figure out how to make languages like Javascript fast, only there is the small problem of 100 zettabytes of blobs on the web, written by companies that no longer exist, and that can't be optimized at all because it's all distributed in a form that resists any inspection.
We don't even use stacks any more – they were some daft hold-over of the 60s that lasted far too long into the 2040s. Only all those zettabytes of blobs were compiled with optimizations that target stack-based VMs.
That's the promise of Native Client.
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.
Have you tried? (genuinely curious)
I suspect taking advantage of this would greatly help in a game situation.
I don't get the fixation with the fact that the filename ends in a .js extension; just because a bunch of code is in a familiar interpreted language doesn't make it readable or maintainable in any other manner.
Web apps written in 1997 do not take advantage of modern browser features.
Browsers written in 1997 can not render modern web pages.
At least with NaCL, you have the option of taking maximum advantage of the available hardware. I'd love to see NaCL grow into having actual on-chip support for NaCL-style sandboxing, the way we've seen CPU vendors add support for virtualization-specific extensions.
At the end of the day, I don't see this as a death blow for NaCL. Rather, it pushes us farther into a post-JS/HTML/CSS platform. We'll start seeing new languages take off, and the underlying platform target itself (browser, native, or otherwise) will matter less and less.
asm.js can be just another compilation target, along-side NaCL and iOS. Once you go in that direction, the HTML/JS/CSS monstrosity start to become less relevant outside of hypertext documents.
An asm.js-supporting runtime which sees this hint can run that code through a different compiler that takes maximum advantage of the available hardware (i.e. whatever it's running on, with the asm.js code doesn't need to know or care about). A runtime that doesn't support asm.js will just run the code like it did before.
My point is that asm.js is every bit as capable of fully optimizing for the host as NaCl. It has two big advantages over NaCl, though. One is that it's architecture-independent: the host knows what architecture it uses, and (assuming it has the compiler, which an asm.js-supporting runtime has by definition) can act accordingly, taking full advantage of its own features. The other advantage is that there's a fallback even in case the runtime doesn't support asm.js: it's no faster than ordinary JavaScript in this case, but at least it does no harm.
A bit off topic, but this already exists, in the sense that there is no difference between NaCl-style sandboxing and what every OS kernel already provides for its processes, except that NaCl is generally locked down tighter. All that would need to happen is for OSes to provide support for containers with arbitrarily restricted syscalls (as Linux already does) and NaCl could give up on the software fault isolation without any real loss in security.
According to Brendan Eich: "all of JS (ES3) is 'universally supported' [by asmjs]"
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.
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.
That's all that asm.js really is: a set of JavaScript coding conventions that (when followed) prove to be easy to optimize to near-native levels of speed, along with a compiler hint to tell the runtime that these conventions are being used. IE6 doesn't understand the compiler hint, but because the asm.js code is still valid JavaScript, it'll still run.
I suspect that either nnethercote and I are using different definitions of backward-compatibility, or nnethercote is mistaken as to what exactly asm.js is. Authorities are less likely to make mistakes, but they can still make them.
None of IE 6, 7, 8 and 9 support them: http://caniuse.com/typedarrays. Ergo, asm.js won't work on IE 6, 7, 8 or 9.
(Speaking of authorities: I got this info from azakai, who's the author of Emscripten and one of the designers of asm.js.)