5 ms·

JavaScript doesn't run at the speed of native, but it certainly runs fast enough on things like Fx OS (or desktop browsers) to run 'native-like' apps. It really

JavaScript doesn't run at the speed of native, but it certainly runs fast enough on things like Fx OS (or desktop browsers) to run 'native-like' apps. It really depends what you want to do with it. For example, this is JavaScript: https://developer.mozilla.org/en-US/demos/detail/bananabread https://developer.mozilla.org/en-US/demos/detail/bananabread

pkolaczk 14y ago
So how come e.g. www.circuitlab.com which is a simulator written in pure JS is two orders of magnitude slower on Chrome or Firefox than native *SPICE implementations in C? It is actually even much slower than the already pretty slow Falstad's Java applet.
- azakai 14y ago
  Two orders of magnitude? That can't be explained by the difference between C and JS. There must be some other difference, like which algorithms are used, or that the C one relies heavily on inline assembly or such. The expected difference between C and JS should be more like one order of magnitude in the worst cases (and much better in the best).
  - mbrubeck 14y ago
    Since azakai is too humble to mention his own qualifications, I want to point out that is the author of the Emscripten LLVM-to-JS compiler, and the BananaBread first-person-shooter demo linked above, so when he talks about the limits of JS performance compared to C, he really knows what he's talking about. :)
  - pkolaczk 14y ago
    Well, I could agree if I saw any computational-heavy JS application (and not a microbenchmark) doing well compared to native counterpart, especially on multicore. So far, I found only the one I cited - and the fact is, it is damn slow. While JIT is getting better over time, you are soon going to hit the law of diminishing returns - the JIT is already extremely sophisticated, but still being a few times slower on average even than JVM. And JVM has it much easier, because it has full explicit type information, while JS has to first figure it out. So I wouldn't expect miracles here.
    - azakai 14y ago
      > Well, I could agree if I saw any computational-heavy JS application (and not a microbenchmark) doing well compared to native counterpart, especially on multicore. For example, BananaBread compiles 120,000 lines of code of a C++ 3D game engine, including AI and physics and so forth. It also uses 3 cores during startup processing The difference between JavaScript and C++ is less than one order of magnitude, and note that this is a hard case to optimize for JS engines since LLVM inlining creates huge functions that JS engines just give up on optimizing currently. So that the game ends up still running as fast as it does in JS is a nice surprise. There are also lots of other compiled examples of real-world code, like Box2D and Bullet. Typically the speed of JS compared to C is 5X-10X slower, again, much of it because of large functions not being fully optimized.
  - mtgx 14y ago
    If you're working on Bananabread, can you check why it's not working on Chrome, the latest stable version? I get an Oops message. I use Windows 7 x64, Core i7 laptop with Nvidia 555m GT .Also just installed Nvidia's latest driver, though I haven't rebooted yet. Could that be it?
    - azakai 14y ago
      I am aware of a bug in Chrome where the Chrome tab will crash after you play for a while or reload the tab. But in a new tab you should be able to play for a few seconds ok - is that what you are experiencing?
    - nightpool 14y ago
      Have you enabled mouse-lock in chrome://flags ? It talks about this on the page, if you're curious.
  - Evbn 14y ago
    Just swap base e for base 10, and boom, twice the orders of magnitude.
- nemetroid 14y ago
  The term "native-like" means "with a responsive interface" these days.
  - pkolaczk 14y ago
    Oh yeah, by this definition interpreted Python is also native like. Just do all your UI rendering by native libs and use scripting to glue it together. But this is not what most of programmers call native speed.
    - buu700 14y ago
      I think you're misinterpreting the meaning of 'native' in this context; the tradeoff in question isn't one of interpreted/JIT'd v. ahead of time to the metal, but rather one of Web v. every platform's standard graphical application stack(s) (which may or may not be ahead of time compiled).
    - signalsignal 14y ago
      Hence the context of being magical. It is more of a sleight of hand trick than actual supernatural. The author of the post is misusing a development term to convey a different meaning.
  - mburns 14y ago
    And access to hardware, and with a common, system interface (native widgets) not custom or third-party UI widgets. Seems like a completely accurate definition. As responsive as expected, similar looking and integrated as expected, and able to access the unique parts of my phone. What is missing, other than having a different build/compile process?
- dangoor 14y ago
  Well-optimized C is likely to always be faster than well-optimized JavaScript. It is also possible that circuitlab is not well-optimized JavaScript. I will say that it also depends on the problem domain. You can make a fast 3D game in JavaScript because WebGL does hardware acceleration of the graphics. You can also make a fast todo list in JavaScript because, well, it's a todo list :)
  - Joeri 14y ago
    I don't think C will always be faster. A JIT-compiled language can theoretically be optimized better than a precompiled binary, because the JIT engine can recompile hot code based on observed behavior on the actual system with the actual data.
    - im3w1l 14y ago
      Theoretically, a c-compiler could produce self modifying code.
      - wisty 14y ago
        Also, this theoretical c compiler could make use of implicit hints (like which variables to place together in memory), making it faster than JS (except asymptotically, when the JIT has run long enough to figure everything out). But the original point is basically right - one day JITs will be faster.
        pkolaczk 14y ago
        JITs don't have so much time to optimize, as static compilers do. Therefore, they can't do e.g. whole program analysis, or expensive cache related optimizations. Despite 15 years of effort of speeding up JVM, it is still slower in general than optimized C. Not by much (usually good Java code runs within a 2x slower margin), but still - it can't beat static compilers.
