5 ms·

But would they have done this without Mozilla pushing the performance with asm.js, or that fast? Competition is great, and it also makes me wonder, if they keep

by devx 13y ago

But would they have done this without Mozilla pushing the performance with asm.js, or that fast? Competition is great, and it also makes me wonder, if they keep this up - maybe NaCl won't be needed either?

cromwellian 13y ago
You still have the pthreads issue. NaCL can leverage SMP in a way that single-threaded JS can't, and the idea of introducing concurrency into JS sends shivers down my spine.
- angersock 13y ago
  You mean like, Web Workers?
  - deleted 13y ago
    [deleted]
  - cromwellian 13y ago
    WebWorkers only support message passing, it's more like processes than threads. There's no concept of shared memory.
    - angersock 13y ago
      That model is one of the easiest and safest ways of doing concurrency of which I'm aware, unless you want to enforce immutability on shared memory records.
      - cromwellian 13y ago
        We're not talking about what's safer, were talking about NaCL vs asm.js, and the primary purpose of those is to run native C code in your browser without significant rewriting (e.g. emscripten) The target for most of this is porting C games to the Web, and many modern C games use all kinds of multithreading and blocking I/O. Game programmers are not interested in safety, they are interested in performance. Yes, message passing leads to fewer bugs. It also leaves a lot of performance on the table if you are trying to maximize usage of CPU resources on an SMP architecture.
        angersock 13y ago
        "modern C games use all kinds of multithreading and blocking I/O." The funny thing here is that gave devs are still kind of weary of threading bugs, and blocking I/O was something that was probably earliest dealt with by the people having to stream content off of spinning plastic discs.
        cromwellian 13y ago
        It's true that gamedevs worry about this, and Tim Sweeney has even given prezos on how great functional languages would be for game programming, but the reality is, hardcore game devs crave two things from what I can tell: 1) determinism and 2) maximizing utilization of resources A VM or high level compiler abstraction, especially with GC, tends to interfere with #1, and sandboxed environments with abstract APIs for accessing hardware tend to interfere with #2. Yes, this is not to say that games won't use scripting, like Lua or UnrealScript, but those are not part of the rendering loop. Asm.js provides predictability in terms of GC, but it does not ensure predictability in terms of performance (because of differing JIT implementations), nor does it give the direct access to hardware resources one would like (e.g. SMP). I don't really see it as a target for next-gen games, regardless of the cool UnrealEngine demos. Mobile casual games maybe.
        pcwalton 13y ago
        > A VM or high level compiler abstraction, especially with GC, tends to interfere with #1, and sandboxed environments with abstract APIs for accessing hardware tend to interfere with #2. For #1, asm.js doesn't have GC, by and large (there are a couple of places where the GC gets used when interacting with Web APIs, but those are fixable and don't matter much in practice). For #2, "a sandboxed environment with abstract APIs for accessing hardware" precisely describes Pepper! > Asm.js provides predictability in terms of GC, but it does not ensure predictability in terms of performance (because of differing JIT implementations), nor does it give the direct access to hardware resources one would like (e.g. SMP). I don't understand what you mean. The performance predictability is fixed by "use asm" and AOT compilation. V8 is opposed, but your point (rightly, IMHO!) argues against that choice. If you're just arguing that there will be multiple implementations of asm.js and that's bad for predictability I don't see that being fixed with any solution outside of a browser monopoly. If PNaCl is to become a cross-browser solution, then you must be open to alternative implementations. As for threads, we can continue to evolve JavaScript so that it is supported, at least in asm.js mode. I don't see this as some fundamental obstacle.
      - ris 13y ago
        It's also one of the slowest.
    - pjmlp 13y ago
      > There's no concept of shared memory. Which is already more than proven that only leads to threading bugs.
      - jamesaguilar 13y ago
        I don't believe it has been proven to anyone's satisfaction that that is the only thing it leads to.
        pjmlp 13y ago
        Given the amount of developers not able to write multi-threaded applications with shared memory I would say it is very well proven.
        jamesaguilar 13y ago
        "Given the amount of developers unable to write a compiler, it is well-proven that compilers lead only to bugs."
        pjmlp 13y ago
        Where can I find a bug free one?
        jamesaguilar 13y ago
        I think the proper question under the formulation you provided is, "Where can I find one that does anything other than produce bugs," since you asserted that bugs are the only result. To which the answer is: any of them.
        riffraff 13y ago
        the argued keyword in your previous comment is "only".
        deleted 13y ago
        [deleted]
    - deleted 13y ago
      [deleted]
  - blueblob 13y ago
    Perhaps locking the DOM is a good trait if you can communicate between the main thread and the webworkers then you can request that the main thread changes the DOM and synchronize, without this you might get unexpected behavior anyways?
