6 ms·

Asm.js is intrinsically superior to native client (and yes, I do see them as competing technologies) and will inevitably push NaCl out of the market for one sim

by pvnick 13y ago

Asm.js is intrinsically superior to native client (and yes, I do see them as competing technologies) and will inevitably push NaCl out of the market for one simple reason: even if the browser doesn't explicitly optimize for asm.js, the code will still run. It may not be usably fast, but something will happen. As opposed to native client, where if your user base doesn't support it you're just dead in the water. And the trend so far is javascript getting faster and closer to native running code. Google must eventually build asm.js optimizations into Chrome. What's their alternative strategy? Ignore asm.js and let Mozilla tout Firefox's javascript engine as faster? NaCl's writing is on the wall and Google knows it.

pfraze 13y ago
I think there's room for both to exist. The strategies are hugely different and will depend on the performance payoff, but asm.js has the simplicity to make it happen while PNaCl has the resources of Google, and since resources is what PNaCl needs (docs, dev environments, marketing) then I can see both coming to maturity. I was threatened by PNaCl for a while, until I realized that it integrates with Javascript through messaging. I think it could be a really solid complement to the Web platform.
- jlongster 13y ago
  I'm kind of glad PNaCl is being researched, and it's really impressive engineering. I personally won't invest in it, but it will be very interesting if they pull it off, especially if other other browser get interested in it. There has been zero interest so far so I'm not betting on it. The thing that bothers me about PNaCl is the potential for Chrome to become silo'ed and for Google to start pushing it's own ecosystem over the web, if they can't get other browsers to join in. I don't think they'll actually do that, but the chance is still kind of scary.
  - threeseed 13y ago
    > I don't think they'll actually do that Problem is there is history of Google doing exactly this: SPDY.
    - haberman 13y ago
      SPDY is an open protocol which has been implemented by Firefox, IE, Opera, and Amazon Silk, and is being used as the basis of the HTTP 2.0 spec. I'm not sure how it could be any more open.
      - threeseed 13y ago
        When Google owns a very popular browser and extremely popular websites they are in a unique position to drive the future of the web. Now it's clear with SPDY that they are willing to abuse this position to make defacto standards come into fruition. It's why I will never support any more of these unilateral efforts. Whether something is open or not is irrelevant when in the case of NativeClient every committer works at Google.
        haberman 13y ago
        What about SPDY was "abuse?" How is it any different than asm.js, which is likewise a single-vendor standard that they are pushing other browsers to adopt?
  - josteink 13y ago
    The thing that bothers me about PNaCl is the potential for Chrome to become silo'ed and for Google to start pushing it's own ecosystem over the web No need to wait. ChromeOS and Netflix proves they are already doing this.
cia_plant 13y ago
asm.js doesn't do fancy 1970 stuff like threads, and can't do them unless it breaks backwards compatibility, which is its one technical advantage.
- jlongster 13y ago
  Web Workers are true threads, it's just the shared memory part that's missing. I think we will have to introduce some form of it at some point, and there are ways to do it but there's definitely a lot more research required (think about only allowed a typed array to be shared, with atomic reads/writes). I don't really know what's going to happen with this feature, and it is the one single thing that's going to be hard to do in JS, but I think we can solve it and there's really nothing else missing (or isn't planned to be implemented).
  - jnbiche 13y ago
    >Web Workers are true threads, it's just the shared memory part that's missing. And thank god for that. I've never understood the fetish C/++ programmers have for shared memory, and locks, and mutexes. Erlang has a much saner approach to concurrency/parallelism, and web workers isn't terribly far away from Erlang's actor model. EDIT: That said, I thought about the idea of only allowing typed arrays to be shared, and I actually really like it. I think that's a sane way to approach shared memory in JS, and it could cover some of the use cases that web workers aren't a big help with.
    - dmpk2k 13y ago
      > I've never understood the fetish C/++ programmers have for shared memory, and locks, and mutexes. There are some problems which are more amenable to shared mutable memory, especially when performance or memory space is a concern. And for those problems where the sharing of mutable data is not needed, forking, pointer ownership, thread-local data, and const correctness are all old concepts. No silver bullet.
    - rdtsc 13y ago
      A lot of languages that claim to have "borrowed" from Erlang often borrow the "concurrent unit running independently communicating by a channel or mailbox" idea. Very few borrow the most amazing part -- isolated heaps for each of the lightweight processes. Web workers and Dart isolates, have that as well. I am not claiming they borrowed from Erlang, just saying they have that nice feature. See, fault tolerance was actually the #1 priority when building Erlang not high concurrency. High concurrency was there too but it was #2. Also the tough part is selling fault tolerance. Only those that have implemented large concurrent systems using shared memory models, plagued by dangling pointers, large mutable state in the middle of everything moving around, and have it fail will appreciate fault tolerance. Most will shrug it off -- "hey look, I can run language shootout's Mandelbrot 10x faster!". There is a trade-off there, of course. Just like in a real OS. If you want to fork separate processes for each request, you'll pay for fault tolerance in performance some, if instead you'd just called a callback in the same process.
