4 ms·

Newer processors don't just increase the performance of all programs equally. They have things like improved branch prediction, cache prefetching, better pipel

by jnhnum1 15y ago

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.

acqq 15y ago
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.
- scott_s 15y ago
  I agree that it probably won't make a difference. But good experiments remove as many of those probablys as possible.
  - acqq 15y ago
    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.
    - scott_s 15y ago
      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.
      - acqq 15y ago
        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!"
      - onan_barbarian 15y ago
        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).
tbrownaw 15y ago
Um, don't even semi-modern compilers optimize things well enough that most of those aren't particularly relevant already?
- jules 15y ago
  No, not at all. On the contrary, modern compilers make use of these things when deciding how to optimize.
  - tbrownaw 15y ago
    ...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".
    - jules 15y ago
      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.

by jnhnum1 15y ago

acqq 15y ago

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.

scott_s 15y ago
I agree that it probably won't make a difference. But good experiments remove as many of those probablys as possible.
- acqq 15y ago
  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.
  - scott_s 15y ago
    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.
    - acqq 15y ago
      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!"
    - onan_barbarian 15y ago
      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).

tbrownaw 15y ago

Um, don't even semi-modern compilers optimize things well enough that most of those aren't particularly relevant already?

jules 15y ago
No, not at all. On the contrary, modern compilers make use of these things when deciding how to optimize.
- tbrownaw 15y ago
  ...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".
  - jules 15y ago
    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.