Why dep_chains_2 becomes slower when enabling slp-vectorize?

[mapleFU]

Thanks for the book!

When I'm reading chapter9 "Optimizing Computations", I found the cmake disable slp via "-fno-slp-vectorize", since it disable breaking a dependency chain. I've run the benchmark in my machine, and find slp makes the code with two RNGs becoming slower.

I also tried the godbolt ( https://godbolt.org/z/5oGrcvKec ), and it shows that the slp has few uOps and can execute faster, but I cannot fully understand the reason, why it would make it slower? Is it due to stress on vectorize unit?

The referenced code I used is listed below, I'm running on my MacOS M1Pro with clang-18

With slp-vectorize enabled:

1. When STRIDE = 2, the randomParticleMotion runs 2200ns per loop, and randomParticleMotionOrigin spend 1900ns
2. When STRIDE = 16, the randomParticleMotion runs 600ns per loop

With slp-vectorize disabled:

1. When STRIDE = 2, the randomParticleMotion runs 1020ns per loop, and randomParticleMotionOrigin spend 1900ns
2. When STRIDE = 16, the randomParticleMotion runs 600ns per loop

So I guess this is another kind of dependency problem in SIMD?

// Simulate the motion of the particles.
// For every particle, we generate a random angle and move the particle
// in the corresponding direction.
template <class RNG>
void randomParticleMotion(std::vector<Particle> &particles, uint32_t seed) {
    constexpr int32_t STRIDE = 2;
    std::array<RNG, STRIDE> rng_arr = make_array_same_ctor<RNG, STRIDE>(seed);
  for (int i = 0; i < STEPS; i++)
  {
    auto count_rng = [](RNG& rng, Particle& p)
    {
      uint32_t angle = rng.gen();
      float angle_rad = angle * DEGREE_TO_RADIAN;
      p.x += cosine(angle_rad) * p.velocity;
      p.y += sine(angle_rad) * p.velocity;
    };
    size_t idx = 0;
    for (;idx < particles.size(); idx += STRIDE)
    {
      for (int i = 0; i < STRIDE; i++)
      {
        count_rng(rng_arr[i], particles[idx + i]);
      }
    }
    // Trailer
    for (size_t i = 0;idx + i < particles.size(); i += 1)
    {
      count_rng(rng_arr[i], particles[idx + i]);
    }
  }
}

template <class RNG>
void randomParticleMotionOrigin(std::vector<Particle> &particles, uint32_t seed) {
  RNG rng(seed);
  for (int i = 0; i < STEPS; i++)
  {
    auto count_rng = [](RNG& rng, Particle& p)
    {
      uint32_t angle = rng.gen();
      float angle_rad = angle * DEGREE_TO_RADIAN;
      p.x += cosine(angle_rad) * p.velocity;
      p.y += sine(angle_rad) * p.velocity;
    };
    size_t idx = 0;
    for (;idx < particles.size(); idx += 1)
    {
      count_rng(rng, particles[idx]);
    }
  }
}

[0legmak]

On my local hardware I don't see any benefit from "-fno-slp-vectorize", it actually makes things run slower (maybe because -O3 is also disabled). Could be related to the fact that I use lang 19 instead of 17. I've just tried to commit change that removes -fno-slp-vectorize and re-enables -O3 but it appears that official benchmarks are currently broken.
Do you have a private branch with a solution I could test?

[mapleFU]

I guess this is only on macos or arm machines, the godbolt shows enabling "-fno-slp-vectorize" would have less IPC and more uOps. See the https://godbolt.org/z/5oGrcvKec

Seems on my AMD 3800X with gcc14, the "-fno-slp-vectorize" only affects little. You can also see my function randomParticleMotion and test different STRIDE for it?

[mapleFU]

Also it's disabled here:

perf-ninja/labs/core_bound/dep_chains_2/CMakeLists.txt

Line 6 in 6785d21

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-slp-vectorize")

[dendibakh]

Hello @mapleFU and @0legmak, and thank you for running some experiments. It's been a couple of years since I developed the benchmark so I don't remember all the details. I also ran it on M1.
AFAIR, the SLP vectorization did its job very cleanly, but now I cannot quickly understand what it's doing by reading the asm output. Will try to look over the weekend.