10 ms·

“The 'use asm' pragma is not necessary to opt into optimizations in V8”

116 points by elisee 13y ago

nonchalance 13y ago
http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html suggested that this would happen: > When I sit down and think about performance gains that asm.js-implementation OdinMonkey-style brings to the table I don’t see anything that would not be possible to achieve within a normal JIT compilation framework and thus simultaneously make human written and compiler generated output faster.
- 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.
      - 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.
- jlongster 13y ago
  This is great news, and most people knew that Chrome could close a lot of the gap and saw asm.js as a competitive push. The main goal seems to have worked. There is still a ways to go though before they are fully on par with Firefox. Note that one of the benchmarks is still far slower on Chrome, and there are still probably edge cases here and there that trigger slow JS in Chrome. The guarantee of asm.js that your code is ~2x slower than native is nice. Additionally, loading in massive amounts of asm.js in Firefox will be much faster in Firefox in the future when they optimize the parser for asm.js. All in all, these are very happy times. There are pros and cons to both approaches, but it's exciting to see how far it's going.
  - anon1385 13y ago
    >The guarantee of asm.js that your code is ~2x slower than native is nice What? How did a couple of benchmarks that showed ~2x performance for a few tasks become a 'guarantee'? In some situations asm.js only takes twice as long to run your code, in others it takes 12 times as long[1] or even more[2]. [1] http://cdn.arstechnica.net/wp-content/uploads/2013/05/benchmark-game-native-v-openmp-v-asmjs.png http://cdn.arstechnica.net/wp-content/uploads/2013/05/benchm... [2] http://cdn.arstechnica.net/wp-content/uploads/2013/05/classic-native-v-optimized-v-asmjs.png http://cdn.arstechnica.net/wp-content/uploads/2013/05/classi...
    - azakai 13y ago
      Those are examples of native code using multiple processes or threads. The asm.js code compared to them did not use multiple processes (but it could have, using web workers), nor did it use threads (which are not available on the web). It's fair to say that for single-threaded code, asm.js has a very good chance of running at half the speed of native, or better. For multicore code, it depends on whether web workers make sense for that use case - if they do, it can still maintain the same performance compared to native. Otherwise, the web platform would need to consider adding some more low-level parallelism to JS. Such proposals exist and there is some discussion about them.
- azakai 13y ago
  I agree with mraleph that this is possible. But it has not happened yet: if you look at the slide linked to there, https://v8.googlecode.com/issues/attachment?aid=25990016000&name=asm-benchmarks.png&token=h4vTA5HJV-Lh78OlhdyF4312yuA%3A1381857693963&inline=1 https://v8.googlecode.com/issues/attachment?aid=25990016000&... you can see that on a few of those there is still a significant difference, for example on Lua (I filed an issue on that here http://code.google.com/p/v8/issues/detail?id=2873 http://code.google.com/p/v8/issues/detail?id=2873 ). In principle, a JIT can do anything an AOT compiler can (and more). In practice, the JITs in Chrome and Firefox have gotten close to what the asm.js AOT in Firefox can reach, but only on most benchmarks, not all. The AOT does give a fairly good guarantee of always running the code at a good speed, while the JITs depend on heuristics. In practice, this means that JITs can be tweaked to run any benchmark well, but they don't always do it out of the box, while the AOT far more often does do so. Again, JIT heuristics can be fixed and improved, I have no doubt about that. And JITs could be designed to rely less on heuristics, I am a strong believer in that as well. But neither of those has yet been proven. I hope they will, though :)
- jerf 13y ago
  The modern version of "sufficiently smart compiler" has become the "sufficiently smart JIT optimizer". Confidence remains as high as ever, but alas, it seems performance is doing the same thing, plateauing noticeably before reaching parity. It's hard to get over the fact that a JIT simply faces an uphill battle against an engine that starts by restricting you to a subset of the language; basically, you can assume both engines are being written by equally smart people, so you kind of have to expect that the one that takes the restrictions is going to have a long-term persistent advantage in practice, no matter how theoretically the other team could catch up. OdinMonkey still has all the JIT opportunities, but it has other opportunities too.
