Re: GCC 8.3.0 vs. 9.0.1

Hi,

On 2019-05-07 16:14:43 +0000, Steven Winfield wrote:
> (Apologies if this isn't the right place to post this)

Seems right.


> A few days ago a blog post appeared on phoronix.com[1] comparing GCC 8.3.0 against 9.0.1 on Intel cascadelake processors.
> A notable difference was seen in the PostgreSQL benchmark (v10.3, pgbench, read/write, more detail below), both when compiling with -march=native and -march=skylake:
> 
> GCC version | -march= |   TPS
>       8.3.0 | skylake |  5667
>       9.0.1 | skylake | 11684 (2.06x speed up)
>       8.3.0 | native  |  8075
>       9.0.1 | native  | 11274 (1.40x speed up)
> 
> I'm interested to know the devs' take on this is - does GCC 9 contain some new feature(s) that are particularly well suited to compiling and optimising Postgres? Or was GCC 8 particularly bad?

I think those numbers are just plain bogus. read/write pgbench is
commonly IO bound.  My suspicion is much more that the tests for gcc 8
and 9 were executed in the same postgres cluster (in which case the
second will be faster, because it'll have pre-initialized WAL files).
Or something of that vein.


> (after patching it so that it can run as root)

That, uh, seems odd.


> - pgbench -i -s <system memory in MB * 0.003> pgbench

That's pretty small, but whatever.


Here's my results:

I ran:

pgbench -i -q -s 96 && pgbench -n -c 8 -j 8 -T 100 -P1


gcc 8.3, march=native (on skylake):

first run:
tps = 14436.465265 (excluding connections establishing)

second run:
tps = 13293.266789 (excluding connections establishing)

third run after postgres restart (and thus a checkpoint):
tps = 14270.248273 (excluding connections establishing)


gcc 9.1, march=native (on skylake):

first run:
tps = 13836.231981 (excluding connections establishing)

second run:
tps = 13304.975550 (excluding connections establishing)

third run after postgres restart (and thus a checkpoint):
tps = 14390.246324 (excluding connections establishing)


As you can see the test results are somewhat unstable - the test
duration of 60s is just not long enough. But there's no meaningful
evidence of a large speedup here.




> This email is confidential. If you are not the intended recipient, please advise us immediately and delete this message. 
> The registered name of Cantab- part of GAM Systematic is Cantab Capital Partners LLP. 
> See - http://www.gam.com/en/Legal/Email+disclosures+EU for further information on confidentiality, the risks of non-secure electronic communication, and certain disclosures which we are required to make in accordance with applicable legislation and regulations. 
> If you cannot access this link, please notify us by reply message and we will send the contents to you.
> 
> GAM Holding AG and its subsidiaries (Cantab – GAM Systematic) will collect and use information about you in the course of your interactions with us. 
> Full details about the data types we collect and what we use this for and your related rights is set out in our online privacy policy at https://www.gam.com/en/legal/privacy-policy. 
> Please familiarise yourself with this policy and check it from time to time for updates as it supplements this notice.

This is a public list.

Greetings,

Andres Freund