4 ms·

This matches my experience with Zen in basically any generation. Once you've used all of the tricks and exhausted all of the memory and storage bandwidth, you'l

This matches my experience with Zen in basically any generation. Once you've used all of the tricks and exhausted all of the memory and storage bandwidth, you'll still have compute left. It's often faster to use one less core than you hit constraints at so that the processor can juggle them between cores to balance the thermal load as opposed to trying to keep it completely saturated.

tw1984 1y ago
this is very interesting. any chance you have more concrete stats or results? thanks
Sesse__ 1y ago
I had real code that ran with IPC > 6 on Zen 3; I think that's the first time I've seen a modern CPU _really_ be ALU-bound. :-) But it was very unusual, and when I vectorized it, it ran completely different.
- menaerus 1y ago
  Zen3 decode is 4-wide + 8 uOp cache, and dispatch backend is 6 uOps wide. Theoretically, it shouldn't be possible to have IPC larger than 6.
  - Sesse__ 1y ago
    I agree, the 6.02 or whatever I got was probably a perf monitoring artifact.
    - menaerus 1y ago
      It's interesting nonetheless. I wouldn't expect measuring such an IPC in the wild without having to craft the code in such an artificial way so that it hits that bound.
      - Sesse__ 1y ago
        Me neither, especially since it was rather branchy (though almost all of the branches were, obviously, easily predictable). It was dominated by simple AND/OR/TEST, though, which I guess can go into a bazillion ports. Perhaps instruction fusion somehow played into it?
        menaerus 1y ago
        Probably everything that there is including the instruction fusion, no decoding aka uop cache, ideal port dispatching, no data dependency etc. If it was a loop then perhaps even LSD.
        Sesse__ 1y ago
        It was a 20-way nested loop (!), but it probably spent all (>99%) of its time in a few of the depths. Pretty sure all of the actually executed code would fit into the LSD. Then I moved stuff into huge precalced arrays instead, and it became intensely memory bound. :-)
        menaerus 1y ago
        Yeah, it might be the LSD then, basically no frontend involved after the first loop iteration, and then no bottleneck in the backend as well. So, what did you end up having in the code? Ugly and fast or nice and slow? :)
        Sesse__ 1y ago
        It's essentially research code, so it's getting uglier and uglier and faster and faster :-) It has stuff like “if I remove this assert(), then Clang does something stupid and 30% of CPU time is spent stalling on this single instruction, so meh, leave it in”. It's not going to be maintained once it's done its computation job. (https://oeis.org/draft/A286874 https://oeis.org/draft/A286874 if you're curious.)

tw1984 1y ago

this is very interesting. any chance you have more concrete stats or results? thanks

Sesse__ 1y ago

I had real code that ran with IPC > 6 on Zen 3; I think that's the first time I've seen a modern CPU _really_ be ALU-bound. :-) But it was very unusual, and when I vectorized it, it ran completely different.

menaerus 1y ago
Zen3 decode is 4-wide + 8 uOp cache, and dispatch backend is 6 uOps wide. Theoretically, it shouldn't be possible to have IPC larger than 6.
- Sesse__ 1y ago
  I agree, the 6.02 or whatever I got was probably a perf monitoring artifact.
  - menaerus 1y ago
    It's interesting nonetheless. I wouldn't expect measuring such an IPC in the wild without having to craft the code in such an artificial way so that it hits that bound.
    - Sesse__ 1y ago
      Me neither, especially since it was rather branchy (though almost all of the branches were, obviously, easily predictable). It was dominated by simple AND/OR/TEST, though, which I guess can go into a bazillion ports. Perhaps instruction fusion somehow played into it?
      - menaerus 1y ago
        Probably everything that there is including the instruction fusion, no decoding aka uop cache, ideal port dispatching, no data dependency etc. If it was a loop then perhaps even LSD.
        Sesse__ 1y ago
        It was a 20-way nested loop (!), but it probably spent all (>99%) of its time in a few of the depths. Pretty sure all of the actually executed code would fit into the LSD. Then I moved stuff into huge precalced arrays instead, and it became intensely memory bound. :-)
        menaerus 1y ago
        Yeah, it might be the LSD then, basically no frontend involved after the first loop iteration, and then no bottleneck in the backend as well. So, what did you end up having in the code? Ugly and fast or nice and slow? :)
        Sesse__ 1y ago
        It's essentially research code, so it's getting uglier and uglier and faster and faster :-) It has stuff like “if I remove this assert(), then Clang does something stupid and 30% of CPU time is spent stalling on this single instruction, so meh, leave it in”. It's not going to be maintained once it's done its computation job. (https://oeis.org/draft/A286874 https://oeis.org/draft/A286874 if you're curious.)