4 ms·

> This seems very much targeted at emscripten and not to cross-compilers that start with GC'ed languages like GWT, Dart, ClojureScript Those languages can bene

by azakai 14y ago

> This seems very much targeted at emscripten and not to cross-compilers that start with GC'ed languages like GWT, Dart, ClojureScript Those languages can benefit as well (but might not make sense in all cases). You can compile Java to C and then to JS, here's a demo http://xmlvm.org/html5/ http://xmlvm.org/html5/ Yes, this has downsides like compiling your own GC. For GC heavy code it might be slow. But for raw computation you would probably get faster results than source-to-source like GWT does - you get LLVM optimizations, and you get asm.js which is easier for JS engines to run quickly. > It's also unclear to me how this solves the problem of startup time on mobile. Yeah, that is a problem. It's a problem on normal JS too, and also for things like PNaCl. Only shipping final native binaries can fully avoid that (but that is nonportable). > The spec seems to argue that Browser VMs could recognize asm.js and if I read between the lines, employ snapshoting the app and caching it for later quick startup? Yes, that is one possibility. It could work for normal JS too, I'm not sure why it hasn't been done yet. Worth investigating. > In all likelihood, the majority of asm.js outputs would be actually be non-human readable output of optimizing cross-compilers, Yes. > so there isn't much benefit from having a readable syntax that humans could read, so what's the real justification for using JS as an intermediate representation over say, a syntax specifically designed for minimum network overhead and maximum startup speed? The justification is that asm.js code will work, right now, in all browsers. (And it can fairly easily be optimized by them to run much faster than compiled code in JS.) Any new format would require standardization and take a long time. asm.js is just JS. For network transmission, we should implement a special minifier for it (written in JS of course).

nnethercote 14y ago
> asm.js is just JS. This needs to be shouted from the rooftops. This is the single most important constraint of the project and also its greatest strength. So asm.js isn't the magical perfect browser bytecode that everyone on HN wants -- and which would have all manner of flaws if it actually existed in concrete form, rather than a platonic ideal in people's heads -- but that's a completely unrealistic goal anyway. But asm.js is usable in all browsers immediately. asm.js is just JS.
- skatepark 14y ago
  > But asm.js is usable in all browsers immediately. asm.js is just JS. A magic JS-based bytecode that's usable in all browsers immediately isn't useful if it isn't fast. Which it isn't, because it's a JS-based bytecode executing under existing JS engines. So now we have apps that perform incredibly poorly when run on a browser without "asm.js" support, and a rather ridiculous bytecode format that will have to be parsed natively to run reasonably quickly, with a fair bit more complexity for every layer in the development and runtime stack because they insist on keeping it as valid JS syntax.
  - deleted 14y ago
    [deleted]
  - coldtea 14y ago
    >"A magic JS-based bytecode that's usable in all browsers immediately isn't useful if it isn't fast." Says who? Python, for one, is plenty usable, and is not fast. >Which it isn't Says who? JS engines are close to Java/C in speed, and 10x faster thn Ruby, Python et al. V8 is faster or as fast than statically compiled Go or JITed Julia, for example...
    - anon1385 14y ago
      >Python, for one, is plenty usable, and is not fast. In any environment where I might currently choose to use Python I also have the option to use something else for parts of the project where Python proves to be too slow. Will FirefoxOS provide such an escape hatch? >JS engines are close to Java/C in speed 'close' is a pretty vague term. For a lot of tasks Ruby is 'close' enough to C that the difference doesn't matter. For a different set of tasks Java is not 'close' enough to C (or C+asm) to be a viable choice and neither is Javascript. I'd also like to point out that battery life does matter, and using at least twice the CPU cycles for most tasks isn't conducive to good battery life.
      - coldtea 14y ago
        >In any environment where I might currently choose to use Python I also have the option to use something else for parts of the project where Python proves to be too slow. Will FirefoxOS provide such an escape hatch? Seeing that Python is 10-20 times slower than V8 for most Python/JS native operations, you should have that problem much. Especially considering that the purpose of asm.js is to give you an even greater boost in speed. And seeing that NaCl never got anywhere, not only this is your best bet but it's far better than anything else out there at the moment. asm.js IS a bytecode format. That it is human readable or that it accepts some tradeoffs because of JS doesn't matter. The end result (after the JIT pass) would not be any slower for it. The only problem with a readable "asm" would be slower load times, but that can be taken care of in the future by providing some pre-compiled format or more control over caching if asm succeeds.

by azakai 14y ago

nnethercote 14y ago

> asm.js is just JS. This needs to be shouted from the rooftops. This is the single most important constraint of the project and also its greatest strength. So asm.js isn't the magical perfect browser bytecode that everyone on HN wants -- and which would have all manner of flaws if it actually existed in concrete form, rather than a platonic ideal in people's heads -- but that's a completely unrealistic goal anyway. But asm.js is usable in all browsers immediately. asm.js is just JS.

skatepark 14y ago
> But asm.js is usable in all browsers immediately. asm.js is just JS. A magic JS-based bytecode that's usable in all browsers immediately isn't useful if it isn't fast. Which it isn't, because it's a JS-based bytecode executing under existing JS engines. So now we have apps that perform incredibly poorly when run on a browser without "asm.js" support, and a rather ridiculous bytecode format that will have to be parsed natively to run reasonably quickly, with a fair bit more complexity for every layer in the development and runtime stack because they insist on keeping it as valid JS syntax.
- deleted 14y ago
  [deleted]
- coldtea 14y ago
  >"A magic JS-based bytecode that's usable in all browsers immediately isn't useful if it isn't fast." Says who? Python, for one, is plenty usable, and is not fast. >Which it isn't Says who? JS engines are close to Java/C in speed, and 10x faster thn Ruby, Python et al. V8 is faster or as fast than statically compiled Go or JITed Julia, for example...
  - anon1385 14y ago
    >Python, for one, is plenty usable, and is not fast. In any environment where I might currently choose to use Python I also have the option to use something else for parts of the project where Python proves to be too slow. Will FirefoxOS provide such an escape hatch? >JS engines are close to Java/C in speed 'close' is a pretty vague term. For a lot of tasks Ruby is 'close' enough to C that the difference doesn't matter. For a different set of tasks Java is not 'close' enough to C (or C+asm) to be a viable choice and neither is Javascript. I'd also like to point out that battery life does matter, and using at least twice the CPU cycles for most tasks isn't conducive to good battery life.
    - coldtea 14y ago
      >In any environment where I might currently choose to use Python I also have the option to use something else for parts of the project where Python proves to be too slow. Will FirefoxOS provide such an escape hatch? Seeing that Python is 10-20 times slower than V8 for most Python/JS native operations, you should have that problem much. Especially considering that the purpose of asm.js is to give you an even greater boost in speed. And seeing that NaCl never got anywhere, not only this is your best bet but it's far better than anything else out there at the moment. asm.js IS a bytecode format. That it is human readable or that it accepts some tradeoffs because of JS doesn't matter. The end result (after the JIT pass) would not be any slower for it. The only problem with a readable "asm" would be slower load times, but that can be taken care of in the future by providing some pre-compiled format or more control over caching if asm succeeds.