- grayrest 14y ago
  In addition to the responses from the Mozilla guys, I'll also point out that the limiting factor in speed for most web applications is not javascript runtime speed but dom manipulation, reflow, and repaint. The tricks for optimizing these tend to be somewhat browser dependent and not generally known by the web development community.

pkolaczk 14y ago

So how come e.g. www.circuitlab.com which is a simulator written in pure JS is two orders of magnitude slower on Chrome or Firefox than native *SPICE implementations in C? It is actually even much slower than the already pretty slow Falstad's Java applet.

azakai 14y ago
Two orders of magnitude? That can't be explained by the difference between C and JS. There must be some other difference, like which algorithms are used, or that the C one relies heavily on inline assembly or such. The expected difference between C and JS should be more like one order of magnitude in the worst cases (and much better in the best).
- mbrubeck 14y ago
  Since azakai is too humble to mention his own qualifications, I want to point out that is the author of the Emscripten LLVM-to-JS compiler, and the BananaBread first-person-shooter demo linked above, so when he talks about the limits of JS performance compared to C, he really knows what he's talking about. :)
- pkolaczk 14y ago
  Well, I could agree if I saw any computational-heavy JS application (and not a microbenchmark) doing well compared to native counterpart, especially on multicore. So far, I found only the one I cited - and the fact is, it is damn slow. While JIT is getting better over time, you are soon going to hit the law of diminishing returns - the JIT is already extremely sophisticated, but still being a few times slower on average even than JVM. And JVM has it much easier, because it has full explicit type information, while JS has to first figure it out. So I wouldn't expect miracles here.
  - azakai 14y ago
    > Well, I could agree if I saw any computational-heavy JS application (and not a microbenchmark) doing well compared to native counterpart, especially on multicore. For example, BananaBread compiles 120,000 lines of code of a C++ 3D game engine, including AI and physics and so forth. It also uses 3 cores during startup processing The difference between JavaScript and C++ is less than one order of magnitude, and note that this is a hard case to optimize for JS engines since LLVM inlining creates huge functions that JS engines just give up on optimizing currently. So that the game ends up still running as fast as it does in JS is a nice surprise. There are also lots of other compiled examples of real-world code, like Box2D and Bullet. Typically the speed of JS compared to C is 5X-10X slower, again, much of it because of large functions not being fully optimized.
- mtgx 14y ago
  If you're working on Bananabread, can you check why it's not working on Chrome, the latest stable version? I get an Oops message. I use Windows 7 x64, Core i7 laptop with Nvidia 555m GT .Also just installed Nvidia's latest driver, though I haven't rebooted yet. Could that be it?
  - azakai 14y ago
    I am aware of a bug in Chrome where the Chrome tab will crash after you play for a while or reload the tab. But in a new tab you should be able to play for a few seconds ok - is that what you are experiencing?
  - nightpool 14y ago
    Have you enabled mouse-lock in chrome://flags ? It talks about this on the page, if you're curious.
- Evbn 14y ago
  Just swap base e for base 10, and boom, twice the orders of magnitude.
nemetroid 14y ago
The term "native-like" means "with a responsive interface" these days.
- pkolaczk 14y ago
  Oh yeah, by this definition interpreted Python is also native like. Just do all your UI rendering by native libs and use scripting to glue it together. But this is not what most of programmers call native speed.
  - buu700 14y ago
    I think you're misinterpreting the meaning of 'native' in this context; the tradeoff in question isn't one of interpreted/JIT'd v. ahead of time to the metal, but rather one of Web v. every platform's standard graphical application stack(s) (which may or may not be ahead of time compiled).
  - signalsignal 14y ago
    Hence the context of being magical. It is more of a sleight of hand trick than actual supernatural. The author of the post is misusing a development term to convey a different meaning.
- mburns 14y ago
  And access to hardware, and with a common, system interface (native widgets) not custom or third-party UI widgets. Seems like a completely accurate definition. As responsive as expected, similar looking and integrated as expected, and able to access the unique parts of my phone. What is missing, other than having a different build/compile process?
dangoor 14y ago
Well-optimized C is likely to always be faster than well-optimized JavaScript. It is also possible that circuitlab is not well-optimized JavaScript. I will say that it also depends on the problem domain. You can make a fast 3D game in JavaScript because WebGL does hardware acceleration of the graphics. You can also make a fast todo list in JavaScript because, well, it's a todo list :)
- Joeri 14y ago
  I don't think C will always be faster. A JIT-compiled language can theoretically be optimized better than a precompiled binary, because the JIT engine can recompile hot code based on observed behavior on the actual system with the actual data.
  - im3w1l 14y ago
    Theoretically, a c-compiler could produce self modifying code.
    - wisty 14y ago
      Also, this theoretical c compiler could make use of implicit hints (like which variables to place together in memory), making it faster than JS (except asymptotically, when the JIT has run long enough to figure everything out). But the original point is basically right - one day JITs will be faster.
      - pkolaczk 14y ago
        JITs don't have so much time to optimize, as static compilers do. Therefore, they can't do e.g. whole program analysis, or expensive cache related optimizations. Despite 15 years of effort of speeding up JVM, it is still slower in general than optimized C. Not by much (usually good Java code runs within a 2x slower margin), but still - it can't beat static compilers.
grayrest 14y ago
In addition to the responses from the Mozilla guys, I'll also point out that the limiting factor in speed for most web applications is not javascript runtime speed but dom manipulation, reflow, and repaint. The tricks for optimizing these tend to be somewhat browser dependent and not generally known by the web development community.