Danieru 13y ago
From what I understand writing fast javascript is hard because the engines are improving so fast no one knows what is fast yet. Thus asm.js is a promise to developers: "Stay within the subset and your javascript will be fast". Yet it never was "use asm" which made asm.js fast. It was the js engine. "use asm" carries symantical knowledge so a browser can warn if you break out of the subset. It also serves as a strong hint that should make the optimizer's easier. This is why I think asm.js is the future. Mozila does not need buy in from Google, or Apple, or MS. Instead developers can compile to asm.js and their code will run, and in time it will run faster. So in effect Chrome supports arm.js but they are not making a promise. I think it would be better for the internet if they made this promise.
- eliben 13y ago
  > Stay within the subset and your javascript will be fast You do realize that asm.js was not designed to be written by hand, don't you? It's a target for compilers. There are no bounds "to stay within" for hand-written JS which is still the vast majority of the code out there.
  - Danieru 13y ago
    I do, which is why I said developers may "compile" their program into asm.js Even still someone has to write that compiler and they want to know what will be fast. I do not see many people writing asm.js by hand beyond optimizing vital sections.
- camus2 13y ago
  > Mozila does not need buy in from Google, or Apple, or MS. So why Chrome should buy from Firefox? why should they follow the asm.js spec ? Maybe it i the wrong answer to a real problem, javascript speed and its memory foodprint.Why not fix the problem at the source instead of creating a subset? not meant to be written by hand? Chrome approach seems better.
  - Danieru 13y ago
    A fair question. I think it has parallels to Intel's itanium vs AMD's x64. I cannot pretend to know what is best in a perfect world. Yet I am willing to pretend to know what is the more practical way forward. Native Client is and was an interesting approach, but it requires buy in. Buy in which it was not getting, and it had several years to get said buy in. When asm.js got announced I can only saw I was shocked. asm.js is brilliant! Brilliant in the same way utf-8 is. It does not require heavy changes yet could bring 90% of the benefit. It does not require a new sandbox. It is cross-platform and cross-architecture!
k_bx 13y ago
I think this only states that asm.js or it's tests are far from perfect now.
cliffbean 13y ago
Getting the Citadel demo to run at 60fps is impressive. It means that V8 is "fast enough" to keep up with the video card on that application. However, the benchmarks at [0] clearly show that this is not the end of the story. The "workload0" runs measure startup time. All the other workloads show runtime performance, and V8 is still quite a ways behind. [0] http://arewefastyet.com/#machine=11&view=breakdown&suite=asmjs-apps http://arewefastyet.com/#machine=11&view=breakdown&suite=asm...
- zobzu 13y ago
  It's interesting to see how Firefox in these benchmarks is way, way faster than Chrome - quite a turn of things.
kevingadd 13y ago
Sadly V8's dev team has yet to address the other problem that "use asm" solves - falling out of JIT sweet spots due to broken heuristics. If you maintain a large machine-generated JS codebase (like I do by proxy, with my compiler), it is a regular occurrence that new releases of Chrome (and Firefox, to be fair) will knock parts of your code out of the JIT sweet spot and suddenly start optimizing other parts. Sometimes code that was fast becomes slow for no reason, other times some slow code becomes fast and now you look at profiles and realize you need to remove caching logic or that your code will be faster if you remove an optimization. The arms race never ends, and keeping up with it is a full-time job. asm.js fixes this, by precisely specifying the 'sweet spot' and giving you a guarantee that if you satisfy its requirements, all your code will be optimized, unless the VM is broken. This lets you build a compiler that outputs valid asm.js code, verify it, and leave it alone. These days I don't even have time to keep up with the constant performance failures introduced by new releases, but JSIL is a nearly two-year-old project now and they cropped up regularly the whole time. Ignoring the performance failures isn't an option because customers don't want slow applications (and neither do I).
- taf2 13y ago
  I know it's probably a little much to ask but do you have any examples of the types of performance regressions you experienced over the last few years within v8 that hit you the hardest?
  - kevingadd 13y ago
    The vast majority of them are cases where some code starts getting deopted by v8 and dropping into the low-performance interpreter-equivalent mode in the runtime. There are hundreds of ways to trigger this and the list changes regularly. In practice when it's big enough to demonstrate with a test case, the reports look like this: http://code.google.com/p/chromium/issues/detail?id=261468 http://code.google.com/p/chromium/issues/detail?id=261468 "It's slower than it used to be, I can't tell why." Part of the problem is that the profiling tools aren't precise or reliable enough to show you what got slower (in fact, opening them changes performance characteristics dramatically). So I end up having to attach a debugger and launch Chrome with special undocumented v8 flags to get it to dump things like traces of optimization attempts and failures, and then try to figure out what cryptic deoptimization causes like 'check-maps' mean in practice for my code. There have been a few specific cases where the VM started relying on particular characteristics of objects, and that caused my code to deopt. I remember that at some point it became the case that putting a method named 'apply' or 'call' on any object will cause calls to those methods to become incredibly slow in V8; for some reason at that time X.apply() and X.call() were special-cased to always assume that they were Function.apply or Function.call, so if they weren't the optimizer bailed out. Funnily enough, this also applied to Function.bind() - if you called .bind() on a function, the result would have special .apply() and .call() methods so using the result deoptimized your code. I don't know if they ever fixed that problem. I renamed all my methods to avoid it and removed most uses of Function.bind.
