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