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).

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. :)

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.

> 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.

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?

Have you enabled mouse-lock in chrome://flags ? It talks about this on the page, if you're curious.

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?

Just swap base e for base 10, and boom, twice the orders of magnitude.

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.

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 :)

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.

Theoretically, a c-compiler could produce self modifying code.

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.

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.

The term "native-like" means "with a responsive interface" these days.

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.

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).

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.

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?