TheZenPsycho 13y ago
A point some people seem to be missing in this thread which I would like to emphasize is the value of predictable performance. It is true that a JIT is in principle, capable of all the same things as an AOT compiler. It is true, that improving the speed of a JIT is valuable. However, that all glosses over the fact that a JIT is a black box. If I am working on an application today that has a mysterious slowdown after running for about 80 seconds, the promise that won't happen in next year's browser release is of no use to me whatsoever. In fact, I would prefer the jit run at the same constant slow speed instead of starting out fast, giving a false sense of performance. I can OPTIMISE for that. I can work with that. I can't work with a JIT that can't decide how fast it's going to run, and why from release to release, from second to second. It's fine for most applications, but if I absolutely positively need to generate a frame at a constant fixed rate, an unpredictable JIT is a huge liability no matter how theoretically fast it can go on benchmarks. Stability trumps raw performance.
s-macke 13y ago
I made the same experience with my hand optimized asm.js code. http://s-macke.github.io/jor1k/ http://s-macke.github.io/jor1k/ It runs as fast as asm.js in Firefox. Chrome is optimizing it really well.

116 points by elisee 13y ago

http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html suggested that this would happen: > When I sit down and think about performance gains that asm.js-implementation OdinMonkey-style brings to the table I don’t see anything that would not be possible to achieve within a normal JIT compilation framework and thus simultaneously make human written and compiler generated output faster.

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.
    - 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.
jlongster 13y ago
This is great news, and most people knew that Chrome could close a lot of the gap and saw asm.js as a competitive push. The main goal seems to have worked. There is still a ways to go though before they are fully on par with Firefox. Note that one of the benchmarks is still far slower on Chrome, and there are still probably edge cases here and there that trigger slow JS in Chrome. The guarantee of asm.js that your code is ~2x slower than native is nice. Additionally, loading in massive amounts of asm.js in Firefox will be much faster in Firefox in the future when they optimize the parser for asm.js. All in all, these are very happy times. There are pros and cons to both approaches, but it's exciting to see how far it's going.
- anon1385 13y ago
  >The guarantee of asm.js that your code is ~2x slower than native is nice What? How did a couple of benchmarks that showed ~2x performance for a few tasks become a 'guarantee'? In some situations asm.js only takes twice as long to run your code, in others it takes 12 times as long[1] or even more[2]. [1] http://cdn.arstechnica.net/wp-content/uploads/2013/05/benchmark-game-native-v-openmp-v-asmjs.png http://cdn.arstechnica.net/wp-content/uploads/2013/05/benchm... [2] http://cdn.arstechnica.net/wp-content/uploads/2013/05/classic-native-v-optimized-v-asmjs.png http://cdn.arstechnica.net/wp-content/uploads/2013/05/classi...
  - azakai 13y ago
    Those are examples of native code using multiple processes or threads. The asm.js code compared to them did not use multiple processes (but it could have, using web workers), nor did it use threads (which are not available on the web). It's fair to say that for single-threaded code, asm.js has a very good chance of running at half the speed of native, or better. For multicore code, it depends on whether web workers make sense for that use case - if they do, it can still maintain the same performance compared to native. Otherwise, the web platform would need to consider adding some more low-level parallelism to JS. Such proposals exist and there is some discussion about them.
