10 ms·

Now this is big. Doesn't this means Node.js would benefit from asm.js addition in V8 as well? Few months ago by Brendan Eich: "Get your tums out, pal. We're ta

• Ygg2 14y ago
  JSC? Anyway I agree. People in the previous thread clamoring for NaCl, claiming asm.js isn't supported by other browser now look really, really foolish in hindsight. I'm moderately happy the Web is moving in this direction. I'm glad Mozilla is moving it in that direction :)
  • sirn 14y ago
    JavaScriptCore, Safari's JavaScript engine.
  • duaneb 14y ago
    I have no idea why Mozilla was so resistant to pnacl. It's a nice step beyond the nasty legacy JavaScript mess. Among other things, JavaScript is necessarily single threaded... Yea.
    • Raphael_Amiard 14y ago
      > I have no idea why Mozilla was so resistant to pnacl Pepper for one is a pretty good reason IMHO
      • duaneb 14y ago
        Why? It seems like a good replacement for npapi.
        • sirn 14y ago
          Brendan Eich discussed about this few months ago at: https://news.ycombinator.com/item?id=4630334 https://news.ycombinator.com/item?id=4630334 Anyway, he said that the problem with Pepper is that its API is gigantic and its only spec is the implementation in Chromium. Other browsers could port the API but it come at very high cost due to WebKit-specific glue code.
          • pekk 14y ago
            The "problem" with pnacl is that it means the end of Javascript's death grip on the browser, which Brendan Eich is interested in extending for obvious reasons
            • lukeschlather 14y ago
              I think you're overstating it. It more likely means the beginning of Google's death grip on the browser.
              • munificent 14y ago
                How does Google have a death grip on the browser?
                • lukeschlather 14y ago
                  They don't yet. I'm saying pnacl is more likely to result in Google getting a death grip on the browser than ending Javascript's dominance.
                  • munificent 14y ago
                    Oooooh, the ominous "yet". Scary.
        • jgraham 14y ago
          To be clear, there are two things that have historically been called "pepper". The first was a basically a better version of NPAPI, with the limited scope that implies. That was replaced by something that's basically a Google-proprietary replacement for the entire web stack, with both the scope and the problems that implies.
    • mtgx 14y ago
      Isn't V8 multi-threaded? You might be right about the other JS engines, though.
      • duaneb 14y ago
        It may run on multiple threads but I don't think it exposes threading to the runtime. Ecmascript is certainly single threaded and async by design, so v8 would be straying far from the spec. I'd love to be proven wrong.
        • Ygg2 14y ago
          Wait, what are Web-workers then?
          • cwmma 14y ago
            for opening up a new separate thread, that you can only communicate through message passing. It's not part of the core language but the browser library hence why you can't use them in Node.
            • rictic 14y ago
              They're also more directly comparable to processes than threads, as they do not share memory (though there are a couple of proposals to allow them to).
              • duaneb 14y ago
                Apparently ParallelArray allows shared memory.
                • cwmma 14y ago
                  yeah but that's not approved yet and from what I can tell ParallelArray is higher level then Workers and doesn't really expose that sort of thing.
    • Ygg2 14y ago
      DRY? I think NaCl will require Mozilla to implement another VM or parser, and do same optimization it already does on JS. So why should they repeat themselves?
      • duaneb 14y ago
        Because designing web standards around laziness is not a great idea and leads to things like.... JavaScript.
    • espadrine 14y ago
      > Among other things, JavaScript is necessarily single threaded... That isn't quite true anymore either, because of Web Workers and ParallelArray. https://bugzilla.mozilla.org/showdependencytree.cgi?id=801869&hide_resolved=1 https://bugzilla.mozilla.org/showdependencytree.cgi?id=80186... https://github.com/RiverTrail/RiverTrail/wiki/ParallelArray https://github.com/RiverTrail/RiverTrail/wiki/ParallelArray
      • niggler 14y ago
        "That isn't quite true anymore either, because of Web Workers and ParallelArray." Quote from yesterday's discussion: https://news.ycombinator.com/item?id=5451658 https://news.ycombinator.com/item?id=5451658 "WebWorkers are not really a multithread model. Game engines could be written to leverage message passing based isolates, but in some cases, but doing it in an optimal form isn't exactly developer friendly, it's one of pains of developing the PS3 SPEs is that they didn't share system memory and you had to DMA stuff around."
        • pcwalton 14y ago
          ParallelArray allows data to be shared without copies.
      • duaneb 14y ago
        Isn't that browsers only? And not really suited (or horribly suited) for realtime work like video games.
        • audreyt 14y ago
          WebWorker with native threads is available on Node.js: https://github.com/audreyt/node-webworker-threads https://github.com/audreyt/node-webworker-threads For an alternate model of parallel computing, WebCL (OpenCL) has been ported to Node.js as well: https://github.com/fifield/node-webcl https://github.com/fifield/node-webcl
