Обсуждение: PostgreSQLv14 TPC-H performance GCC vs Clang

Hi 

PostgreSQLv14 source code build  with GCCv11.2 and Clangv12(without JIT) with  optimisation flags like O3 and tested with HammerDB

Observed TPC-H , GCC performance better than Clang(without JIT). The performance difference ~22% and also noticed the assembly code difference GCC vs Clang( e.g. GCC inlined functionality compared to Clang). 

Environment details:

————————-

OS :RHEL8.4

Bare metal : Apple/AMD EPYC/IBM

Test(TPC-H) Benchmark Environment:HammerDB

Is the performance difference mainly because of below points ?

1 data over flow and calculations like int128(int128.c) and C arithmetic operations(functions include in float.h e.g float4_mul)   

And please suggest is any another functionality or code points need to check on the performance difference 

Yes, currently focusing affects queries as well.

In meanwhile on analysis(hardware level) and sample examples noticed

1. GCC performance  better than Clang on int128 . 

2. Clang performance better than GCC on long long 

 the reference example https://stackoverflow.com/questions/63029428/why-is-int128-t-faster-than-long-long-on-x86-64-gcc

3.GCC enabled with “ fexcess-precision=standard” (precision cast for floating point ).

Is these 3 points can make performance  difference GCC vs Clang in PostgreSQLv14 in Apple/AMD/()environment(intel environment need to check). In these environment int128 enabled wrt PostgreSQLv14.

On Friday, November 5, 2021, Tomas Vondra <tomas.vondra@enterprisedb.com> wrote:

Hi,

IMO this thread provides so little information it's almost impossible to answer the question. There's almost no information about the hardware, scale of the test, configuration of the Postgres instance, the exact build flags, differences in generated asm code, etc.

I find it hard to believe merely switching from clang to gcc yields 22% speedup - that's way higher than any differences we've seen in the past.

In my experience, the speedup is unlikely to be "across the board". There will be a handful of affected queries, while most remaining queries will be about the same. In that case you need to focus on those queries, see if the plans are the same, do some profiling, etc.


regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

> GCC vs Clang 

related: 

As I see - with LLVM/Clang 14.0 ( X86_64 -O3 )   ~12% performance increase expected with the new optimisation ( probably adapted from gcc  )  

- https://twitter.com/djtodoro/status/1466808507240386560

- https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Clang-14-Hoist-Load

regards,

 Imre

arjun shetty <arjunshetty955@gmail.com> ezt írta (időpont: 2021. nov. 16., K, 11:10):

Yes, currently focusing affects queries as well.

In meanwhile on analysis(hardware level) and sample examples noticed

1. GCC performance  better than Clang on int128 . 

2. Clang performance better than GCC on long long 

 the reference example https://stackoverflow.com/questions/63029428/why-is-int128-t-faster-than-long-long-on-x86-64-gcc

3.GCC enabled with “ fexcess-precision=standard” (precision cast for floating point ).

Is these 3 points can make performance  difference GCC vs Clang in PostgreSQLv14 in Apple/AMD/()environment(intel environment need to check). In these environment int128 enabled wrt PostgreSQLv14.

On Friday, November 5, 2021, Tomas Vondra <tomas.vondra@enterprisedb.com> wrote:

Hi,

IMO this thread provides so little information it's almost impossible to answer the question. There's almost no information about the hardware, scale of the test, configuration of the Postgres instance, the exact build flags, differences in generated asm code, etc.

I find it hard to believe merely switching from clang to gcc yields 22% speedup - that's way higher than any differences we've seen in the past.

In my experience, the speedup is unlikely to be "across the board". There will be a handful of affected queries, while most remaining queries will be about the same. In that case you need to focus on those queries, see if the plans are the same, do some profiling, etc.


regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company