I sympathize with the author's dislike for C++ and while you can't argue that dynamic languages "could" at some point in the future be faster than C++, it's very unlikely to happen since one of the requirements for this kind of speed is for a language to be statically typed. Without type information, the compiler is left with very few options to optimize the generated code.
one of the requirements for this kind of speed is for a language to be statically typed
No, one of the requirements for static optimization is that a language be statically typed. It does not follow that there are no ways to make dynamic languages fast, just that they mostly have to use different techniques.
You need to make languages fast on both dimensions, static and dynamic. A dynamically typed language can only be optimized in one dimension, which is why they usually trail behind statically typed languages in performances (since those are optimized along both axes).
I've not seen anything like the dynamic-dispatch optimisations the Self team came up with in the 1990s done in C++, nor problem-domain optimisations expressed as macros as is often done in Lisps, nor the aggressive constant-propagation of closures and their eventual inlining that Factor does.
Perhaps some of them could be applied, but a highly complicated base language with extensive mutation semantics (including pointer aliasing) probably mean they'll be so limited in their applicable scope, and so difficult to implement, that it's not an attractive activity for C++ compiler writers...
Do you know Synthesis OS (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.4...). The author made the OS specialize (and thus optimize) system calls during runtime (or something like that, it's been a while since I read the paper). The techniques might me applicable in higher-level languages than the assembler used there.
Yeah! Synthesis is quite excellent. I've been interested in exploring using the FORTH model of easily-accessible-runtime-compiler in that sort of context...
Don't you mean statically bound? I think quite a few C++ programmers get into the mindset that once the program has compiled that's the end of the optimisation. It depends on the system that is being run, but if the system has a long runtime: ongoing optimisation may bring about better performance over time. This is particularly true given how many bad C++ programmers there are (which is partly down to the language learning curve).
Strict typing was mostly about trapping programming errors at compilation rather than runtime. Perhaps something despite all the effort C++ has struggled to improve defect count through typing (C++ systems often fail for far more obscure reasons, and the strict typing can cause hideous compile-time errors).
Comments
I sympathize with the author's dislike for C++ and while you can't argue that dynamic languages "could" at some point in the future be faster than C++, it's very unlikely to happen since one of the requirements for this kind of speed is for a language to be statically typed. Without type information, the compiler is left with very few options to optimize the generated code.
one of the requirements for this kind of speed is for a language to be statically typed
No, one of the requirements for static optimization is that a language be statically typed. It does not follow that there are no ways to make dynamic languages fast, just that they mostly have to use different techniques.
You need to make languages fast on both dimensions, static and dynamic. A dynamically typed language can only be optimized in one dimension, which is why they usually trail behind statically typed languages in performances (since those are optimized along both axes).
I've not seen anything like the dynamic-dispatch optimisations the Self team came up with in the 1990s done in C++, nor problem-domain optimisations expressed as macros as is often done in Lisps, nor the aggressive constant-propagation of closures and their eventual inlining that Factor does.
Perhaps some of them could be applied, but a highly complicated base language with extensive mutation semantics (including pointer aliasing) probably mean they'll be so limited in their applicable scope, and so difficult to implement, that it's not an attractive activity for C++ compiler writers...
Do you know Synthesis OS (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.4...). The author made the OS specialize (and thus optimize) system calls during runtime (or something like that, it's been a while since I read the paper). The techniques might me applicable in higher-level languages than the assembler used there.
Yeah! Synthesis is quite excellent. I've been interested in exploring using the FORTH model of easily-accessible-runtime-compiler in that sort of context...
However it seems dead. Anything new on Synthesis (and related ideas) in the last two decades?
Other than JIT recompilation in VMs of various kinds (which is only indirectly related), no, not that I know of...
Don't you mean statically bound? I think quite a few C++ programmers get into the mindset that once the program has compiled that's the end of the optimisation. It depends on the system that is being run, but if the system has a long runtime: ongoing optimisation may bring about better performance over time. This is particularly true given how many bad C++ programmers there are (which is partly down to the language learning curve).
Strict typing was mostly about trapping programming errors at compilation rather than runtime. Perhaps something despite all the effort C++ has struggled to improve defect count through typing (C++ systems often fail for far more obscure reasons, and the strict typing can cause hideous compile-time errors).
Ousterhout of Tcl fame has a very nice (and surprisingly old) paper about this. http://www.tcl.tk/doc/scripting.html