IanET 13y ago
Portable NaCl does something similar via pepper.js
ajross 13y ago
I'm not sure "intrinsically superior" is the right way to think about this. If you were asked for a mechanism to get web clients to execute stuff "fast" that was generated from a traditional C-like compiler front end, you surely wouldn't have designed asm.js. You'd probably have ended up with something more like the JVM or PNaCL. It's true that asm.js wins for compatibility, for obvious reasons. And that's a powerful advantage. And it works in the same runtime that existing web apps do, which likewise a win; Java and especially NaCl have complicated interoperability paradigms. They are not just "a faster web page", which is what 90% of developers really wanted to begin with. That said, the remaining 10% really do want something more. They want to write targetted architecture-specific assembly, perhaps. They want access to syscall-level abstractions like threads and true sockets (buffer sizes, Nagle settings, timeouts, etc...). And asm.js has nothing for these people. And despite its simlicity, asm.js is still mostly just a toy. It's got one working compiler backend that isn't packaged sanely anywhere. I've three times now decided to get serious and build emscripten from source, and three times given up -- it lags LLVM releases, it has glitchy behavior. Compare to clang and especially gcc which build robustly and cleanly everywhere and come with elaborate test suites. This isn't a toolchain I'm about to start betting a company on, for sure. Give it time. I like asm.js too. But it's never going to be The Answer to remotely deployable "native like" code any more than Java was.
- pcwalton 13y ago
  > They want to write targetted architecture-specific assembly, perhaps. Neither PNaCl nor the JVM gives you this.
  - ajross 13y ago
    True enough, though NaCl does. I was mostly listing a bunch of stuff asm.js doesn't do to address the "intrinsically superior" comment, not giving a pros and cons list of specific technologies. Feel free to ignore that point if you like, I don't see that it meaningfully affects my argument.
    - espadrine 13y ago
kayoone 13y ago
PNaCl has a JS fallback too, which is pepper.js so we should all be good eventually. Somehow people seem to miss this.
haberman 13y ago
> As opposed to native client, where if your user base doesn't support it you're just dead in the water. Or you use pepper.js for compatibility with non-PNaCl browsers, which compiles the PNaCl app to plain JS.

by pvnick 13y ago

pfraze 13y ago

I think there's room for both to exist. The strategies are hugely different and will depend on the performance payoff, but asm.js has the simplicity to make it happen while PNaCl has the resources of Google, and since resources is what PNaCl needs (docs, dev environments, marketing) then I can see both coming to maturity. I was threatened by PNaCl for a while, until I realized that it integrates with Javascript through messaging. I think it could be a really solid complement to the Web platform.

jlongster 13y ago
I'm kind of glad PNaCl is being researched, and it's really impressive engineering. I personally won't invest in it, but it will be very interesting if they pull it off, especially if other other browser get interested in it. There has been zero interest so far so I'm not betting on it. The thing that bothers me about PNaCl is the potential for Chrome to become silo'ed and for Google to start pushing it's own ecosystem over the web, if they can't get other browsers to join in. I don't think they'll actually do that, but the chance is still kind of scary.
- threeseed 13y ago
  > I don't think they'll actually do that Problem is there is history of Google doing exactly this: SPDY.
  - haberman 13y ago
    SPDY is an open protocol which has been implemented by Firefox, IE, Opera, and Amazon Silk, and is being used as the basis of the HTTP 2.0 spec. I'm not sure how it could be any more open.
    - threeseed 13y ago
      When Google owns a very popular browser and extremely popular websites they are in a unique position to drive the future of the web. Now it's clear with SPDY that they are willing to abuse this position to make defacto standards come into fruition. It's why I will never support any more of these unilateral efforts. Whether something is open or not is irrelevant when in the case of NativeClient every committer works at Google.
      - haberman 13y ago
        What about SPDY was "abuse?" How is it any different than asm.js, which is likewise a single-vendor standard that they are pushing other browsers to adopt?
- josteink 13y ago
  The thing that bothers me about PNaCl is the potential for Chrome to become silo'ed and for Google to start pushing it's own ecosystem over the web No need to wait. ChromeOS and Netflix proves they are already doing this.

