17 ms·

Why Asm.js Bothers Me

274 points by espadrine 14y ago

hosay123 14y ago
He makes a solid point regarding polyfills for asm.js: if the specification is so rigorously defined, then the only fallback a current-generation browser has on offer when encountering a "v2 asm.js" is to treat it like regular Javascript. That's a pretty nasty regression, and hopefully one that will be addressed. Regardless I still prefer building on Javascript than any proposed alternative. No matter what happens next, any pristine standard is going to look like an overextended mess even in just a few years time. So why not pick the overextended mess we started with.
- niggler 14y ago
  "So why not pick the overextended mess we started with." What's the starting point? Javascript or assembly? NaCl gets closer to the original starting point (which predates javascript by more than 20 years)
  - hosay123 14y ago
    In the context of manipulating symbols on an infinitely long piece of tape, sure, but in the context of the web we don't "have" NaCl and there's sufficiently plausible technical and political resistance that we're probably never going to. At various points he talks about how a fresh byte code would address some of the issues raised, and certainly from a full time compiler engineer's perspective, some pristine representation and a handful of tree-walks are obviously going to appeal to his academic side. I just doubt any such perfectly forward-compatible ideal representation will ever exist that can cater to all camps and survive the test of time, because to my knowledge such a thing has never existed. So why abandon our current path for something that'll inevitably end up as ugly as JS in the long term, when we already have something as ugly as JS.
    - pifflesnort 14y ago
      > ... there's sufficiently plausible technical and political resistance that we're probably never going to. Resistance that you contribute to with almost every article that touches on NaCL, yes. It's self-fulfilling prophesy and a circular argument: "We can't adopt NaCL because nobody will ever adopt NaCL" -- say the people responsible for choosing whether to adopt NaCL. > So why abandon our current path for something that'll inevitably end up as ugly as JS in the long term, when we already have something as ugly as JS. Why is this the "inevitable" result?
      - hosay123 14y ago
        Show me a counterexample, that's all I ask. I'd give all the rhetoric in the world for a single damned counterexample of a program format that's lasted since the 80s. That's what's at stake. Instead we have a company that throws specs over the wall like they're teenaged nerds that have just discovered Pascal's pack function, a company that pushed SPDY on everyone despite it relying on a draft SSL feature that got rejected at the IETF (and in the space of 2/3 years we now have three HTTP variants - and why? Because 3 years ago it shaved 1ms off a maps.google.com request). Did you even take a look at the original WebSocket spec? It worked in terms of comparing the entire start of the HTTP request using memcmp()! Regardless of my opinion of NaCl, this is stuff that should be getting defined slowly and in the open by bearded old men that have spent their lives in glacial, trusted industries like telecoms, or just about any other mature technology industry. Not a throng of Java graduates who think they're changing the world by continually dumping crap specs over the wall and paying for subsidized articles to promote them.
        niggler 14y ago
        "a throng of Java graduates who think they're changing the world by continually dumping crap specs over the wall and paying for subsidized articles to promote them." Based on the media hype surrounding asm.js, it really sounds like mozilla fits the description
        14y ago
  - bcoates 14y ago
    By my count Javascript is around 5 years older than amd64. If we had gone with native client back then we'd be stuck with pre-SSE x86 or maybe they'd have been forward-looking and gone with Alpha or Itanium with emulation for "legacy" systems. Also, why the false choice between asm.js and NaCl anyway? The article makes a pretty compelling case for "neither".
    - pifflesnort 14y ago
      > By my count Javascript is around 5 years older than amd64. If we had gone with native client back then we'd be stuck with pre-SSE x86 or maybe they'd have been forward-looking and gone with Alpha or Itanium with emulation for "legacy" systems. That's not really how NaCL works. Any instruction that can't break out of the jail can be whitelisted; this includes all versions of SSE. Additionally, PNaCL can be retargeted at as-of-yet unknown architectures. The result is that binaries would have been either shipped as PNaCL-only, or optimized for i386+SSE1 with fallback to PNaCL. As new hardware was shipped, new binaries could be targeted appropriately. This seems reasonable to me; default to portability, provide an option for best-case performance.
      - pcwalton 14y ago
        How do you plan to ensure that authors test and ship working and performant PNaCl binaries if they and their users are always using the native code?
        pifflesnort 14y ago
        How did Apple developers ship working PPC/m68k binaries? Or PPC/x86 after that, later PPC/x86/x86-64, and armv6/armv7/armv7s on the iPhone?
        pcwalton 14y ago
        Totally different. In all of those cases, the developers have access to devices that run the hardware, and they have economic incentive to target all of those devices. Whereas with your suggestion, developers ship and test native builds for all of the CPUs on the market, plus one extra "portable" version for posterity, one that no immediate customers will ever use (because they'll be using the native versions for their architecture instead). I suspect developers wouldn't even ship the portable version (too much of a pain), browsers won't optimize it (because nobody will use it), and developers won't test it (because nobody will use it). It's like saying that images are no problem for accessibility on the Web, because designers know to use alt text. Of course they know they should, but we all know what the reality is. A backup "portable" version of an app is like alt text in this way. Some developers would do the right thing; many won't, and the Web will be de facto locked in to x86 and ARM forever.
- constexpr 14y ago
  Ouch, that's a great point about versioning. The thing that appeals to me about asm.js is that it short-cuts the long, slow path of VM optimization and gives great performance now instead of five years down the road. Sure it's an ugly hack but that doesn't matter to your users, all they see is a much faster user experience. Now all we need is a SIMD API for JS and we can write some truly amazing apps.
  - niggler 14y ago
    "it short-cuts the long, slow path of VM optimization and gives great performance now instead of five years down the road." Something tells me that, based purely on usage metrics, chrome matters more than firefox: http://stats.wikimedia.org/archive/squid_reports/2013-02/SquidReportClients.htm http://stats.wikimedia.org/archive/squid_reports/2013-02/Squ... (and pretty much every other metric according to https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Historical_usage_share https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Hi... )
    - Elv13 14y ago
      Thats starcounter numbers. Do you really think IE is bellow 30%? Chrome numbers are inflated.
- dherman 14y ago
  We've talked about versioning, and I think feature detection is probably the best approach. If the user agent publishes a list of supported asm.js features via a standard query mechanism (note that this is a feature list, not browser detection) -- e.g., ASM.SIMD === true -- then apps can negotiate content accordingly. This might entail compiling multiple versions of your codebase for various versions of asm.js, but that's an acceptable price to pay for VM evolution, IMO.
astrodust 14y ago
Compiling JavaScript down to asm.js format JavaScript might be messy, but it might lead to better performance if your compiler is better than the JIT engine. I'm still not sure why a compact, concise, standardized bytecode format isn't being pursued. Perhaps minified, gzipped asm.js encoded JavaScript is as close as we'll ever get.
- cleverjake 14y ago
  I think that short concise bytecode is why we have high level languages like javascript to begin with.
  - astrodust 14y ago
    By "bytecode" we probably mean "ActionScript" which is a train-wreck of an implementation due to differing bytecode formats internally for various versions of Flash. Maybe this is why people are terrified of the idea.
    - cleverjake 14y ago
      No, by bytecode, I mean bytecode. http://en.wikipedia.org/wiki/Bytecode http://en.wikipedia.org/wiki/Bytecode
- Drakim 14y ago
  > is as close as we'll ever get. This is the point I think the author and a lot of people are missing. It's not always about what is the best possible design, instead it is often "what we will get". Politics, ideology, and timing can often come in the way of "the best design". I would love to use NaCl (I was cheering for it up until recently), but if only Chrome is implementing it then it's about as useful as a screwdriver that doesn't fit any screws. asm.js is already a stronger candidate because I can use it right now and it will work everywhere. Obviously the browser vendors has to create asm.js specific optimizations for it to be truly great, but that is like fuzzing over the handle, grip and material of the screwdriver. It fits the screws, it gets the job done, it actually works. What does it matter how great your technology is if it doesn't work? What does it matter if NaCl is ten times faster if I can't actually use it? From what I see, Mozilla isn't very hot on the idea of adopting NaCl, and Microsoft will probably not even touch it in this millennia. If a client wants me to produce something, I can't use NaCl, because it won't actually run in non-chrome browsers (without installing plugins). To me it appears that the choice is either asm.js or nothing. NaCl just isn't happening.
asb 14y ago
"Why asm.js is a JavaScript subset?". Simple, because Mozilla wants the benefits of the (P)NaCl approach but don't want to have to import LLVM. asm.js allows them to 1) make use of their existing JIT compiler and 2) avoid defining a new bytecode format (the benefits of this are questionable). asm.js is ugly, but it doesn't seem that much more ugly than adding a new multi-megabyte dependency to every browser. I suppose an interesting question would be how hard would it have been to standardise on the PNaCl bytecode format and use that as the input to ${FOO}monkey
- drivebyacct2 14y ago
  I've heard plenty of reasons Mozilla doesn't like NaCl, but that sure isn't one of them...
  - asb 14y ago
    I'm just speculating wildly like most other people here are, but you really think it wasn't a positive for them that they could reuse the JIT they've invested in and have expertise in rather than relying on LLVM.
    - drivebyacct2 14y ago
      I don't want to speak to that. I was more referring to the notion that they didn't consider it because LLVM is a large dependency. As others have noted, emscripten uses LLVM, and it's likely that LLVM will be leverage to coerce other code in asm.js style javascript. Mozilla's reasons for not wanting NaCl have been spelled out lots of places.
  - josteink 14y ago
    I think the main reason for anyone not to support it, would be that it makes the WWW platform specific. I can't wait for my first "Sorry. This webpage does not support ARMv7 Hard-float". Another reason Mozilla might not support this is that it's actually not called Na(tive) Cl(ient). It's full name is "Google Native Client". That sure as hell doesn't sound like a standardized and fully spec'd thing I'd implement in my browser if my name was anything besides Google.
drivebyacct2 14y ago
Isn't he describing Dart in his second to last section?
- mraleph 14y ago
  I am not sure what do you mean. Dart is a dynamically typed language, not a bytecode. Dart's type annotations don't even have any implications on performance and not used for optimizations by either Dart VM or dart2js.
  - kyrra 14y ago
    Though, you can run the DartVM in "checked" mode which will validate all type assignments to make sure they match the types annotated in your code.
ajanuary 14y ago
This seems to assume asm.js came first. Really it's a development build on top of what things like emacripten were already doing. There doesn't really seem to be much criticism here of asm.js as a bytecode, only as a syntax.
voidlogic 14y ago
"the first danger that I sense: OdinMonkey is a hammer that will kill incentive to optimize JavaScript that humans write. Why waste time optimizing normal, dynamic, fluid like water JavaScript if you can just ask people that they write something more structured and easier for compiler to recognize? " I'm eagerly awaiting the day I can write single-threaded Go or Java, have it turned into asm.js and never have to write another line of yucky Javascript again. I like this proposed alternate future.
- chrisbu 14y ago
  Have you looked at Dart? It's not that far from Java.
  - bradleyjg 14y ago
    Not really. It's a dynamically typed language that tries to fool the casual user into thinking it's statically typed.
    - kyrra 14y ago
      But it has more normal types. I'm betting if asm.js takes off, dart2js could easily output code that uses it. Sure you can write fully untyped Dart code, but their js compiler already does a lot of type inference.
- Millennium 14y ago
  If something like asm.js could possibly kill the incentive to optimize handwritten code, we'd still be writing everything in assembly. Asm.js is aptly named, because it's targeted at small, tightly-looped, extremely performance-critical operations over large amounts of homogeneous data. That's one of the few things people still use assembly language for on the desktop. That's all asm.js really is: a compiler hint that you've gotten desperate for cycles, so here are some coding conventions that will make things easier to optimize.
  - deleted 14y ago
    [deleted]
snird 14y ago
If it is not JavaScript, and it gains it's performance by static typing - well, we already have a language like that, and it's more production ready than asm.js - it's Dart.
- mraleph 14y ago
  Dart is not statically typed.
  - deleted 14y ago
    [deleted]
- chrisbu 14y ago
  In an addition to the parent comment, Dart uses its type system to increase performance, even when generating JavaScript: http://www.youtube.com/watch?v=rbLkYlbEZ1E http://www.youtube.com/watch?v=rbLkYlbEZ1E
dvt 14y ago
What bothers me about asm.js is that no one really needs it. I mean don't get me wrong, Unreal III in Firefox is pretty cool, but very very few developers will seriously consider writing a production game for the browser. So then what are we left with? FFT implementations? OCR? Real-time fluid mechanics? Who does these things in a browser? What JS needs is to finally standardize WebSockets (across the board), to seriously consider multi-threading (not this WebWorker nonsense), to implement optional type checking (like Dart), etc, etc. The effort that's going into asm.js should go into building better JIT compilers. We seem to be forgetting that JavaScript is a web programming scripting language, not some general-purpose low-level esoteric programming language. There are so many improvements JS could make on the web-side of things (you know, where it's actually used) instead of on the "cool 3D Unreal III game-programming, bytecode-crunching, Jacobi-simulating"-side of things.
- deleted 14y ago
  [deleted]
- tree_of_item 14y ago
  The goal of things like asm.js is to make JavaScript a general purpose, low level programming language. I'm not sure why you consider it esoteric, though. People don't do those things in the browser because asm.js (or some alternative) isn't widespread yet. When it is, they will.
  - dvt 14y ago
    Exactly. JS was never meant to be a general-purpose language. Using the right tool for the right job is a fundamental aspect of software engineering. If you use C for writing web-apps and JavaScript for writing operating systems, you're doing something very, very wrong. The irony here is that JavaScript isn't even a very good language, anyway. So when lambdas are implemented in a language like C++11 (to the chagrin of many programmers that shun the unnecessary complexities of recent revisions of C++), that's one thing; but when we're trying to use JS for low-level programming, that seems very silly. And as far as your second point is concerned, I beg to differ. Java has been able to run OpenGL in the browser for ages. Flash can also do hardware-acceleration. As can Unity3D. 99% of computers have either Flash or Java installed, and yet, no serious developer (barring maybe a couple of indies) would seriously consider Java/Flash as a serious platform. I don't think HTML5/asm.js will change that.
jdonaldson 14y ago
I would imagine that people would rarely write asm.js code, but instead they would generate it from statically typed languages (TypeScript, Dart, Haxe). I admit asm is a bit ugly to look at. But, it's backwards compatible, and provides a way forward for getting some performance out of js in very specific cases. It's not going to be an all purpose code path for general use, and I don't think it's going to take attention away from other general js improvements. The only thing I'm skeptical about here is whether or not Google chooses to integrate asm with Chrome (Setting aside what Apple or Microsoft ends up doing). It runs counter to the work Google has done with Dart. For that reason alone, I think there's a significant risk it won't gain traction. I think the creation of "fast" web performance is seen as a huge carrot from the big tech companies (MS, Adobe, Google, Mozilla). Each is trying to offer it in different ways, and at the same time pulling developers into their specific dev tooling ecosystem. It's a difficult time to pick languages/tooling. I like Haxe because I know it'll support the platform of whomever wins (asm.js, dartvm, es6, etc.)
- NinjaWarrior 14y ago
  > I would imagine that people would rarely write asm.js code, but instead they would generate it from statically typed languages (TypeScript, Dart, Haxe). Current asm.js is just for C/C++. Those altJS languages can't make use of asm.js (Haxe->C++->LLVM->Emscripten->asm.js might be possible but I think it's meaningless). asm.js is the answer of Mozilla for "the web standards can't handle AAA games" but I believe this is far from an ideal solution. And I agree with the worry of the poster that this ugly hack makes JavaScript more ugly, both on the specs and VMs. To be honest, I trembled when I saw the Math.imul proposion to see how some people are so obsessed with JavaScript...
  - smosher 14y ago
    Current asm.js is just for C/C++. I think that's a dangerous way of putting it. Asm.js is just a spec and can (and ought to) be emitted by things other than Emscripten.
  - azakai 14y ago
    > Current asm.js is just for C/C++ There is already asm.js support for lljs, some thoughts on support in things like JSIL (C#) and Haxe (as you mentioned). And in principle anything that compiles to LLVM IR or C/C++ would work through emscripten.
apendleton 14y ago
Without having actually done much to investigate the feasibility of this, it seems to me like someone could write a compiler infrastructure that would generate both asm.js and (P)NaCL output from the same lower-level non-JS code, since you can get to both from LLVM bytecode. Combined with a JS client library to paper over the differences between the two, developers could just write one set of low-level code and not care which fast-path execution strategy the browser implemented, and the asm.js version, along with whatever polyfill hacks were necessary to make it work, could be served to old browsers to run the same code slowly. This is, I guess, not that different from the OP's suggestion to create a bytecode and define a one-pass transformation of that into JS.
haberman 14y ago
> OdinMonkey is a hammer that will kill incentive to optimize JavaScript that humans write. Eh, I'm not worried about this. Many apps will have no reason to migrate to asm.js, and for as long as some big and important apps are written in JavaScript, there will be incentive to optimize plain JavaScript. JavaScript and other dynamically-typed languages exist because in many cases they are the best and most convenient way to write apps. But suppose this weren't true; suppose that in the long-term developers started favoring statically-typed languages for web apps, either because of performance or because of usability (Eclipse-like IDE convenience; hard to provide in a dynamic language). Is the author saying that we should artificially prop up usage of dynamic languages by taking away some of the inherent performance benefits of static languages? That doesn't sound like the best way to achieve technical excellence in the long term. In the marketplace of ideas and technologies, let things succeed or fail based on their demonstrated merit, rather than trying to pick winners and losers based on our preconceptions. > Somebody might say that [my proposed bytecode] does not run everywhere. Nope. It does run everywhere: just take JavaScript and write a simple one pass translator from this bytecode to JavaScript. You can think of asm.js as just that; a one-pass translator of an implicitly-defined bytecode to JavaScript. If you want to view/edit it as a more traditional-looking byte-code, you can easily implement a YourBytecode<->asm.js compiler. It just so happens that asm.js is a backward-compatible representation, so works more conveniently as the standardized wire encoding. (I have not studied the asm.js spec in detail, but I've seen pcwalton describe it as an alternate encoding of LLVM bitcode, so I suspect that the idea of implementing a YourBytecode<->asm.js compiler is actually reasonable given the asm.js definition).
- niggler 14y ago
  " If you want to view/edit it as a more traditional-looking byte-code, you can easily implement a YourBytecode<->asm.js compiler." There are quite a few hurdles, and some of them will be resolved with some stuff Mozilla has proposed in ES6. But as it stands now, you can't use CLR IL bytecode or even JVM bytecode.
  - glhaynes 14y ago
    You couldn't (reasonably) compile the CLR or the JVM to asm.js? I'd assume you could, which would seem to point toward a translation of bytecodes (since that's what the asm.js-hosted CLR/JVM would be doing) being feasible…
aeflash 14y ago
> It can’t allocate normal JavaScript objects or access normal JavaScript properties. No strings. Only arithmetic and typed arrays (a single one actually with multiple views). I think he is missing a core concept here. You can create and modify strings, just at a lower level. An array of ints can be used as a char array, which in turn can be used as a string. You just have to interface with it at a lower level, probably implementing your own C-style strlen/strtok functions. It will be more complicated, especially if you need to accommodate unicode, but it is doable. Granted, there is no advantage to abandoning the built-in string manipulation functions except speed, but you would only use asm.js when speed absolutely matters. At a more fundamental level, when you have access to memory through a stack and/or heap, and can create arrays of ints with which you can do normal arithmetic and load/store operations, you really can do anything. After all, that is the entirety of what actual assembler code has to work with. You just have to make your own abstractions.
- mraleph 14y ago
  When I say "no strings" I mean JavaScript built-in primitive string values. I will amend the paragraph to make it explicit. It was added because I talked to people who think that just adding "use asm" on top of their node.js module will make it go as fast as C++ without realizing that asm.js is a very limited subset with its own rules. You can surely represent a JS string as a Uint16Array or Uint8Array, but copying things in and out of emulated heap into real heap will cause penalty. You will also have to reimplement a lot of functionality that host JS engine provides. Trying to implement say a regexp engine in asm.js that would be as performant as V8's built-in on would be a challenge. Yes, you can do anything. I don't dispute that. But you have to do it manually and sometimes you are replicating functionality that already exists in the host engine e.g. you might implement GC, but it will less efficient than builtin one.
foursquared 14y ago
"Please keep in mind that I used to work on V8" In theory a V8 could optimize regular JS as fast as asm.js, but in practice OdinMonkey made this code 3x to 10x faster (or more) with a couple months of effort. And to boot it is completely compatible with every JS engine, and the code generated can be cached offline for fast startup (because of the linking part), and the FFI between JS and asm.JS is trivial. Basically this post is sour grapes. Mozilla came up with a better idea than the so-called geniuses at Google did.
- zem 14y ago
  That's a weird thing to say. Is the perception really that mozilla doesn't have its share of geniuses?
mappu 14y ago
In related news, researchers from Mozilla and UC San Diego with support from Microsoft Research have recently published another approach to typed JavaScript, named Dependent Javascript or "DJS". This isn't focused on performance so much as correctness. 1. http://lambda-the-ultimate.org/node/4700 http://lambda-the-ultimate.org/node/4700 2. http://goto.ucsd.edu/~ravi/research/djs/ http://goto.ucsd.edu/~ravi/research/djs/
acqq 14y ago
The author complains about having to write x = 0 in asm.js blocks where it simply means "here I declare x to be a number and not undefined". He worries that "if you remove a single + or | the code above will be rejected by the validator." But it is good: if your goal is to have a really fast code, and declared the section as such, you don't want any construct that will make it significantly slower. Finally, author believes that the "JavaScript" code can be made "as fast" even without annotating it like in asm.js. He writes "I don't believe that anything like asm.js is needed to generate highly efficient native code" but of course he shows nowhere how something like that cab be achieved. Because it can't. Unless you somehow specify your assumptions in most of the cases you have to have the run-time checks. Which are slow. Observe just for example: c = a + b; If you haven't written before a = 0 and b = 0 you have to assume that a and be can be strings etc. You can have some code to take the int route but you have to have runtime checks. Now if you even wrote a = 0 and b = 0 and you're doing the loop in which you have a + b, you can't assume that the result will fit 32 bits. Which you don't need, unless you really want to do 32-bit arithmetic -- there are algorithms where you get the performance advantage by using it. The asm.js annotations are a really clever way to tell to the JIT what you (the programmer) expect. The sections allow you to get the nice clean pieces of clean native code, free of a lot of run-time checks. Speed and much more efficient memory use. Pure goodness.
- Millennium 14y ago
  Correct me if I'm wrong, but wouldn't the hypothetical techniques needed to enable something like "asm.js without the compiler hint" also come rather close to solving the halting problem?
  - jkrems 14y ago
    The techniques need to enable something like "asm.js without the compiler hint" exist and are in use today in JIT compilation (at least to some degree). Since the source code does not generally change and the generated instructions may, you can make assumptions first and later on rewrite the instructions if your assumptions don't hold. At least that's how I understand it. If you would do AOT compilation and ship the instructions, then you may be right about the halting problem.
coldtea 14y ago
OK, let's say that with stuff like ams.js we never get true native performance than say NaCL would give. Isn't that also a good thing? I wouldn't want the web as a platform to be that good that it kills all native desktop applications, essentially turning every computer into something like a Chrome Book. Isn't that a real danger with stuff like NaCL?
- GnarlinBrando 14y ago
  > I wouldn't want the web as a platform to be that good What? Are you so ideologically caught up that you actually wish something wont get good? It is totally reasonable to to think something isn't the right approach or a waste of time, or to not like the workflow, etc. But to actually wish that something wont get good enough to be a general solution even if it can? How does that make any sense?
  - coldtea 14y ago
    >But to actually wish that something wont get good enough to be a general solution even if it can? How does that make any sense? It makes a lot of sense because things do not happen in isolation. A "good enough web platform" could bring a lot of OTHER outcomes too. I wrote one in my comment already: all computers because Chromebooks, glorified clients. That has other consequences: you loose control, you don't own your apps (the company does, and it can take them from you in an instant, like Google Reader), etc. Not to mention the privacy implication of ALL apps running in a web browser, getting their data remotely. Or the implications for companies and governments locking content, pushing you out, demanding a premium, etc.
    - fzzzy 14y ago
      I don't see that those consequences follow, at all. I see a natural evolution from where we are now to a world where people own their own servers in the cloud and run all the software on them. Or, if you really don't want any data to go over the wire, just run all the web app servers locally. There was a big swing from the idea that at&t would sell you a terminal that was connected to a central mainframe, to personal computers that were distributed, back to everything being centralized because the advantages of the web were compelling and centralizing things was the natural path. Things will swing back again to decentralization, but the difference this time is you will be able to access all of your data from anywhere at any time.
dgreensp 14y ago
There's a valid philosophical objection here, and I found the article illuminating about the nature of Asm.js. The strategy of making a static subset of a language that's easy to compile works great -- if it's targeted at humans! RPython, for example, means you can write the Python VM in Python, and the SmallTalk VM (or Squeak?) was written in SmallTalk using the same approach. The point is part of your code base is in this restricted language instead of C, and you can bootstrap that way. If this language is just a compiler target and not meant to be particularly human-friendly (RPython has classes and mixins) then making it a weird subset of JavaScript is a little more dubious and without precedent that I can think of.
- acqq 14y ago
  It's definitely not "just a compiler target," not more than the assembly language in which people still write some code by hand when there's need for that. The real world example: https://github.com/srijs/rusha https://github.com/srijs/rusha (see the benchmarks -- Firefox 21 uses asm.js) and the source https://github.com/srijs/rusha/blob/master/rusha.js https://github.com/srijs/rusha/blob/master/rusha.js I don't see that the code got ugly. The calculations needed are the same, the most obvious differences from the "non-asm.js" code is the "asm.js" and a few |0 marks. And some of such |0 constructs can improve speed even on the browsers which don't do full "asm.js". So the engines will get smarter by recognizing such constructs even without the full support of "asm.js" segments. It's a win-win already.
  - munificent 14y ago
    Right, but your example here is a particularly skewed one. It's a hashing library. All it does is take integers and do arithmetic on them. Most real-world application code is not at all like that. Asm.js doesn't even support strings as far as I know.
    - acqq 14y ago
      Asm.js is exactly made for things like that: the pieces of code that don't depend on "strings" but calculate a lot. And for things like this: http://bellard.org/jslinux/ http://bellard.org/jslinux/ For "strings" the existing JITers do already the good job. You can just use JavaScript as is then.
askimto 14y ago
Looks like the asm.js Jedi mind trick didn't work on someone :)
guilloche 14y ago
Yeah, I have the same bad feeling on asm.js. If we need c/c++=>llvm=>javascript/asm.js for performance reasons, then why not just embed llvm inside web brosers? Isn't it much easier, and much cleaner?
nivertech 14y ago
I find asm.js pointless. If all you need a fast numeric calculations in JavaScript, the better compiler backend would be WebCL - OpenCL binding to JavaScript.
- michaelwww 14y ago
  Could you expand on this? It seems like an apples and oranges comparison.
  - nivertech 14y ago
    Asm.js only allows numeric operations on emulated heap buffer. You can do much better with OpenCL on CPU device. Asm.js intended to be used as a backend for compilers. One of OpenCL use cases is the same. Asm.js code pretends to be a JavaScript code, OpenCL does not, but there is WebCL - a JavaScript binding standard for OpenCL.
    - michaelwww 14y ago
      Asm.js is still JavaScript. You can do all kinds of things that JavaScript can't do by itself if you call native code with a plug in. That's the difference. No plugin. No installation.
      - nivertech 14y ago
        What's the difference between Mozilla deciding to bundle Asm.js with Firefox vs. Google deciding to bundle WebCL and WebGL with Chrome?
        michaelwww 14y ago
        I refer you to http://asmjs.org/faq.html http://asmjs.org/faq.html to understand the difference. Particularly the Question: "Why not NaCl or PNaCl instead? Are you just being stubborn about JavaScript?"

274 points by espadrine 14y ago

He makes a solid point regarding polyfills for asm.js: if the specification is so rigorously defined, then the only fallback a current-generation browser has on offer when encountering a "v2 asm.js" is to treat it like regular Javascript. That's a pretty nasty regression, and hopefully one that will be addressed. Regardless I still prefer building on Javascript than any proposed alternative. No matter what happens next, any pristine standard is going to look like an overextended mess even in just a few years time. So why not pick the overextended mess we started with.

niggler 14y ago
"So why not pick the overextended mess we started with." What's the starting point? Javascript or assembly? NaCl gets closer to the original starting point (which predates javascript by more than 20 years)
- hosay123 14y ago
  In the context of manipulating symbols on an infinitely long piece of tape, sure, but in the context of the web we don't "have" NaCl and there's sufficiently plausible technical and political resistance that we're probably never going to. At various points he talks about how a fresh byte code would address some of the issues raised, and certainly from a full time compiler engineer's perspective, some pristine representation and a handful of tree-walks are obviously going to appeal to his academic side. I just doubt any such perfectly forward-compatible ideal representation will ever exist that can cater to all camps and survive the test of time, because to my knowledge such a thing has never existed. So why abandon our current path for something that'll inevitably end up as ugly as JS in the long term, when we already have something as ugly as JS.
  - pifflesnort 14y ago
    > ... there's sufficiently plausible technical and political resistance that we're probably never going to. Resistance that you contribute to with almost every article that touches on NaCL, yes. It's self-fulfilling prophesy and a circular argument: "We can't adopt NaCL because nobody will ever adopt NaCL" -- say the people responsible for choosing whether to adopt NaCL. > So why abandon our current path for something that'll inevitably end up as ugly as JS in the long term, when we already have something as ugly as JS. Why is this the "inevitable" result?
    - hosay123 14y ago
      Show me a counterexample, that's all I ask. I'd give all the rhetoric in the world for a single damned counterexample of a program format that's lasted since the 80s. That's what's at stake. Instead we have a company that throws specs over the wall like they're teenaged nerds that have just discovered Pascal's pack function, a company that pushed SPDY on everyone despite it relying on a draft SSL feature that got rejected at the IETF (and in the space of 2/3 years we now have three HTTP variants - and why? Because 3 years ago it shaved 1ms off a maps.google.com request). Did you even take a look at the original WebSocket spec? It worked in terms of comparing the entire start of the HTTP request using memcmp()! Regardless of my opinion of NaCl, this is stuff that should be getting defined slowly and in the open by bearded old men that have spent their lives in glacial, trusted industries like telecoms, or just about any other mature technology industry. Not a throng of Java graduates who think they're changing the world by continually dumping crap specs over the wall and paying for subsidized articles to promote them.
      - niggler 14y ago
        "a throng of Java graduates who think they're changing the world by continually dumping crap specs over the wall and paying for subsidized articles to promote them." Based on the media hype surrounding asm.js, it really sounds like mozilla fits the description
        14y ago
- bcoates 14y ago
  By my count Javascript is around 5 years older than amd64. If we had gone with native client back then we'd be stuck with pre-SSE x86 or maybe they'd have been forward-looking and gone with Alpha or Itanium with emulation for "legacy" systems. Also, why the false choice between asm.js and NaCl anyway? The article makes a pretty compelling case for "neither".
  - pifflesnort 14y ago
    > By my count Javascript is around 5 years older than amd64. If we had gone with native client back then we'd be stuck with pre-SSE x86 or maybe they'd have been forward-looking and gone with Alpha or Itanium with emulation for "legacy" systems. That's not really how NaCL works. Any instruction that can't break out of the jail can be whitelisted; this includes all versions of SSE. Additionally, PNaCL can be retargeted at as-of-yet unknown architectures. The result is that binaries would have been either shipped as PNaCL-only, or optimized for i386+SSE1 with fallback to PNaCL. As new hardware was shipped, new binaries could be targeted appropriately. This seems reasonable to me; default to portability, provide an option for best-case performance.
    - pcwalton 14y ago
      How do you plan to ensure that authors test and ship working and performant PNaCl binaries if they and their users are always using the native code?
      - pifflesnort 14y ago
        How did Apple developers ship working PPC/m68k binaries? Or PPC/x86 after that, later PPC/x86/x86-64, and armv6/armv7/armv7s on the iPhone?
        pcwalton 14y ago
        Totally different. In all of those cases, the developers have access to devices that run the hardware, and they have economic incentive to target all of those devices. Whereas with your suggestion, developers ship and test native builds for all of the CPUs on the market, plus one extra "portable" version for posterity, one that no immediate customers will ever use (because they'll be using the native versions for their architecture instead). I suspect developers wouldn't even ship the portable version (too much of a pain), browsers won't optimize it (because nobody will use it), and developers won't test it (because nobody will use it). It's like saying that images are no problem for accessibility on the Web, because designers know to use alt text. Of course they know they should, but we all know what the reality is. A backup "portable" version of an app is like alt text in this way. Some developers would do the right thing; many won't, and the Web will be de facto locked in to x86 and ARM forever.
constexpr 14y ago
Ouch, that's a great point about versioning. The thing that appeals to me about asm.js is that it short-cuts the long, slow path of VM optimization and gives great performance now instead of five years down the road. Sure it's an ugly hack but that doesn't matter to your users, all they see is a much faster user experience. Now all we need is a SIMD API for JS and we can write some truly amazing apps.
- niggler 14y ago
  "it short-cuts the long, slow path of VM optimization and gives great performance now instead of five years down the road." Something tells me that, based purely on usage metrics, chrome matters more than firefox: http://stats.wikimedia.org/archive/squid_reports/2013-02/SquidReportClients.htm http://stats.wikimedia.org/archive/squid_reports/2013-02/Squ... (and pretty much every other metric according to https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Historical_usage_share https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Hi... )
  - Elv13 14y ago
    Thats starcounter numbers. Do you really think IE is bellow 30%? Chrome numbers are inflated.
dherman 14y ago
We've talked about versioning, and I think feature detection is probably the best approach. If the user agent publishes a list of supported asm.js features via a standard query mechanism (note that this is a feature list, not browser detection) -- e.g., ASM.SIMD === true -- then apps can negotiate content accordingly. This might entail compiling multiple versions of your codebase for various versions of asm.js, but that's an acceptable price to pay for VM evolution, IMO.

astrodust 14y ago

Compiling JavaScript down to asm.js format JavaScript might be messy, but it might lead to better performance if your compiler is better than the JIT engine. I'm still not sure why a compact, concise, standardized bytecode format isn't being pursued. Perhaps minified, gzipped asm.js encoded JavaScript is as close as we'll ever get.

cleverjake 14y ago
I think that short concise bytecode is why we have high level languages like javascript to begin with.
- astrodust 14y ago
  By "bytecode" we probably mean "ActionScript" which is a train-wreck of an implementation due to differing bytecode formats internally for various versions of Flash. Maybe this is why people are terrified of the idea.
  - cleverjake 14y ago
    No, by bytecode, I mean bytecode. http://en.wikipedia.org/wiki/Bytecode http://en.wikipedia.org/wiki/Bytecode
Drakim 14y ago
> is as close as we'll ever get. This is the point I think the author and a lot of people are missing. It's not always about what is the best possible design, instead it is often "what we will get". Politics, ideology, and timing can often come in the way of "the best design". I would love to use NaCl (I was cheering for it up until recently), but if only Chrome is implementing it then it's about as useful as a screwdriver that doesn't fit any screws. asm.js is already a stronger candidate because I can use it right now and it will work everywhere. Obviously the browser vendors has to create asm.js specific optimizations for it to be truly great, but that is like fuzzing over the handle, grip and material of the screwdriver. It fits the screws, it gets the job done, it actually works. What does it matter how great your technology is if it doesn't work? What does it matter if NaCl is ten times faster if I can't actually use it? From what I see, Mozilla isn't very hot on the idea of adopting NaCl, and Microsoft will probably not even touch it in this millennia. If a client wants me to produce something, I can't use NaCl, because it won't actually run in non-chrome browsers (without installing plugins). To me it appears that the choice is either asm.js or nothing. NaCl just isn't happening.

asb 14y ago

"Why asm.js is a JavaScript subset?". Simple, because Mozilla wants the benefits of the (P)NaCl approach but don't want to have to import LLVM. asm.js allows them to 1) make use of their existing JIT compiler and 2) avoid defining a new bytecode format (the benefits of this are questionable). asm.js is ugly, but it doesn't seem that much more ugly than adding a new multi-megabyte dependency to every browser. I suppose an interesting question would be how hard would it have been to standardise on the PNaCl bytecode format and use that as the input to ${FOO}monkey

drivebyacct2 14y ago
I've heard plenty of reasons Mozilla doesn't like NaCl, but that sure isn't one of them...
- asb 14y ago
  I'm just speculating wildly like most other people here are, but you really think it wasn't a positive for them that they could reuse the JIT they've invested in and have expertise in rather than relying on LLVM.
  - drivebyacct2 14y ago
    I don't want to speak to that. I was more referring to the notion that they didn't consider it because LLVM is a large dependency. As others have noted, emscripten uses LLVM, and it's likely that LLVM will be leverage to coerce other code in asm.js style javascript. Mozilla's reasons for not wanting NaCl have been spelled out lots of places.
- josteink 14y ago
  I think the main reason for anyone not to support it, would be that it makes the WWW platform specific. I can't wait for my first "Sorry. This webpage does not support ARMv7 Hard-float". Another reason Mozilla might not support this is that it's actually not called Na(tive) Cl(ient). It's full name is "Google Native Client". That sure as hell doesn't sound like a standardized and fully spec'd thing I'd implement in my browser if my name was anything besides Google.

drivebyacct2 14y ago

Isn't he describing Dart in his second to last section?

mraleph 14y ago
I am not sure what do you mean. Dart is a dynamically typed language, not a bytecode. Dart's type annotations don't even have any implications on performance and not used for optimizations by either Dart VM or dart2js.
- kyrra 14y ago
  Though, you can run the DartVM in "checked" mode which will validate all type assignments to make sure they match the types annotated in your code.

ajanuary 14y ago

This seems to assume asm.js came first. Really it's a development build on top of what things like emacripten were already doing. There doesn't really seem to be much criticism here of asm.js as a bytecode, only as a syntax.

voidlogic 14y ago

"the first danger that I sense: OdinMonkey is a hammer that will kill incentive to optimize JavaScript that humans write. Why waste time optimizing normal, dynamic, fluid like water JavaScript if you can just ask people that they write something more structured and easier for compiler to recognize? " I'm eagerly awaiting the day I can write single-threaded Go or Java, have it turned into asm.js and never have to write another line of yucky Javascript again. I like this proposed alternate future.

chrisbu 14y ago
Have you looked at Dart? It's not that far from Java.
- bradleyjg 14y ago
  Not really. It's a dynamically typed language that tries to fool the casual user into thinking it's statically typed.
  - kyrra 14y ago
    But it has more normal types. I'm betting if asm.js takes off, dart2js could easily output code that uses it. Sure you can write fully untyped Dart code, but their js compiler already does a lot of type inference.
Millennium 14y ago
If something like asm.js could possibly kill the incentive to optimize handwritten code, we'd still be writing everything in assembly. Asm.js is aptly named, because it's targeted at small, tightly-looped, extremely performance-critical operations over large amounts of homogeneous data. That's one of the few things people still use assembly language for on the desktop. That's all asm.js really is: a compiler hint that you've gotten desperate for cycles, so here are some coding conventions that will make things easier to optimize.
- deleted 14y ago
  [deleted]

snird 14y ago

If it is not JavaScript, and it gains it's performance by static typing - well, we already have a language like that, and it's more production ready than asm.js - it's Dart.

mraleph 14y ago
Dart is not statically typed.
- deleted 14y ago
  [deleted]
chrisbu 14y ago
In an addition to the parent comment, Dart uses its type system to increase performance, even when generating JavaScript: http://www.youtube.com/watch?v=rbLkYlbEZ1E http://www.youtube.com/watch?v=rbLkYlbEZ1E

dvt 14y ago

What bothers me about asm.js is that no one really needs it. I mean don't get me wrong, Unreal III in Firefox is pretty cool, but very very few developers will seriously consider writing a production game for the browser. So then what are we left with? FFT implementations? OCR? Real-time fluid mechanics? Who does these things in a browser? What JS needs is to finally standardize WebSockets (across the board), to seriously consider multi-threading (not this WebWorker nonsense), to implement optional type checking (like Dart), etc, etc. The effort that's going into asm.js should go into building better JIT compilers. We seem to be forgetting that JavaScript is a web programming scripting language, not some general-purpose low-level esoteric programming language. There are so many improvements JS could make on the web-side of things (you know, where it's actually used) instead of on the "cool 3D Unreal III game-programming, bytecode-crunching, Jacobi-simulating"-side of things.

deleted 14y ago
[deleted]
tree_of_item 14y ago
The goal of things like asm.js is to make JavaScript a general purpose, low level programming language. I'm not sure why you consider it esoteric, though. People don't do those things in the browser because asm.js (or some alternative) isn't widespread yet. When it is, they will.
- dvt 14y ago
  Exactly. JS was never meant to be a general-purpose language. Using the right tool for the right job is a fundamental aspect of software engineering. If you use C for writing web-apps and JavaScript for writing operating systems, you're doing something very, very wrong. The irony here is that JavaScript isn't even a very good language, anyway. So when lambdas are implemented in a language like C++11 (to the chagrin of many programmers that shun the unnecessary complexities of recent revisions of C++), that's one thing; but when we're trying to use JS for low-level programming, that seems very silly. And as far as your second point is concerned, I beg to differ. Java has been able to run OpenGL in the browser for ages. Flash can also do hardware-acceleration. As can Unity3D. 99% of computers have either Flash or Java installed, and yet, no serious developer (barring maybe a couple of indies) would seriously consider Java/Flash as a serious platform. I don't think HTML5/asm.js will change that.

jdonaldson 14y ago

I would imagine that people would rarely write asm.js code, but instead they would generate it from statically typed languages (TypeScript, Dart, Haxe). I admit asm is a bit ugly to look at. But, it's backwards compatible, and provides a way forward for getting some performance out of js in very specific cases. It's not going to be an all purpose code path for general use, and I don't think it's going to take attention away from other general js improvements. The only thing I'm skeptical about here is whether or not Google chooses to integrate asm with Chrome (Setting aside what Apple or Microsoft ends up doing). It runs counter to the work Google has done with Dart. For that reason alone, I think there's a significant risk it won't gain traction. I think the creation of "fast" web performance is seen as a huge carrot from the big tech companies (MS, Adobe, Google, Mozilla). Each is trying to offer it in different ways, and at the same time pulling developers into their specific dev tooling ecosystem. It's a difficult time to pick languages/tooling. I like Haxe because I know it'll support the platform of whomever wins (asm.js, dartvm, es6, etc.)

NinjaWarrior 14y ago
> I would imagine that people would rarely write asm.js code, but instead they would generate it from statically typed languages (TypeScript, Dart, Haxe). Current asm.js is just for C/C++. Those altJS languages can't make use of asm.js (Haxe->C++->LLVM->Emscripten->asm.js might be possible but I think it's meaningless). asm.js is the answer of Mozilla for "the web standards can't handle AAA games" but I believe this is far from an ideal solution. And I agree with the worry of the poster that this ugly hack makes JavaScript more ugly, both on the specs and VMs. To be honest, I trembled when I saw the Math.imul proposion to see how some people are so obsessed with JavaScript...
- smosher 14y ago
  Current asm.js is just for C/C++. I think that's a dangerous way of putting it. Asm.js is just a spec and can (and ought to) be emitted by things other than Emscripten.
- azakai 14y ago
  > Current asm.js is just for C/C++ There is already asm.js support for lljs, some thoughts on support in things like JSIL (C#) and Haxe (as you mentioned). And in principle anything that compiles to LLVM IR or C/C++ would work through emscripten.

apendleton 14y ago

Without having actually done much to investigate the feasibility of this, it seems to me like someone could write a compiler infrastructure that would generate both asm.js and (P)NaCL output from the same lower-level non-JS code, since you can get to both from LLVM bytecode. Combined with a JS client library to paper over the differences between the two, developers could just write one set of low-level code and not care which fast-path execution strategy the browser implemented, and the asm.js version, along with whatever polyfill hacks were necessary to make it work, could be served to old browsers to run the same code slowly. This is, I guess, not that different from the OP's suggestion to create a bytecode and define a one-pass transformation of that into JS.

haberman 14y ago

> OdinMonkey is a hammer that will kill incentive to optimize JavaScript that humans write. Eh, I'm not worried about this. Many apps will have no reason to migrate to asm.js, and for as long as some big and important apps are written in JavaScript, there will be incentive to optimize plain JavaScript. JavaScript and other dynamically-typed languages exist because in many cases they are the best and most convenient way to write apps. But suppose this weren't true; suppose that in the long-term developers started favoring statically-typed languages for web apps, either because of performance or because of usability (Eclipse-like IDE convenience; hard to provide in a dynamic language). Is the author saying that we should artificially prop up usage of dynamic languages by taking away some of the inherent performance benefits of static languages? That doesn't sound like the best way to achieve technical excellence in the long term. In the marketplace of ideas and technologies, let things succeed or fail based on their demonstrated merit, rather than trying to pick winners and losers based on our preconceptions. > Somebody might say that [my proposed bytecode] does not run everywhere. Nope. It does run everywhere: just take JavaScript and write a simple one pass translator from this bytecode to JavaScript. You can think of asm.js as just that; a one-pass translator of an implicitly-defined bytecode to JavaScript. If you want to view/edit it as a more traditional-looking byte-code, you can easily implement a YourBytecode<->asm.js compiler. It just so happens that asm.js is a backward-compatible representation, so works more conveniently as the standardized wire encoding. (I have not studied the asm.js spec in detail, but I've seen pcwalton describe it as an alternate encoding of LLVM bitcode, so I suspect that the idea of implementing a YourBytecode<->asm.js compiler is actually reasonable given the asm.js definition).

niggler 14y ago
" If you want to view/edit it as a more traditional-looking byte-code, you can easily implement a YourBytecode<->asm.js compiler." There are quite a few hurdles, and some of them will be resolved with some stuff Mozilla has proposed in ES6. But as it stands now, you can't use CLR IL bytecode or even JVM bytecode.
- glhaynes 14y ago
  You couldn't (reasonably) compile the CLR or the JVM to asm.js? I'd assume you could, which would seem to point toward a translation of bytecodes (since that's what the asm.js-hosted CLR/JVM would be doing) being feasible…

aeflash 14y ago

> It can’t allocate normal JavaScript objects or access normal JavaScript properties. No strings. Only arithmetic and typed arrays (a single one actually with multiple views). I think he is missing a core concept here. You can create and modify strings, just at a lower level. An array of ints can be used as a char array, which in turn can be used as a string. You just have to interface with it at a lower level, probably implementing your own C-style strlen/strtok functions. It will be more complicated, especially if you need to accommodate unicode, but it is doable. Granted, there is no advantage to abandoning the built-in string manipulation functions except speed, but you would only use asm.js when speed absolutely matters. At a more fundamental level, when you have access to memory through a stack and/or heap, and can create arrays of ints with which you can do normal arithmetic and load/store operations, you really can do anything. After all, that is the entirety of what actual assembler code has to work with. You just have to make your own abstractions.

mraleph 14y ago
When I say "no strings" I mean JavaScript built-in primitive string values. I will amend the paragraph to make it explicit. It was added because I talked to people who think that just adding "use asm" on top of their node.js module will make it go as fast as C++ without realizing that asm.js is a very limited subset with its own rules. You can surely represent a JS string as a Uint16Array or Uint8Array, but copying things in and out of emulated heap into real heap will cause penalty. You will also have to reimplement a lot of functionality that host JS engine provides. Trying to implement say a regexp engine in asm.js that would be as performant as V8's built-in on would be a challenge. Yes, you can do anything. I don't dispute that. But you have to do it manually and sometimes you are replicating functionality that already exists in the host engine e.g. you might implement GC, but it will less efficient than builtin one.

foursquared 14y ago

"Please keep in mind that I used to work on V8" In theory a V8 could optimize regular JS as fast as asm.js, but in practice OdinMonkey made this code 3x to 10x faster (or more) with a couple months of effort. And to boot it is completely compatible with every JS engine, and the code generated can be cached offline for fast startup (because of the linking part), and the FFI between JS and asm.JS is trivial. Basically this post is sour grapes. Mozilla came up with a better idea than the so-called geniuses at Google did.

zem 14y ago
That's a weird thing to say. Is the perception really that mozilla doesn't have its share of geniuses?

mappu 14y ago

In related news, researchers from Mozilla and UC San Diego with support from Microsoft Research have recently published another approach to typed JavaScript, named Dependent Javascript or "DJS". This isn't focused on performance so much as correctness. 1. http://lambda-the-ultimate.org/node/4700 http://lambda-the-ultimate.org/node/4700 2. http://goto.ucsd.edu/~ravi/research/djs/ http://goto.ucsd.edu/~ravi/research/djs/

acqq 14y ago

The author complains about having to write x = 0 in asm.js blocks where it simply means "here I declare x to be a number and not undefined". He worries that "if you remove a single + or | the code above will be rejected by the validator." But it is good: if your goal is to have a really fast code, and declared the section as such, you don't want any construct that will make it significantly slower. Finally, author believes that the "JavaScript" code can be made "as fast" even without annotating it like in asm.js. He writes "I don't believe that anything like asm.js is needed to generate highly efficient native code" but of course he shows nowhere how something like that cab be achieved. Because it can't. Unless you somehow specify your assumptions in most of the cases you have to have the run-time checks. Which are slow. Observe just for example: c = a + b; If you haven't written before a = 0 and b = 0 you have to assume that a and be can be strings etc. You can have some code to take the int route but you have to have runtime checks. Now if you even wrote a = 0 and b = 0 and you're doing the loop in which you have a + b, you can't assume that the result will fit 32 bits. Which you don't need, unless you really want to do 32-bit arithmetic -- there are algorithms where you get the performance advantage by using it. The asm.js annotations are a really clever way to tell to the JIT what you (the programmer) expect. The sections allow you to get the nice clean pieces of clean native code, free of a lot of run-time checks. Speed and much more efficient memory use. Pure goodness.

Millennium 14y ago
Correct me if I'm wrong, but wouldn't the hypothetical techniques needed to enable something like "asm.js without the compiler hint" also come rather close to solving the halting problem?
- jkrems 14y ago
  The techniques need to enable something like "asm.js without the compiler hint" exist and are in use today in JIT compilation (at least to some degree). Since the source code does not generally change and the generated instructions may, you can make assumptions first and later on rewrite the instructions if your assumptions don't hold. At least that's how I understand it. If you would do AOT compilation and ship the instructions, then you may be right about the halting problem.

coldtea 14y ago

OK, let's say that with stuff like ams.js we never get true native performance than say NaCL would give. Isn't that also a good thing? I wouldn't want the web as a platform to be that good that it kills all native desktop applications, essentially turning every computer into something like a Chrome Book. Isn't that a real danger with stuff like NaCL?

GnarlinBrando 14y ago
> I wouldn't want the web as a platform to be that good What? Are you so ideologically caught up that you actually wish something wont get good? It is totally reasonable to to think something isn't the right approach or a waste of time, or to not like the workflow, etc. But to actually wish that something wont get good enough to be a general solution even if it can? How does that make any sense?
- coldtea 14y ago
  >But to actually wish that something wont get good enough to be a general solution even if it can? How does that make any sense? It makes a lot of sense because things do not happen in isolation. A "good enough web platform" could bring a lot of OTHER outcomes too. I wrote one in my comment already: all computers because Chromebooks, glorified clients. That has other consequences: you loose control, you don't own your apps (the company does, and it can take them from you in an instant, like Google Reader), etc. Not to mention the privacy implication of ALL apps running in a web browser, getting their data remotely. Or the implications for companies and governments locking content, pushing you out, demanding a premium, etc.
  - fzzzy 14y ago
    I don't see that those consequences follow, at all. I see a natural evolution from where we are now to a world where people own their own servers in the cloud and run all the software on them. Or, if you really don't want any data to go over the wire, just run all the web app servers locally. There was a big swing from the idea that at&t would sell you a terminal that was connected to a central mainframe, to personal computers that were distributed, back to everything being centralized because the advantages of the web were compelling and centralizing things was the natural path. Things will swing back again to decentralization, but the difference this time is you will be able to access all of your data from anywhere at any time.

dgreensp 14y ago

There's a valid philosophical objection here, and I found the article illuminating about the nature of Asm.js. The strategy of making a static subset of a language that's easy to compile works great -- if it's targeted at humans! RPython, for example, means you can write the Python VM in Python, and the SmallTalk VM (or Squeak?) was written in SmallTalk using the same approach. The point is part of your code base is in this restricted language instead of C, and you can bootstrap that way. If this language is just a compiler target and not meant to be particularly human-friendly (RPython has classes and mixins) then making it a weird subset of JavaScript is a little more dubious and without precedent that I can think of.

acqq 14y ago
It's definitely not "just a compiler target," not more than the assembly language in which people still write some code by hand when there's need for that. The real world example: https://github.com/srijs/rusha https://github.com/srijs/rusha (see the benchmarks -- Firefox 21 uses asm.js) and the source https://github.com/srijs/rusha/blob/master/rusha.js https://github.com/srijs/rusha/blob/master/rusha.js I don't see that the code got ugly. The calculations needed are the same, the most obvious differences from the "non-asm.js" code is the "asm.js" and a few |0 marks. And some of such |0 constructs can improve speed even on the browsers which don't do full "asm.js". So the engines will get smarter by recognizing such constructs even without the full support of "asm.js" segments. It's a win-win already.
- munificent 14y ago
  Right, but your example here is a particularly skewed one. It's a hashing library. All it does is take integers and do arithmetic on them. Most real-world application code is not at all like that. Asm.js doesn't even support strings as far as I know.
  - acqq 14y ago
    Asm.js is exactly made for things like that: the pieces of code that don't depend on "strings" but calculate a lot. And for things like this: http://bellard.org/jslinux/ http://bellard.org/jslinux/ For "strings" the existing JITers do already the good job. You can just use JavaScript as is then.

askimto 14y ago

Looks like the asm.js Jedi mind trick didn't work on someone :)

guilloche 14y ago

Yeah, I have the same bad feeling on asm.js. If we need c/c++=>llvm=>javascript/asm.js for performance reasons, then why not just embed llvm inside web brosers? Isn't it much easier, and much cleaner?

nivertech 14y ago

I find asm.js pointless. If all you need a fast numeric calculations in JavaScript, the better compiler backend would be WebCL - OpenCL binding to JavaScript.

michaelwww 14y ago
Could you expand on this? It seems like an apples and oranges comparison.
- nivertech 14y ago
  Asm.js only allows numeric operations on emulated heap buffer. You can do much better with OpenCL on CPU device. Asm.js intended to be used as a backend for compilers. One of OpenCL use cases is the same. Asm.js code pretends to be a JavaScript code, OpenCL does not, but there is WebCL - a JavaScript binding standard for OpenCL.
  - michaelwww 14y ago
    Asm.js is still JavaScript. You can do all kinds of things that JavaScript can't do by itself if you call native code with a plug in. That's the difference. No plugin. No installation.
    - nivertech 14y ago
      What's the difference between Mozilla deciding to bundle Asm.js with Firefox vs. Google deciding to bundle WebCL and WebGL with Chrome?
      - michaelwww 14y ago
        I refer you to http://asmjs.org/faq.html http://asmjs.org/faq.html to understand the difference. Particularly the Question: "Why not NaCl or PNaCl instead? Are you just being stubborn about JavaScript?"