Imagine: there is a paper discussing the techniques of weight lifting. Your complaint is that there are newer models of weights than those they lifted.
Newer processors don't just increase the performance of all programs equally. They have things like improved branch prediction, cache prefetching, better pipelining, and different cache sizes which can make a lot of performance optimizations that you get from C / C++ less relevant.
Except from the "most optimized C++ code" you have all sources of all benchmarks. Please try to run them on any newer x86/64 based processor and show us that the article conclusions don't hold. I'm not holding my breath though.
The parent commenter uses "improved branch prediction, cache prefetching, better pipelining, and different cache sizes" as a "mumbo-jumbo that can mean something different." I'm in the business, so I can tell you, most of the improvements give you just some "overall speedup" so that you can happily buy today's processor running on 3 GHz and be glad it's faster than almost a decade old P4 running on the same 3 GHz. Add to that that now you have a multi-core CPU and that you have to "clear" the paths to the cores in order to prevent them from slowing down one another and also to compensate the bigger delay introduced by more modern RAM technologies, which trade bigger delay for the possibility to feed more cores.
Then, measure the algorithms that run on one core, anyway, on the P4 and the latest Core iX. Your slow languages won't be faster than your fast ones just because the quoted changes were introduced to the processors in between.
Please note that I did not disagree with your conclusion - I agree that it probably won't make a difference. If it makes you feel better, I'll say it's a very high value of probably. But I'm in the business of performing systems experiments. Removing as many variables as possible is just good experimental design. If you want to know what the performance will be like on modern machines, then it's best to run on modern machines.
Dear lord, thank you for this bit of common sense.
It's actually quite hard to know what a given piece of code will do on a given microarchitecture even if on average it runs everything X% faster - you may find you're the bit of code that bites the big one and run X% slower on the new microarchitecture (e.g. you were depending on branch mispredicts being cheaper than they are) or suddenly your code runs way faster than competing codes (e.g. you're the superstar running 2X% faster because a sudden increase in ILP exposes that you've got a main loop full of independent operations).
Thought experiment: you are Intel and your new processor makes, who knows how, writing highly optimized C code unnecessary, since the speed up of some higher level languages (from now on Java or Scala) is bigger than the speed up of the highly optimized C code (in which the runtime of Java and Scala are implemented). Wouldn't you make the biggest announcement of the computing history? "With this new CPU, your sloppier written code is faster than a highly optimized code. Every programming assumption valid up to now isn't anymore!"
...oh, I think I see what you're saying. If you have hardware that can predict jump-to-pointer and not just jump-to-literal, that can make quite a difference in how well more dynamic languages / paradigms perform compared to more static ones. I was thinking more along the lines of languages giving programmers (the appearance of) the ability to tweak their code to take advantage of these things, and "don't bother, the compiler is smarter than you are".
Branch prediction and processor caches help all languages, and low level languages like C and C++ even more than dynamic languages. What I'm saying is that smart compilers are not in any way a substitute for branch prediction and processor caches, on the contrary: smart compilers are designed to take the best advantage of these features. And on the point why C and C++ are still relevant because of this: it's basically impossible to fully take advantage of e.g. processor caches in languages like Java and Ruby because you cannot fully influence how your data structures are laid out in memory. You can in C and C++. Sure, in theory smart compilers could do that for you, but in practice they don't. And the problem is so difficult that we probably get that in compilers working about as well as a human C/C++ programmer around the same time that we get strong AI.
I've programmed computers at a low level, and lifted weights for the past 21 years (and in fact, read some actual papers about weight lifting, and failed to make the aforementioned complaint). The Eleikos of today feel basically like the Yorks of yesteryear.
On the other hand, the processors of 2000 are quite a bit different to the processors of 2011, and anyone who thinks that they can prove that this is irrelevant to the experiment in question by pure reasoning (rather than experimentation) is a moron, plain and simple.
Having tracked individual embodiments of algorithms over architectures from the P4 to Sandy Bridge, I can assure you that tradeoffs between particular approaches on an given problem vary wildy based on changes in microarchitecture.
Overall, there's a steady improvement and perhaps these languages are all gaining exactly the same (despite a substantial improvement in effective ILP from P4 to Core 2)... but I don't know that for sure and neither do you, despite your sophomoric self-assurance.
If only they could do the experiments on a processor from the last 5-6 years...naturally someone else could do the work for them, but why bother?
