4 ms·

"the comparison is still flawed because it doesn’t matter if Intel can do more instruction per cycle if AMD can produce more cycles in a span of wall time." Th

"the comparison is still flawed because it doesn’t matter if Intel can do more instruction per cycle if AMD can produce more cycles in a span of wall time." The reason Intel had the "per core" superiority crown for years is that it had a better IPC performance due to design efficiency. Both manufacturers are pushing against the same frequency ceiling, so if you went AMD you had to significantly increase the core count to catch up, and could never match the still important single-thread performance. We know from large scale, comprehensive benchmarks that AMD has massively picked up the pace and is neck and neck with Intel. At the same processor speed it matches the best Intel processors. But yeah, this article is just terrible. Not just tiny, minuscule, extremely myopic benchmarks, but then a gross over-reach with conclusions. And in the way that ignorance begets ignorance, the fact that it's trending on a couple of social news sites means that now Google is surfacing it as canonical information when it's just a junk, extremely lazy analysis.

api 7y ago
> surfacing it as canonical information when it's just a junk, extremely lazy analysis. Isn't that what the Internet is for?
Tempest1981 7y ago
He ran a few basic tests, and showed the results. Where was the "gross over-reach"? The article ends with a "your mileage may vary" disclaimer.
- endorphone 7y ago
  "So AMD runs at 2/3 the IPC of an old Intel processor. That is quite poor!" That is most certainly an overreach. An extraordinary overreach. Worse, it's absurdly using an AVX2 codebase, optimized for Westmere, as the baseline for "IPC" testing? The premise itself borders of gross negligence. IPC as a generalized concept is a broad, general purpose set of instructions, not an absurdly narrow test. Saying "Intel is faster at AVX512" is going to surprise exactly no one, and also happens to be irrelevant for the overwhelming majority of users and uses. The microbenchmarking thing has gone on for years, and at this point anyone who has paid any attention is rightly cautious when stomping their feet and making declarations, because usually they're just pouring noise into the mix. Lazily running a couple of tiny tests is not the rigour to avoid deserved criticism.
  - BeeOnRope 7y ago
    I'm not sure if you were implying it or just using it as example of another type of unhelpful claim, but this test does not involve AVX-512. I agree using Westmere isn't necessarily the best approach, but there is no difference in this case with either -march=native or -march=znver1. The loop is small and simple, with only 9 instructions and compiles more or less the same regardless of march setting (I observed some basically no-op changes such as a mov and blsr swapping places). Here's the assembly (for the second test, with the bigger IPC gap): top: tzcnt r8,rcx add r8d,edx mov DWORD PTR [rdi+rax*4],r8d mov eax,DWORD PTR [rsi] inc eax blsr rcx,rcx mov DWORD PTR [rsi],eax jne .top
    - endorphone 7y ago
      "I'm not sure if you were implying it or just using it as example of another type of unhelpful claim, but this test does not involve AVX-512." Even worse! Is this a defense, because it's remarkably unhelpful as one. The blog post was clearly a cry for attention for some project -- let's just use some clickbait IPC claims to gain it -- and continually alluded to a whole project -- an extreme niche project that still wouldn't have any relevance. But instead it's a meaningless, completely misrepresentative micro-loop.
      - BeeOnRope 7y ago
        My read is different than yours. I think Daniel uses those examples because they are actual examples from projects that he is or has been working on, and he's familiar with them and actually cares about them, and because it's at least a notch more realistic than something totally synthetic. It seems like a very roundabout thing to use as a cry for attention for SIMDjson (the project I assume you are talking about), and I don't believe that's the purpose. I see no problem in linking the project. Picking two random benchmarks and trying to extract any kind of more general IPC claim is not on solid ground, but I'm pretty sure Daniel will say he's not doing that: he's only sharing these two specific results. That's a style that reoccurs across several entries in that blog, however, so if it triggers (as it has me on occasion) you might want to look elsewhere.

api 7y ago

> surfacing it as canonical information when it's just a junk, extremely lazy analysis. Isn't that what the Internet is for?

Tempest1981 7y ago

He ran a few basic tests, and showed the results. Where was the "gross over-reach"? The article ends with a "your mileage may vary" disclaimer.

endorphone 7y ago
"So AMD runs at 2/3 the IPC of an old Intel processor. That is quite poor!" That is most certainly an overreach. An extraordinary overreach. Worse, it's absurdly using an AVX2 codebase, optimized for Westmere, as the baseline for "IPC" testing? The premise itself borders of gross negligence. IPC as a generalized concept is a broad, general purpose set of instructions, not an absurdly narrow test. Saying "Intel is faster at AVX512" is going to surprise exactly no one, and also happens to be irrelevant for the overwhelming majority of users and uses. The microbenchmarking thing has gone on for years, and at this point anyone who has paid any attention is rightly cautious when stomping their feet and making declarations, because usually they're just pouring noise into the mix. Lazily running a couple of tiny tests is not the rigour to avoid deserved criticism.
- BeeOnRope 7y ago
  I'm not sure if you were implying it or just using it as example of another type of unhelpful claim, but this test does not involve AVX-512. I agree using Westmere isn't necessarily the best approach, but there is no difference in this case with either -march=native or -march=znver1. The loop is small and simple, with only 9 instructions and compiles more or less the same regardless of march setting (I observed some basically no-op changes such as a mov and blsr swapping places). Here's the assembly (for the second test, with the bigger IPC gap): top: tzcnt r8,rcx add r8d,edx mov DWORD PTR [rdi+rax*4],r8d mov eax,DWORD PTR [rsi] inc eax blsr rcx,rcx mov DWORD PTR [rsi],eax jne .top
  - endorphone 7y ago
    "I'm not sure if you were implying it or just using it as example of another type of unhelpful claim, but this test does not involve AVX-512." Even worse! Is this a defense, because it's remarkably unhelpful as one. The blog post was clearly a cry for attention for some project -- let's just use some clickbait IPC claims to gain it -- and continually alluded to a whole project -- an extreme niche project that still wouldn't have any relevance. But instead it's a meaningless, completely misrepresentative micro-loop.
    - BeeOnRope 7y ago
      My read is different than yours. I think Daniel uses those examples because they are actual examples from projects that he is or has been working on, and he's familiar with them and actually cares about them, and because it's at least a notch more realistic than something totally synthetic. It seems like a very roundabout thing to use as a cry for attention for SIMDjson (the project I assume you are talking about), and I don't believe that's the purpose. I see no problem in linking the project. Picking two random benchmarks and trying to extract any kind of more general IPC claim is not on solid ground, but I'm pretty sure Daniel will say he's not doing that: he's only sharing these two specific results. That's a style that reoccurs across several entries in that blog, however, so if it triggers (as it has me on occasion) you might want to look elsewhere.