azakai 13y ago
I agree with mraleph that this is possible. But it has not happened yet: if you look at the slide linked to there, https://v8.googlecode.com/issues/attachment?aid=25990016000&name=asm-benchmarks.png&token=h4vTA5HJV-Lh78OlhdyF4312yuA%3A1381857693963&inline=1 https://v8.googlecode.com/issues/attachment?aid=25990016000&... you can see that on a few of those there is still a significant difference, for example on Lua (I filed an issue on that here http://code.google.com/p/v8/issues/detail?id=2873 http://code.google.com/p/v8/issues/detail?id=2873 ). In principle, a JIT can do anything an AOT compiler can (and more). In practice, the JITs in Chrome and Firefox have gotten close to what the asm.js AOT in Firefox can reach, but only on most benchmarks, not all. The AOT does give a fairly good guarantee of always running the code at a good speed, while the JITs depend on heuristics. In practice, this means that JITs can be tweaked to run any benchmark well, but they don't always do it out of the box, while the AOT far more often does do so. Again, JIT heuristics can be fixed and improved, I have no doubt about that. And JITs could be designed to rely less on heuristics, I am a strong believer in that as well. But neither of those has yet been proven. I hope they will, though :)
jerf 13y ago
The modern version of "sufficiently smart compiler" has become the "sufficiently smart JIT optimizer". Confidence remains as high as ever, but alas, it seems performance is doing the same thing, plateauing noticeably before reaching parity. It's hard to get over the fact that a JIT simply faces an uphill battle against an engine that starts by restricting you to a subset of the language; basically, you can assume both engines are being written by equally smart people, so you kind of have to expect that the one that takes the restrictions is going to have a long-term persistent advantage in practice, no matter how theoretically the other team could catch up. OdinMonkey still has all the JIT opportunities, but it has other opportunities too.

Danieru 13y ago

From what I understand writing fast javascript is hard because the engines are improving so fast no one knows what is fast yet. Thus asm.js is a promise to developers: "Stay within the subset and your javascript will be fast". Yet it never was "use asm" which made asm.js fast. It was the js engine. "use asm" carries symantical knowledge so a browser can warn if you break out of the subset. It also serves as a strong hint that should make the optimizer's easier. This is why I think asm.js is the future. Mozila does not need buy in from Google, or Apple, or MS. Instead developers can compile to asm.js and their code will run, and in time it will run faster. So in effect Chrome supports arm.js but they are not making a promise. I think it would be better for the internet if they made this promise.

eliben 13y ago
> Stay within the subset and your javascript will be fast You do realize that asm.js was not designed to be written by hand, don't you? It's a target for compilers. There are no bounds "to stay within" for hand-written JS which is still the vast majority of the code out there.
- Danieru 13y ago
  I do, which is why I said developers may "compile" their program into asm.js Even still someone has to write that compiler and they want to know what will be fast. I do not see many people writing asm.js by hand beyond optimizing vital sections.
camus2 13y ago
> Mozila does not need buy in from Google, or Apple, or MS. So why Chrome should buy from Firefox? why should they follow the asm.js spec ? Maybe it i the wrong answer to a real problem, javascript speed and its memory foodprint.Why not fix the problem at the source instead of creating a subset? not meant to be written by hand? Chrome approach seems better.
- Danieru 13y ago
  A fair question. I think it has parallels to Intel's itanium vs AMD's x64. I cannot pretend to know what is best in a perfect world. Yet I am willing to pretend to know what is the more practical way forward. Native Client is and was an interesting approach, but it requires buy in. Buy in which it was not getting, and it had several years to get said buy in. When asm.js got announced I can only saw I was shocked. asm.js is brilliant! Brilliant in the same way utf-8 is. It does not require heavy changes yet could bring 90% of the benefit. It does not require a new sandbox. It is cross-platform and cross-architecture!

k_bx 13y ago

I think this only states that asm.js or it's tests are far from perfect now.

cliffbean 13y ago