- jlongster 13y ago
  There's already a lot of good progress with introducing parallelism in JavaScript. See http://wiki.ecmascript.org/doku.php?id=strawman:data_parallelism http://wiki.ecmascript.org/doku.php?id=strawman:data_paralle...
- pcwalton 13y ago
  > NaCL can leverage SMP in a way that single-threaded JS can't, and the idea of introducing concurrency into JS sends shivers down my spine. I agree that we don't want to break the single-threaded JS model. But we have options, the easiest of which is to restrict shared mutable state to ArrayBuffers and asm.js, or asm.js-like code.
aboodman 13y ago
64 bit integers are one small example of something you can't do no matter how fast you make JavaScript.
- apaprocki 13y ago
  Value types (64-bit, DFP, etc) are possibly on the table for ES7. Brendan has a strawman he shows in talks. If you look at his JSConf.EU video he discusses it. edit: Video link http://www.youtube.com/watch?v=IXIkTrq3Rgg http://www.youtube.com/watch?v=IXIkTrq3Rgg
- pcwalton 13y ago
  JavaScript needs 64-bit integers no matter what; the Node folks have been clamoring for it for a long time. We need to add them. Same with SIMD. JavaScript is not some immutable thing. It needs enhancing, not replacing.
  - deleted 13y ago
    [deleted]
