GCC vs Clang, which produces better code?

[lefticus]

This is a follow-up to the #26 issues that were reported with clang producing code 1/2 the speed of gcc.

[lefticus]

Various versions being tested is here:

https://github.com/lefticus/cpp_weekly/tree/master/parallel_algorithms

Data: https://github.com/lefticus/cpp_weekly/blob/master/parallel_algorithms/performance_stats.csv

So far it looks like the fact that I used signed indexes for some of the code resulted in clang losing its mind, which, if you know anything about the history of the "used signed for performance" stuff, should be rather ironic.

I also need to run callgrind tests against the different versions and see what shakes out.

[elbeno]

Related: Alex Dathskovsky's (https://www.youtube.com/@cppnext-alexd) talk "To Int or to Uint?" at CppNorth 2024, to be repeated at CppCon 2024 https://cppcon2024.sched.com/event/1gZg0/to-int-or-to-uint-this-is-the-question

[lefticus]

Notes:

• Back in Episode 435 (opencl / sycl / adaptivecpp #26) I noted that GCC was generating code that ran 2x faster than Clang. https://youtu.be/ImM7f5IQOaw
• I've spent the last 4 months off and on researching what was going on.
• This is a small project that all fits in one file. All of the stats collected are available in this link:

https://docs.google.com/spreadsheets/d/1NyOpRZq8w6pXXz9mdWE8HxIDfIRuAUyFFKK8sALIJ1c/edit?usp=sharing

These things are generally true from this research:

• On GCC -O1 is always faster than -O0, -O1 is always faster than -O2, -O3 is always faster than -02
• Despite what you may have heard about the value of -O3, in this code it was 100% of the time faster than -O2 in all comparisons, on GCC nearly 3x faster
• -march=native only had marginal improvement
• If you truly want the fastest binary, you need to test every optimization level for every compiler until you find the sweet spot for your code

Except for one case (which we'll get to) these things hold true:

• GCC is always faster than clang for -O0, -O2, -O3 (1.5-2x faster)
• Clang -O1 always beats GCC -O1
• Clang -O2 is always slower than Clang -O1

The change that made the biggest improvement on Clang was unpredictable and almost impossible to decipher what happened.

• When I first developed this project I decided to "optimize" the layout of my game of life map by choosing the smallest possible integral type that worked for the compile-time known dimensions I was using.
• If the grid was 100x100, then only a single byte was used for Width and Height (int8_t)
• If the grid was 1024x1024, then 2 bytes were used (int16_t)
• etc
• This should have helped with cache-friendly-ness right?
• After first I noticed Clang generating very different code in the presence of IO, so I removed all that and simplified it
• But that didn't show a significant difference
• Then I just started poking at things, randomly adding alwaysinline and moving things around.
• This did show a big difference
• Eventually I narrowed it down to this one tiny change: https://www.diffchecker.com/zBQnke71/
• Which causes clang to produce a binary so completely different that it's impossible for me to understand what's going on https://compiler-explorer.com/z/Pcav1dG6z

So which is faster?

• GCC is consistent, and very good
• Clang is faster if you hold its hand and tweak the code until you cast the right spell
• YMMV, IANAL, Consult your doctor, etc.

So your homework is to

• dig into what exactly is happening here.
• Signed/unsigned does not seem to be the issue, I've also messed with that.

[lefticus]

Coming in Ep460

[cor3ntin]

Did you report the issue? https://github.com/llvm/llvm-project/issues

[lefticus]

Did you report the issue? https://github.com/llvm/llvm-project/issues

I did not, for 2 reasons:

1. This is not something I could articulate as an issue succinctly ("in some weird cases, in this large chunk of code, clang decides to make code that is slower than gcc's code...?")
2. I have never once had a compiler bug report to clang, gcc, or MSVC be taken seriously by the developers, so I have stopped making compiler bug reports. (most common is the bug is ignored, second most common is that it's marked as fixed, when it is not fixed)

[guoci]

I have narrowed the cause to the floor_modulo function.

Link to my final version of the code: https://www.diffchecker.com/nAgBP2zA/

For the compact indexing version, if we change the type of divisor from auto to size_t, the performance can be on par with that of the size_t indexing version.

However, a bug was introduced in both the above refactor and the size_t indexing version.

In the floor_modulo function, if the dividend is a negative integer and the divisor is switched from a signed to an unsigned integer type, the result can be different due to implicit integer conversions.

int8_t{-1} % size_t{10} == 5;
int8_t{-1} % int64_t{10} == -1;

To fix that issue, I replace floor_modulo with:

[[nodiscard]] constexpr auto floor_modulo(auto dividend, size_t divisor) {
  dividend += divisor; // make dividend positive
  return dividend % divisor;
}

and prevent overflow with:

template<std::size_t value>
auto min_int() {
  if constexpr (2 * value <= std::numeric_limits<std::int8_t>::max()) {
    return std::int8_t{};
  } else if constexpr (2 * value <= std::numeric_limits<std::int16_t>::max()) {
    return std::int16_t{};
  } else if constexpr (2 * value <= std::numeric_limits<std::int32_t>::max()) {
    return std::int32_t{};
  } else {
    return std::int64_t{};
  }
}

We can also replace the use of floor_modulo with built-in modulo (for better performance) by changing neighbors to the following to make the dividend nonnegative:

  constexpr static std::array<Point, 8> neighbors{
    Point{width - 1, 0}, Point{1, 0},
    Point{width - 1, height - 1}, Point{0, height - 1}, Point{1, height - 1},
    Point{width - 1, 1}, Point{0, 1}, Point{1, 1}
  };

[guoci]

With my version of the code, I do not observe any difference in performance between GCC and Clang at -O3, but at -O2 GCC slows by 2x.

[lefticus]

With my version of the code, I do not observe any difference in performance between GCC and Clang at -O3, but at -O2 GCC slows by 2x.

Awesome, amazing work.

[pietrom16]

I would try with different data set sizes. I suspect that:

• Small data set, within the size of the cache, will be more performant with 64-bits data types, since you are using a 64 bits CPU.
• Large data set, beyond the size of the cache, may be more performant with smaller data types, since more data objects fit in the cache, requiring fewer RAM accesses.

The two compilers may utilize different optimization techniques in each case and for each optimization level.