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