Um every fast and decent JS engine IS WRITTEN IN C!!!
I refuse to click on anything as ridiculous sounding as "Faster than C? Parsing binary data in JavaScript".
JavaScript will NEVER be faster than C. If you personally test it and it is - all that you have really proven is that the C compiler you are using was horribly written and is probably 20+ years old. The level of ignorance that programmers have about low level languages and the performance cost of abstractions amazes me sometimes.
This is a very silly point of view. What you think you're arguing is that Javascript can't conceivably be faster than native code, and you're conflating C with native code. But C isn't machine code either; like Javascript, it's transformed into machine code by a compiler.
I don't generally think that Javascript runtimes are going to routinely beat C compilers for most performant execution of basic programs any time soon, but I'd happily bet that some high level language JIT is going to give C a real run for its money sometime soon. That JIT will inevitably be expressible in C, but when your recourse as a C programmer is "implement the important parts of the JIT for language X, then proceed to solve your real problem", you're not making much of a case for C.
I am not even close to conflating C with native code (although it is the lowest level language next to Assembly). C is the lowest level structured language and JS is among the highest. The fact that they are both ultimately compiled to a processor level binary means very little.
Since it seems so simple and plausible that a high level JITted language can be on par with C, why did you not explain how?
You cannot because you clearly don't understand language compilation and the laws that exist between performance and abstractions - so I am confused by your argument.
Let me put it simply, take any two languages - both ultimately compile to machine code, one has the overhead of bounds checking, run-time type resolution and garbage collection (there is actually much more that I could mention but for brevity...) and the other does not. Now please explain to me how the one WITH all this overhead could possibly be faster?
There is only one way - If the C compiler were egregiously under-optimized.
This will be the case till the end of time. All other things being equal, the executable code with more overhead to slow it down will lose. This seems a very simple concept to me - I cannot understand how it is so hard to grasp. Perhaps it is because along side learning Java, HTML and JavaScript - I also learned Assembly Language, C, C++ and hardware architectures.
This argument is tired, but I'll rebut it anyway. Yes, every performant JS engine is written in C, but that doesn't matter, even a little bit. When the code is compiled to machine code (as in V8) you're on a level playing field; all that matters is speed of compilation and how well the compiler performs.
If I write a C compiler in Python with the same optimizations as GCC, is the output any different? No.
So the argument has to be: there is something fundamental in JS that prevents it from being compiled to code as fast as C. That argument holds up for whole programs -- there are places where you just can't optimize JS greatly -- but if you're talking about specific bits of code, there's no reason it can't match (or surpass) C.
At the end of the day, JS can be quite fast, and the arguments against it don't hold up to scrutiny.
"there's no reason it can't match (or surpass) C."
No reason?, so run-time bounds checking, type checking/resolution and GC are free of charge then (as in no performance penalty)? Managed heap re/allocation are free? JITting is even free right? What about when the machine is low on virtual memory? can it compete them? how about when there is not an unoccupied processor core and ram channel available to be dedicated to a GC cycle? What about the context switches that exist on every non RTOS? and how this affects a stack based VM? A modern JS engine is heavily slowed by the stack/register abstraction that the VM utilizes when the machine has other tasks on hand.
How about that for some reasons? I am looking forward to your rebuttal... Tell me how doing more work can be faster please? There must be something I am missing here.
Sure there are great VMs that are blazing fast and are absolutely a sufficient tool for a large majority of tasks at hand - fine. I am just tired of the "fast as C" or "Faster than C" statements by those who appear to always feel slighted by the fact that their language is not fast as optimized C and the proclaimed (and false) expertise by users of such languages. They have no knowledge to back up their claims so instead of engaging in a discussion - they simply down vote with bitterness.
> No reason?, so run-time bounds checking, type checking/resolution and GC are free of charge then (as in no performance penalty)? Managed heap re/allocation are free? JITting is even free right? What about when the machine is low on virtual memory? can it compete them? how about when there is not an unoccupied processor core and ram channel available to be dedicated to a GC cycle? What about the context switches that exist on every non RTOS? and how this affects a stack based VM? A modern JS engine is heavily slowed by the stack/register abstraction that the VM utilizes when the machine has other tasks on hand.
All of these can be summed up simply: none of these things have to happen in the execution of JS code. None. They're implementation features.
Take this JS code:
function addfive(x) {
return x + 5;
}
var correct = addfive(3) == 8;
There is no need for garbage collection, it can be purely type inferred and compiled statically, and the object representations could be minimal (there's no reason it can't use tagged ints Ocaml-style).
Again, you're arguing that all JS code can't be as fast or faster than C. That's obviously true, but it has absolutely no value in the real world. What matters is that some code -- especially math-heavy code -- can be just as fast as C, because it compiles to the exact same thing.
I'm no JS fan, but I've spent a lot of time working on compilers for other "high-level languages". I can say, without a doubt, that C is not the be-all and end-all of programming languages.
This is a straw man argument. You are reducing the claims made by both sides here into a function that adds primitives REALLY?
You know full well that this is complete BS. Nothing meaningful(including the original blog post) can be done in JS and have the code emitted even come close to the compiled code of the C implementation of the same function. Sure a few bytes here and there MAY be the same and therefore execute in a similar amount of time (as long as a GC Cycle doesn't happen to run in the middle of it) - but it is ridiculous to even compare the two overall in this manner.
As for C not being the be-all and end-all of programming languages... Who ever made this claim? Personally - I don't even like using C. Are you trying to create a diversionary argument to make-up for the edge case you presented that MAY execute as fast as a C compiler output?
Please only reply with real challenges. Not edge cases.
I refuse to click on anything as ridiculous sounding as "Faster than C? Parsing binary data in JavaScript".
JavaScript will NEVER be faster than C. If you personally test it and it is - all that you have really proven is that the C compiler you are using was horribly written and is probably 20+ years old. The level of ignorance that programmers have about low level languages and the performance cost of abstractions amazes me sometimes.