From: Tom Lane <tgl@sss.pgh.pa.us>
To: Steven Winfield <Steven.Winfield@cantabcapital.com>
cc: "pgsql-performance@lists.postgresql.org"
 <pgsql-performance@lists.postgresql.org>
Subject: Re: GCC 8.3.0 vs. 9.0.1
In-reply-to: 
 <E9FA92C2921F31408041863B74EE4C2001BD66841B@CCPMAILDAG03.cantab.local>
References: 
 <E9FA92C2921F31408041863B74EE4C2001BD66841B@CCPMAILDAG03.cantab.local>
Comments: In-reply-to Steven Winfield <Steven.Winfield@cantabcapital.com>
	message dated "Tue, 07 May 2019 16:14:43 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4469.1557248759.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 07 May 2019 13:05:59 -0400
Message-ID: <4470.1557248759@sss.pgh.pa.us>
Precedence: bulk

Steven Winfield <Steven.Winfield@cantabcapital.com> writes:
> 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, pgbenc=
h, read/write, more detail below), both when compiling with -march=3Dnativ=
e and -march=3Dskylake:
> I'm interested to know the devs' take on this is - does GCC 9 contain so=
me new feature(s) that are particularly well suited to compiling and optim=
ising Postgres? Or was GCC 8 particularly bad?

Given the described test setup, I'd put basically no stock in these
numbers.  It's unlikely that this test case's performance is CPU-bound
per se; more likely, I/O and lock contention are dominant factors.
So I'm afraid whatever they're measuring is a more-or-less chance
effect rather than a real system-wide code improvement.

It is an interesting report, all the same.

			regards, tom lane