Getting the Citadel demo to run at 60fps is impressive. It means that V8 is "fast enough" to keep up with the video card on that application. However, the benchmarks at [0] clearly show that this is not the end of the story. The "workload0" runs measure startup time. All the other workloads show runtime performance, and V8 is still quite a ways behind. [0] http://arewefastyet.com/#machine=11&view=breakdown&suite=asmjs-apps http://arewefastyet.com/#machine=11&view=breakdown&suite=asm...

zobzu 13y ago
It's interesting to see how Firefox in these benchmarks is way, way faster than Chrome - quite a turn of things.

kevingadd 13y ago

Sadly V8's dev team has yet to address the other problem that "use asm" solves - falling out of JIT sweet spots due to broken heuristics. If you maintain a large machine-generated JS codebase (like I do by proxy, with my compiler), it is a regular occurrence that new releases of Chrome (and Firefox, to be fair) will knock parts of your code out of the JIT sweet spot and suddenly start optimizing other parts. Sometimes code that was fast becomes slow for no reason, other times some slow code becomes fast and now you look at profiles and realize you need to remove caching logic or that your code will be faster if you remove an optimization. The arms race never ends, and keeping up with it is a full-time job. asm.js fixes this, by precisely specifying the 'sweet spot' and giving you a guarantee that if you satisfy its requirements, all your code will be optimized, unless the VM is broken. This lets you build a compiler that outputs valid asm.js code, verify it, and leave it alone. These days I don't even have time to keep up with the constant performance failures introduced by new releases, but JSIL is a nearly two-year-old project now and they cropped up regularly the whole time. Ignoring the performance failures isn't an option because customers don't want slow applications (and neither do I).

taf2 13y ago
I know it's probably a little much to ask but do you have any examples of the types of performance regressions you experienced over the last few years within v8 that hit you the hardest?
- kevingadd 13y ago
  The vast majority of them are cases where some code starts getting deopted by v8 and dropping into the low-performance interpreter-equivalent mode in the runtime. There are hundreds of ways to trigger this and the list changes regularly. In practice when it's big enough to demonstrate with a test case, the reports look like this: http://code.google.com/p/chromium/issues/detail?id=261468 http://code.google.com/p/chromium/issues/detail?id=261468 "It's slower than it used to be, I can't tell why." Part of the problem is that the profiling tools aren't precise or reliable enough to show you what got slower (in fact, opening them changes performance characteristics dramatically). So I end up having to attach a debugger and launch Chrome with special undocumented v8 flags to get it to dump things like traces of optimization attempts and failures, and then try to figure out what cryptic deoptimization causes like 'check-maps' mean in practice for my code. There have been a few specific cases where the VM started relying on particular characteristics of objects, and that caused my code to deopt. I remember that at some point it became the case that putting a method named 'apply' or 'call' on any object will cause calls to those methods to become incredibly slow in V8; for some reason at that time X.apply() and X.call() were special-cased to always assume that they were Function.apply or Function.call, so if they weren't the optimizer bailed out. Funnily enough, this also applied to Function.bind() - if you called .bind() on a function, the result would have special .apply() and .call() methods so using the result deoptimized your code. I don't know if they ever fixed that problem. I renamed all my methods to avoid it and removed most uses of Function.bind.

TheZenPsycho 13y ago

A point some people seem to be missing in this thread which I would like to emphasize is the value of predictable performance. It is true that a JIT is in principle, capable of all the same things as an AOT compiler. It is true, that improving the speed of a JIT is valuable. However, that all glosses over the fact that a JIT is a black box. If I am working on an application today that has a mysterious slowdown after running for about 80 seconds, the promise that won't happen in next year's browser release is of no use to me whatsoever. In fact, I would prefer the jit run at the same constant slow speed instead of starting out fast, giving a false sense of performance. I can OPTIMISE for that. I can work with that. I can't work with a JIT that can't decide how fast it's going to run, and why from release to release, from second to second. It's fine for most applications, but if I absolutely positively need to generate a frame at a constant fixed rate, an unpredictable JIT is a huge liability no matter how theoretically fast it can go on benchmarks. Stability trumps raw performance.

s-macke 13y ago

I made the same experience with my hand optimized asm.js code. http://s-macke.github.io/jor1k/ http://s-macke.github.io/jor1k/ It runs as fast as asm.js in Firefox. Chrome is optimizing it really well.