- v13inc 13y ago
  That's not quite true -- it is entirely possible to write a 64-bit integer class entirely in Javascript, and have a JIT / ASM.js compiler recognize that and swap out a native version (See ecmascript_simd [1] which I believe was written with this idea in mind) [1] https://github.com/johnmccutchan/ecmascript_simd https://github.com/johnmccutchan/ecmascript_simd
  - aboodman 13y ago
    Do you have any pointers to how value types can be implemented efficiently without adding type tags to the language? I can see how that would work in simple cases (say within one function), but it seems that there would be many cases where the vm cannot assume the type of a variable. I looked at the spec briefly (http://wiki.ecmascript.org/doku.php?id=strawman:value_objects#performance http://wiki.ecmascript.org/doku.php?id=strawman:value_object...), but it doesn't talk about the how.
eliben 13y ago
Competition is great, and projects like pepper.js (http://trypepperjs.appspot.com/ http://trypepperjs.appspot.com/) demonstrate that coexistence is possible as well. What's exciting about this is that for developers all of this is very positive - they can write faster code to write in the client.
nolok 13y ago
They've been doing it for years, remember that Chrome/v8 is the one that forced all the others in really caring about js speed in the first place, and kept the race going for years by always being a few steps ahead. In this cas mozilla is the one that took the lead on the asm.js case, and healthy competition is always better, but I believe it makes no doubt that the v8 team would have worked at improving their js speed as much as possible even without that pinch from mozilla.
- asadotzler 13y ago
  "remember that Chrome/v8 is the one that forced all the others in really caring about js speed in the first place" That's not accurate. I recommend you go back and look at the actual order of events here. Apple started the JS perf battle with SquirrelFish Extreme and Firefox answered with TraceMonkey, all before Chrome was even announced. I am not discounting the impact that V8 has had on the industry, but it is simply wrong to claim that Google kicked this thing off when Apple and Mozilla were both there publicly squaring off in JS benchmarks well before you, and just about every one else on the planet, even knew Chrome was a thing.
  - pornel 13y ago
    It's hard to trace who really started it. Before SquirrelFish extreme there was Opera Kestrel that crushed everyone in JS tests: http://nontroppo.org/timer/kestrel_tests/ http://nontroppo.org/timer/kestrel_tests/ and when Safari was still an early beta Opera was marketed as "The Fastest Browser on Earth".
  - afsina 13y ago
    This does not changed the fact that chrome crushed the competition just like gmail crushed others. It took a very long time others to keep up and they are still behind in most cases. IMHO v8 deserves all the credit for the advance of JavaScript performance race.

by devx 13y ago

cromwellian 13y ago

You still have the pthreads issue. NaCL can leverage SMP in a way that single-threaded JS can't, and the idea of introducing concurrency into JS sends shivers down my spine.

angersock 13y ago
You mean like, Web Workers?
- deleted 13y ago
  [deleted]
- cromwellian 13y ago
  WebWorkers only support message passing, it's more like processes than threads. There's no concept of shared memory.
  - angersock 13y ago
    That model is one of the easiest and safest ways of doing concurrency of which I'm aware, unless you want to enforce immutability on shared memory records.
    - cromwellian 13y ago
      We're not talking about what's safer, were talking about NaCL vs asm.js, and the primary purpose of those is to run native C code in your browser without significant rewriting (e.g. emscripten) The target for most of this is porting C games to the Web, and many modern C games use all kinds of multithreading and blocking I/O. Game programmers are not interested in safety, they are interested in performance. Yes, message passing leads to fewer bugs. It also leaves a lot of performance on the table if you are trying to maximize usage of CPU resources on an SMP architecture.
      - angersock 13y ago
        "modern C games use all kinds of multithreading and blocking I/O." The funny thing here is that gave devs are still kind of weary of threading bugs, and blocking I/O was something that was probably earliest dealt with by the people having to stream content off of spinning plastic discs.
        cromwellian 13y ago
        It's true that gamedevs worry about this, and Tim Sweeney has even given prezos on how great functional languages would be for game programming, but the reality is, hardcore game devs crave two things from what I can tell: 1) determinism and 2) maximizing utilization of resources A VM or high level compiler abstraction, especially with GC, tends to interfere with #1, and sandboxed environments with abstract APIs for accessing hardware tend to interfere with #2. Yes, this is not to say that games won't use scripting, like Lua or UnrealScript, but those are not part of the rendering loop. Asm.js provides predictability in terms of GC, but it does not ensure predictability in terms of performance (because of differing JIT implementations), nor does it give the direct access to hardware resources one would like (e.g. SMP). I don't really see it as a target for next-gen games, regardless of the cool UnrealEngine demos. Mobile casual games maybe.
        pcwalton 13y ago
        > A VM or high level compiler abstraction, especially with GC, tends to interfere with #1, and sandboxed environments with abstract APIs for accessing hardware tend to interfere with #2. For #1, asm.js doesn't have GC, by and large (there are a couple of places where the GC gets used when interacting with Web APIs, but those are fixable and don't matter much in practice). For #2, "a sandboxed environment with abstract APIs for accessing hardware" precisely describes Pepper! > Asm.js provides predictability in terms of GC, but it does not ensure predictability in terms of performance (because of differing JIT implementations), nor does it give the direct access to hardware resources one would like (e.g. SMP). I don't understand what you mean. The performance predictability is fixed by "use asm" and AOT compilation. V8 is opposed, but your point (rightly, IMHO!) argues against that choice. If you're just arguing that there will be multiple implementations of asm.js and that's bad for predictability I don't see that being fixed with any solution outside of a browser monopoly. If PNaCl is to become a cross-browser solution, then you must be open to alternative implementations. As for threads, we can continue to evolve JavaScript so that it is supported, at least in asm.js mode. I don't see this as some fundamental obstacle.
    - ris 13y ago
      It's also one of the slowest.
  - pjmlp 13y ago
    > There's no concept of shared memory. Which is already more than proven that only leads to threading bugs.
    - jamesaguilar 13y ago
      I don't believe it has been proven to anyone's satisfaction that that is the only thing it leads to.
      - pjmlp 13y ago
        Given the amount of developers not able to write multi-threaded applications with shared memory I would say it is very well proven.
        jamesaguilar 13y ago
        "Given the amount of developers unable to write a compiler, it is well-proven that compilers lead only to bugs."
        pjmlp 13y ago
        Where can I find a bug free one?
        jamesaguilar 13y ago
        I think the proper question under the formulation you provided is, "Where can I find one that does anything other than produce bugs," since you asserted that bugs are the only result. To which the answer is: any of them.
        riffraff 13y ago
        the argued keyword in your previous comment is "only".
        deleted 13y ago
        [deleted]
  - deleted 13y ago
    [deleted]
- blueblob 13y ago
  Perhaps locking the DOM is a good trait if you can communicate between the main thread and the webworkers then you can request that the main thread changes the DOM and synchronize, without this you might get unexpected behavior anyways?
jlongster 13y ago
There's already a lot of good progress with introducing parallelism in JavaScript. See http://wiki.ecmascript.org/doku.php?id=strawman:data_parallelism http://wiki.ecmascript.org/doku.php?id=strawman:data_paralle...
pcwalton 13y ago
> NaCL can leverage SMP in a way that single-threaded JS can't, and the idea of introducing concurrency into JS sends shivers down my spine. I agree that we don't want to break the single-threaded JS model. But we have options, the easiest of which is to restrict shared mutable state to ArrayBuffers and asm.js, or asm.js-like code.

aboodman 13y ago

64 bit integers are one small example of something you can't do no matter how fast you make JavaScript.

apaprocki 13y ago
Value types (64-bit, DFP, etc) are possibly on the table for ES7. Brendan has a strawman he shows in talks. If you look at his JSConf.EU video he discusses it. edit: Video link http://www.youtube.com/watch?v=IXIkTrq3Rgg http://www.youtube.com/watch?v=IXIkTrq3Rgg
pcwalton 13y ago
JavaScript needs 64-bit integers no matter what; the Node folks have been clamoring for it for a long time. We need to add them. Same with SIMD. JavaScript is not some immutable thing. It needs enhancing, not replacing.
- deleted 13y ago
  [deleted]
v13inc 13y ago
That's not quite true -- it is entirely possible to write a 64-bit integer class entirely in Javascript, and have a JIT / ASM.js compiler recognize that and swap out a native version (See ecmascript_simd [1] which I believe was written with this idea in mind) [1] https://github.com/johnmccutchan/ecmascript_simd https://github.com/johnmccutchan/ecmascript_simd
- aboodman 13y ago
  Do you have any pointers to how value types can be implemented efficiently without adding type tags to the language? I can see how that would work in simple cases (say within one function), but it seems that there would be many cases where the vm cannot assume the type of a variable. I looked at the spec briefly (http://wiki.ecmascript.org/doku.php?id=strawman:value_objects#performance http://wiki.ecmascript.org/doku.php?id=strawman:value_object...), but it doesn't talk about the how.

eliben 13y ago

Competition is great, and projects like pepper.js (http://trypepperjs.appspot.com/ http://trypepperjs.appspot.com/) demonstrate that coexistence is possible as well. What's exciting about this is that for developers all of this is very positive - they can write faster code to write in the client.

nolok 13y ago

They've been doing it for years, remember that Chrome/v8 is the one that forced all the others in really caring about js speed in the first place, and kept the race going for years by always being a few steps ahead. In this cas mozilla is the one that took the lead on the asm.js case, and healthy competition is always better, but I believe it makes no doubt that the v8 team would have worked at improving their js speed as much as possible even without that pinch from mozilla.

asadotzler 13y ago
"remember that Chrome/v8 is the one that forced all the others in really caring about js speed in the first place" That's not accurate. I recommend you go back and look at the actual order of events here. Apple started the JS perf battle with SquirrelFish Extreme and Firefox answered with TraceMonkey, all before Chrome was even announced. I am not discounting the impact that V8 has had on the industry, but it is simply wrong to claim that Google kicked this thing off when Apple and Mozilla were both there publicly squaring off in JS benchmarks well before you, and just about every one else on the planet, even knew Chrome was a thing.
- pornel 13y ago
  It's hard to trace who really started it. Before SquirrelFish extreme there was Opera Kestrel that crushed everyone in JS tests: http://nontroppo.org/timer/kestrel_tests/ http://nontroppo.org/timer/kestrel_tests/ and when Safari was still an early beta Opera was marketed as "The Fastest Browser on Earth".
- afsina 13y ago
  This does not changed the fact that chrome crushed the competition just like gmail crushed others. It took a very long time others to keep up and they are still behind in most cases. IMHO v8 deserves all the credit for the advance of JavaScript performance race.