cia_plant 13y ago

asm.js doesn't do fancy 1970 stuff like threads, and can't do them unless it breaks backwards compatibility, which is its one technical advantage.

jlongster 13y ago
Web Workers are true threads, it's just the shared memory part that's missing. I think we will have to introduce some form of it at some point, and there are ways to do it but there's definitely a lot more research required (think about only allowed a typed array to be shared, with atomic reads/writes). I don't really know what's going to happen with this feature, and it is the one single thing that's going to be hard to do in JS, but I think we can solve it and there's really nothing else missing (or isn't planned to be implemented).
- jnbiche 13y ago
  >Web Workers are true threads, it's just the shared memory part that's missing. And thank god for that. I've never understood the fetish C/++ programmers have for shared memory, and locks, and mutexes. Erlang has a much saner approach to concurrency/parallelism, and web workers isn't terribly far away from Erlang's actor model. EDIT: That said, I thought about the idea of only allowing typed arrays to be shared, and I actually really like it. I think that's a sane way to approach shared memory in JS, and it could cover some of the use cases that web workers aren't a big help with.
  - dmpk2k 13y ago
    > I've never understood the fetish C/++ programmers have for shared memory, and locks, and mutexes. There are some problems which are more amenable to shared mutable memory, especially when performance or memory space is a concern. And for those problems where the sharing of mutable data is not needed, forking, pointer ownership, thread-local data, and const correctness are all old concepts. No silver bullet.
  - rdtsc 13y ago
    A lot of languages that claim to have "borrowed" from Erlang often borrow the "concurrent unit running independently communicating by a channel or mailbox" idea. Very few borrow the most amazing part -- isolated heaps for each of the lightweight processes. Web workers and Dart isolates, have that as well. I am not claiming they borrowed from Erlang, just saying they have that nice feature. See, fault tolerance was actually the #1 priority when building Erlang not high concurrency. High concurrency was there too but it was #2. Also the tough part is selling fault tolerance. Only those that have implemented large concurrent systems using shared memory models, plagued by dangling pointers, large mutable state in the middle of everything moving around, and have it fail will appreciate fault tolerance. Most will shrug it off -- "hey look, I can run language shootout's Mandelbrot 10x faster!". There is a trade-off there, of course. Just like in a real OS. If you want to fork separate processes for each request, you'll pay for fault tolerance in performance some, if instead you'd just called a callback in the same process.

IanET 13y ago

Portable NaCl does something similar via pepper.js

ajross 13y ago

I'm not sure "intrinsically superior" is the right way to think about this. If you were asked for a mechanism to get web clients to execute stuff "fast" that was generated from a traditional C-like compiler front end, you surely wouldn't have designed asm.js. You'd probably have ended up with something more like the JVM or PNaCL. It's true that asm.js wins for compatibility, for obvious reasons. And that's a powerful advantage. And it works in the same runtime that existing web apps do, which likewise a win; Java and especially NaCl have complicated interoperability paradigms. They are not just "a faster web page", which is what 90% of developers really wanted to begin with. That said, the remaining 10% really do want something more. They want to write targetted architecture-specific assembly, perhaps. They want access to syscall-level abstractions like threads and true sockets (buffer sizes, Nagle settings, timeouts, etc...). And asm.js has nothing for these people. And despite its simlicity, asm.js is still mostly just a toy. It's got one working compiler backend that isn't packaged sanely anywhere. I've three times now decided to get serious and build emscripten from source, and three times given up -- it lags LLVM releases, it has glitchy behavior. Compare to clang and especially gcc which build robustly and cleanly everywhere and come with elaborate test suites. This isn't a toolchain I'm about to start betting a company on, for sure. Give it time. I like asm.js too. But it's never going to be The Answer to remotely deployable "native like" code any more than Java was.

pcwalton 13y ago
> They want to write targetted architecture-specific assembly, perhaps. Neither PNaCl nor the JVM gives you this.
- ajross 13y ago
  True enough, though NaCl does. I was mostly listing a bunch of stuff asm.js doesn't do to address the "intrinsically superior" comment, not giving a pros and cons list of specific technologies. Feel free to ignore that point if you like, I don't see that it meaningfully affects my argument.
  - espadrine 13y ago

kayoone 13y ago

PNaCl has a JS fallback too, which is pepper.js so we should all be good eventually. Somehow people seem to miss this.

haberman 13y ago

> As opposed to native client, where if your user base doesn't support it you're just dead in the water. Or you use pepper.js for compatibility with non-PNaCl browsers, which compiles the PNaCl app to plain JS.