Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Why are C/C++ so much faster than JIT'ed Javascript? Can't a subset of Javascript be converted to ASM.js JS that'll run around the same speed? loops, arrays, conditional statements, etc. Why does Javascript have to be so much slower?



C maps datatypes and actions to the underlying hardware, Javascript does not. C puts everything on the stack by default (cheap) while Javascript puts it in the heap (expensive). C uses copy semantics, while Javascript does not (fucks caches, but more importantly now you have to do two loads for each value you want to read).

Javascript is dynamically typed, and comes with eval, so that you can never really be sure what type x is (and therefore what binary code the processor should run), so you have to check and make allowances, which cost performance.

In C you always know the type of a variable so you can match + to either a float, double or integer addition at compiler time, in Javascript you have to (dynamically) check the type of both, possibly convert one or more and then either perform a float or integer addition or string concatenation.

I C you always know the size of all structs, and they can't change so allocating them is cheap and fast, whereas you have to create a hash table in Javascript and access the objects that way (which is a lot more expensive, and potentially you have to walk the chain of several objects due to usage of the prototype property).

The same thing goes for Arrays, in C they are a pointer, in Javascript they are far more complicated.


> C maps datatypes and actions to the underlying hardware, Javascript does not.

That's not entirely true. A lot of 8-bit microcontrollers, for example, do not have hardware support for arithmetic on 32-bit integers; nevertheless, C code using int32_t or uint32_t will compile just fine for those processors. This goes double for floats, if you'll pardon the completely unintentional pun.

It's a matter of degree, of course. C is still a lot closer to the metal than JS.


Great comparison, thanks.


Type safety basically. JITs can produce good code which performs very well, but it still must check that the data it has is of the type it expects. A good JIT may only check occasionally, but it still must check. asm.js can guarantee that its data's types cannot change through static analysis.


> Can't a subset of Javascript be converted to ASM.js JS that'll run around the same speed?

ASM.js code is a subset of javascript. The point is that they have defined a subset of javascript and a set of rules that, while it will run in a normal javascript engine, clearly indicates to the engine that if it supports it, it can do additional optimizations that could break things for "normal" javascript.

E.g. javascript doesn't have proper integers. Doing everything with floats is a performance killer, and for the JS engines to figure out when they can safely substitute integers is extremely hard without hints, so ASM.js specifies how to "fake" integers in a way that ensures the code will still work in standard JS engines (by using bitwise operators to coerce the value to integer values all over the place) while allowing an engine that knows about the ASM.js conventions to optimize the code further.

Nothing stops you from writing javascript code manually this way in the first place (apart from tedium), though it is admittedly a "workaround" to features in javascript that are incredibly hard to optimize well that would've been handled cleaner by language modifications.

The advantage of ASM.js is that the code still works in other JS engines, while if they'd started adding actual extensions to the language we'd be in portability hell for years.


>Why are C/C++ so much faster than JIT'ed Javascript? Can't a subset of Javascript be converted to ASM.js JS that'll run around the same speed? loops, arrays, conditional statements, etc. Why does Javascript have to be so much slower?

"So much slower"?

Perhaps you haven't been around this web scene for more than 5-6 years. JS is so much faster now it's not even funny. JS used to be in the "slow as molasses" category pre-2005.

Now it's like 10 times faster than Python for pure algorithmic code.


I'm asking to have C/C++ compared to JIT'ed Javascript. You are explaining how Javascript is so much faster than it used to be, and that it's 10x faster than Python. The fact that I mentioned JIT'ed Javascript should have given away that I understand Javascript's current performance.

If Javascript were fast enough, we wouldn't be looking for "4-10x" improvements with ASM.js and NaCL. Are we close to the limit of what can be done to improve Javascript performance? Perhaps another 2x?


>The fact that I mentioned JIT'ed Javascript should have given away that I understand Javascript's current performance.

Sure, but "understanding" is different than appreciating.

After all, a JIT is not some magic wand. If a language is very dynamic, memory hungry, less prone to optimizations, etc, JIT code will still be slower than C/C++. Plus, not everything in a JS program is getting JITed.

>Are we close to the limit of what can be done to improve Javascript performance?

With Javascript as it is, yes. Maybe some 2x at best. If we add type hints, contiguous storage, and frozen object guarantees though (some of which ES6 has, IIRC) that can be improved further.


JIT is pretty cool stuff. You can do stuff with it that you can't do with compiled langauges:

http://en.wikipedia.org/wiki/Escape_analysis

[Update] Adding this great read about Java vs C++ performance:

http://www.azulsystems.com/blog/cliff/2009-09-06-java-vs-c-p...


In theory yes. But in actual JITs you don't get that much off of them compared to compiled code.

I've never seen any actual JIT being faster than compiled C/C++/Ada/Fortran, except for isolated contrived benchmarks.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: