8 ms·

Actual numbers from the Groups link at the bottom: So I discovered from Alan today - asm.js was everything I hoped it would be. One of the more i

• masklinn 14y ago
  > Backwards compatibility even with IE6 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.
  • hosay123 14y ago
    Perhaps for your OpenGL games, but for some business application originally written for VB4 that basically draws a bunch of forms and puts stuff in a database, that's more than fast enough for some compiler that took VB4 and turned it into JS. 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]
    • ahoge 14y ago
      VB uses garbage collection. You can't compile it to the JS subset of asm.js.
      • whatshisface 14y ago
        That's like saying you can't implement python in x86... if it can run code, it can run code.
        • ahoge 14y ago
          You were able to do the same without asm.js. 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.
    • ahoge 14y ago
      >the notion that GC somehow can't be implemented is nonsensical http://asmjs.org/faq.html 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?
    • stormbrew 14y ago
      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.
      • EwanToo 14y ago
        From the asm FAQ, it seems like GC will happen: 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.
        • stormbrew 14y ago
          I took that to be actually talking about the other way around -- accessing JS GC'd objects from the asm.js code's heap and having it work correctly (which is currently onerous). I don't think that helps implement GC of the asm.js heap.
      • deleted 14y ago
        [deleted]
  • ahoge 14y ago
    V8 is about 100 times (seriously) faster than IE6's JS engine. So, yes, "backward compatible with IE6" doesn't really mean anything. 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.
    • hosay123 14y ago
      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.
    • Millennium 14y ago
      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.
      • ahoge 14y ago
        "Run". Yes, just ~600 times slower. At that speed it probably won't be very useful. You have ~50 msec for an operation which is perceived as instantaneous. If it takes 30 seconds (600 times as long), people will not use it. It simply isn't feasible. 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/ http://kangax.github.com/es5-compat-table/
  • coldtea 14y ago
    >if Chrome gets a 6x perf hit 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).
    • masklinn 14y ago
      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.
• hderms 14y ago
  Can you go into more detail about why you are glad there isn't a blob + VM approach? I know the long history of Java vulnerabilities, etc... but I'd be curious to hear what someone knowledgeable about the subject would say.
  • hosay123 14y ago
    It's easy to show. Imagine Gmail was written for and compiled with an IE3 or IE4 era Javascript parser/interpreter/compiler, and the result was distributed as a blob to run natively. Shortly thereafter Google goes out of business. 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.
    • cromwellian 14y ago
      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.
      • niggler 14y ago
        "WebWorkers/Isolates are a poor substitute for high performance games." Have you tried? (genuinely curious)
        • fzzzy 14y ago
          WebWorkers have also been recently enhanced so that it is possible to pass a message with no copy (by moving it out of the current WebWorker; it loses it's reference to the data). I suspect taking advantage of this would greatly help in a game situation.
• lucian1900 14y ago
  But it's terrible! Bytecode + VM would be so much better ...
• pifflesnort 14y ago
  I'm not sure why you think asm.js isn't a blob: 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. 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.
  • hosay123 14y ago
    But it's not, by your logic a compiler producing machine-generated K&R C in the late 70s would also be a blob. 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)
    • pifflesnort 14y ago
• nzonbi 14y ago
  Taking a comment from someone on this thread, named xal: 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.
  • ux-app 14y ago
    "Now I wish that the same thing done here to javascript, were also done to html, CSS, the dom, etc." 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.
• nnethercote 14y ago
  It relies on typed arrays, so unfortunately it's not backwards compatible with IE6 :(
  • ux-app 14y ago
    If I'm understanding things correctly, the JS produced is a subset of ES3. The use of typed arrays simply give supporting platforms an additional speed boost. According to Brendan Eich: "all of JS (ES3) is 'universally supported' [by asmjs]"
    • surrealize 14y ago
      I'm reading Eich's tweet differently. Here's the twitter exchange: https://twitter.com/BrendanEich/status/302897797827530752 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/ 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.
  • Millennium 14y ago
    Typed arrays are a background thing in this case. The code one writes in asm.js (or compiles to asm.js) doesn't mention them at all. IE6 will see the code and use normal arrays, because as far as it knows, that's the only kind of array there is.
    • hosay123 14y ago
      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.