• icebraining 14y ago
  Doesn't this means Node.js would benefit from asm.js addition in V8 as well? Probably, but why? asm.js is supposed to be a target for compilation, but if you can run Node, you have a better target: actual machine code.
  • sirn 14y ago
    What I meant to say was not to use asm.js as target for compilation, but rather implementing performance-critical module in asm.js subset and get the extra performance out of V8. Sort of like how Rusha[1] did it. [1]: https://github.com/srijs/rusha/commit/e435ccdd709b6a3374879cfce7329f9325690aca https://github.com/srijs/rusha/commit/e435ccdd709b6a3374879c...
    • abecedarius 14y ago
      Another example I posted yesterday: http://wry.me/hacking/Turing-Drawings/ http://wry.me/hacking/Turing-Drawings/
  • grayrest 14y ago
    Crossing the JS to C++ barrier is not free [1]. Compiling the C to asm.js allows everything to live in the VM and avoids this cost. [1] https://github.com/felixge/faster-than-c https://github.com/felixge/faster-than-c is a talk by a longtime node contributor on this topic.
    • abecedarius 14y ago
      Calling asm.js code is not free either, it's worth mentioning. I measured it at (very) roughly 2ms/call for the code I posted yesterday. (At asmjs.org they mention they intend to address this.)
      • erichocean 14y ago
        2ms is obscenely slow for a no-op function call. If correct, that needs to be treated as a bug by the asm.js team.
• iso8859-1 14y ago
  "Cross-browser". Why exactly is it asm.js cross-browser? Because they just said they'd put it in V8? The argument is moot since if Mozilla said that first about PNaCl (that they'd adopt it) it would be PNaCl that would be the cross-browser solution. No, I don't care about backwards-compatibility. I care about the solution leveraging existing infrastructure and not being a hack.
  • tomp 14y ago
    > I don't care about backwards-compatibility. I care about the solution leveraging existing infrastructure Isn't that one and the same?
  • masklinn 14y ago
    > "Cross-browser". Why exactly is it asm.js cross-browser? Because they just said they'd put it in V8? Because it's a strict subset of javascript which is already cross-browser. > The argument is moot since if Mozilla said that first about PNaCl (that they'd adopt it) it would be PNaCl that would be the cross-browser solution. PNaCl is still not done, still not fully specified and still full of Chrome implementation details via Pepper. > No, I don't care about backwards-compatibility. I care about the solution leveraging existing infrastructure and not being a hack. Which would exclude PNaCl since there's no existing PNaCl infrastructure.
  • Millennium 14y ago
    asm.js is, at its heart, nothing more than a compiler hint. It tells the runtime that the JavaScript you're writing in this function follows some conventions that happen to be easy to optimize, but it's still JavaScript code. A browser that doesn't support asm.js will pause for a few nanoseconds to wonder what the heck that strange string at the start of the function is, then go on to execute the JavaScript code the same way it always does, with the same result as if it had known what asm.js is.
  • bradleyjg 14y ago
    As far as I can tell they haven't said they'd put it in V8. One member of the chromium team, who doesn't work in that area, has opened up a feature request. This seems to be much ado about nothing unless and until it's accepted and assigned.
• ksec 14y ago
  On the Note of Node.js, i was wondering if there will ever be a Node.js based on IonMonkey + Baseline Compiler instead of V8.
  • ed_blackburn 14y ago
    On the Note of Node.js, i was wondering if there will ever be a Node.js based on IonMonkey + Baseline Compiler instead of V8. The engineer in my says, cool idea and judging by libuv [0] The joyent / node.js team seems to be open to abstractions, if help is offered. Assuming the technical task isn't too expensive in terms of leaky abstractions or ripple, one has to ask the next question, if V8 works...why, would it be worth it? [0] https://github.com/joyent/libuv https://github.com/joyent/libuv
  • surrealize 14y ago
    The mozilla guys took a stab at creating a "spidernode" a while back: https://github.com/zpao/spidernode https://github.com/zpao/spidernode but then they dropped it.
• justinschuh 14y ago
  I don't see this as big. Kbr wouldn't in any way be responsible for adding asm.js support to v8. He's one of the core guys on accelerated graphics, but isn't involved in the JS engine. Also, you'd be well served to consider anything Brendan Eich claims in the context of his own motivations. Because other JS engine developers aren't necessarily enthused about signing on to support a spec that Mozilla developed mostly in secret without their input, relies extensively on engine quirks, and doesn't yet (ever?) address many hard problems like code caching and threading. I'm not saying asm.js isn't interesting, but it's not a guaranteed win either.
  • derefr 14y ago
    > other JS engine developers aren't necessarily enthused about signing on to support a spec that [company] developed mostly in secret without input from other JS engines, relies extensively on engine quirks, and doesn't yet solve many hard problems Wow, where have I heard that before? ;)
    • justinschuh 14y ago
      And I would argue that any spec tagged with these kinds of complaints rarely ever sees broad adoption, regardless who made it. From my perspective, the only thing asm.js has going for it that offsets the downsides is that the code at least runs in other JS engines even if they don't explicitly support it. And that alone might actually be enough.
  • smosher 14y ago
    You forgot to bring up his throne of skulls.
  • azakai 14y ago
    > Because other JS engine developers aren't necessarily enthused about signing on to support a spec that Mozilla developed mostly in secret without their input, I don't think that's accurate. We started work on asm.js only a few months ago; at the beginning, we had no idea if it would work, so we just threw around some ideas between each other. When we had something we felt could actually work, we immediately put it up on https://github.com/dherman/asm.js https://github.com/dherman/asm.js And worked on it there. asm.js has been discussed on IRC (#emscripten and other places), the emscripten mailing list, etc., as we further improved the spec. About the middle last month, we got some performance numbers, and felt we could say something about speed, so I mentioned asm.js in my talk at mloc.js and other more noticeable places, but it was definitely not a secret far before that. > relies extensively on engine quirks That would be a bad bug in the asm.js spec. Can you please elaborate?