3 ms·

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 tha

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

by azakai 14y ago

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.