Why gcc's code is so much slower than clang's?

Why gcc's code is so much slower than clang's?

[Georg-Johann Lay]

For the C code below, I am getting execution times of around 8 to 8.3
seconds with gcc (v11.3 and v13.2) and around 5 seconds with clang v17.

Only options I used were -O3 (-Os or -Ofast didn't make a difference).

Architecture is x86_64-linux-gnu, Dual Core Intel Core2

I ran the code below with

 > gcc coll.c -o coll.x -O3 && time -p ./coll.x

I wouldn't ask this question if I hadn't observed similar thing
with other programs already, any I am wondering if I am missing
something crucial like supplying GCC with better options?

After all, it's that GCC's code is 60% (or more) slower than clang's.

I'd guess +-5% is well in the range of noise, but +60% or more ???

Johann

---

C99 Code:


#include <inttypes.h>
#include <stdio.h>
#include <stdlib.h>

uint32_t coll (uint64_t i)
{
     for (uint32_t n = 0; ; ++n)
     {
         if (i == 1)
             return n;

         if (i > UINT64_MAX / 3 - 3)
         {
             fprintf (stderr, "%" PRIu64 " = %" PRIx64 " too big\n", i, i);
             exit (1);
         }

         i = (i & 1)
             ? (3 * i + 1) >> 1
             : i >> 1;
     }
}

int main (void)
{
     uint64_t n  = 0x1000000;
     uint64_t i0 = 0x2000000;
     uint32_t max_it = 0;

     for (uint64_t i = i0; i <= i0 + n; ++i)
     {
         uint32_t it = coll (i);
         if (it > max_it)
         {
             printf ("%" PRIu64 ": %" PRIu32 "\n", i, it);
             max_it = it;
         }
     }

     return 0;
}

Re: Why gcc's code is so much slower than clang's?

[Alexander Monakov]

On Mon, 23 Oct 2023, Georg-Johann Lay wrote:

> For the C code below, I am getting execution times of around 8 to 8.3
> seconds with gcc (v11.3 and v13.2) and around 5 seconds with clang v17.
> 
> Only options I used were -O3 (-Os or -Ofast didn't make a difference).
> 
> Architecture is x86_64-linux-gnu, Dual Core Intel Core2
> 
> I ran the code below with
> 
> > gcc coll.c -o coll.x -O3 && time -p ./coll.x
> 
> I wouldn't ask this question if I hadn't observed similar thing
> with other programs already, any I am wondering if I am missing
> something crucial like supplying GCC with better options?

In this specific program, Clang translates

    i = (i & 1)
        ? (3 * i + 1) >> 1
        : i >> 1;

into a straight-line code involving a conditional move, while GCC
emits a conditional branch. That branch turns out to be poorly
predictable, causing GCC-compiled program to run slower, even though
it executes much fewer instructions (~13 billion vs ~20 billion).

(I used 'perf stat' to obtain the instruction counts)

For other programs the cause of disparity may be different.

Alexander

Re: Why gcc's code is so much slower than clang's?

[David Brown]

On 23/10/2023 15:30, Georg-Johann Lay wrote:
> For the C code below, I am getting execution times of around 8 to 8.3
> seconds with gcc (v11.3 and v13.2) and around 5 seconds with clang v17.
> 
> Only options I used were -O3 (-Os or -Ofast didn't make a difference).
> 
> Architecture is x86_64-linux-gnu, Dual Core Intel Core2
> 
> I ran the code below with
> 
>  > gcc coll.c -o coll.x -O3 && time -p ./coll.x
> 
> I wouldn't ask this question if I hadn't observed similar thing
> with other programs already, any I am wondering if I am missing
> something crucial like supplying GCC with better options?
> 
> After all, it's that GCC's code is 60% (or more) slower than clang's.
> 
> I'd guess +-5% is well in the range of noise, but +60% or more ???
> 
> Johann

The only noticeable difference I saw in the generated assembly with a 
quick test on godbolt is that clang uses a conditional move to implement 
the ternary expression, while gcc uses a conditional branch.  The 
branching here might be overwhelming the speculative execution - after 
all, it is not a very predictable expression (or there'd be no point in 
your program).

If my speculative theory is correct, I don't know how to encourage gcc 
to generate a cmove here - perhaps giving it more information about the 
actual target processor with "-march=native" will improve the choice of 
instructions.

But if you are hoping to find a counterexample to the Collatz 
conjecture, you'll need to move to "unsigned __uint128", since it's been 
checked up to about 2 ** 68 :-)

mvh.,

David




> 
> ---
> 
> C99 Code:
> 
> 
> #include <inttypes.h>
> #include <stdio.h>
> #include <stdlib.h>
> 
> uint32_t coll (uint64_t i)
> {
>      for (uint32_t n = 0; ; ++n)
>      {
>          if (i == 1)
>              return n;
> 
>          if (i > UINT64_MAX / 3 - 3)
>          {
>              fprintf (stderr, "%" PRIu64 " = %" PRIx64 " too big\n", i, i);
>              exit (1);
>          }
> 
>          i = (i & 1)
>              ? (3 * i + 1) >> 1
>              : i >> 1;
>      }
> }
> 
> int main (void)
> {
>      uint64_t n  = 0x1000000;
>      uint64_t i0 = 0x2000000;
>      uint32_t max_it = 0;
> 
>      for (uint64_t i = i0; i <= i0 + n; ++i)
>      {
>          uint32_t it = coll (i);
>          if (it > max_it)
>          {
>              printf ("%" PRIu64 ": %" PRIu32 "\n", i, it);
>              max_it = it;
>          }
>      }
> 
>      return 0;
> }
> 

Re: Why gcc's code is so much slower than clang's?

[Xi Ruoyao]

On Mon, 2023-10-23 at 17:27 +0300, Alexander Monakov wrote:
> 
> On Mon, 23 Oct 2023, Georg-Johann Lay wrote:
> 
> > For the C code below, I am getting execution times of around 8 to
> > 8.3
> > seconds with gcc (v11.3 and v13.2) and around 5 seconds with clang
> > v17.
> > 
> > Only options I used were -O3 (-Os or -Ofast didn't make a
> > difference).
> > 
> > Architecture is x86_64-linux-gnu, Dual Core Intel Core2
> > 
> > I ran the code below with
> > 
> > > gcc coll.c -o coll.x -O3 && time -p ./coll.x
> > 
> > I wouldn't ask this question if I hadn't observed similar thing
> > with other programs already, any I am wondering if I am missing
> > something crucial like supplying GCC with better options?
> 
> In this specific program, Clang translates
> 
>     i = (i & 1)
>         ? (3 * i + 1) >> 1
>         : i >> 1;
> 
> into a straight-line code involving a conditional move, while GCC
> emits a conditional branch. That branch turns out to be poorly
> predictable, causing GCC-compiled program to run slower, even though
> it executes much fewer instructions (~13 billion vs ~20 billion).
> 
> (I used 'perf stat' to obtain the instruction counts)

GCC even uses branch instead of cmov for:

int test(int x)
{
	return x & 1 ? 3 * x + 1 : x / 2;
}

Should we create a ticket in bugzilla or is there some reason not to use
cmov here?

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University

Re: Why gcc's code is so much slower than clang's?

[Alexander Monakov]

On Mon, 23 Oct 2023, Xi Ruoyao via Gcc-help wrote:

> GCC even uses branch instead of cmov for:
> 
> int test(int x)
> {
> 	return x & 1 ? 3 * x + 1 : x / 2;
> }
> 
> Should we create a ticket in bugzilla or is there some reason not to use
> cmov here?

There's a long-standing problem that RTL if-conversion passes do not emit
important information such as estimated costs and attempted transforms,
so it's impossible to say if it's "working as designed" without gdb'ing
the compiler. I suspect something is not working as it should on this
example.

In general:

For predictable branches, cmov can stitch computations into one long
dependency chain, making the resulting code latency-bound. For unpredictable
branches, cmov avoids the costs resulting from mispredictions.

The compiler cannot tell if a branch is going to be well-predictable or not.
My view is that compilers should offer __builtin_branchless_select so people
can express what they need. So far it didn't happen. LLVM offers
__builtin_unpredictable, which in my eyes is just an indirect way to request
branchless code.

Alexander