Re: [PATCH] audo-detect and use -moutline-atomics compilation flag for aarch64

From: "Zidenberg, Tsahi" <tsahee(at)amazon(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] audo-detect and use -moutline-atomics compilation flag for aarch64
Date: 2020-09-30 16:04:49
Message-ID: A0D2F7B7-9531-41EC-A2B0-861F0023D651@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 29/09/2020, 10:21, "Heikki Linnakangas" <hlinnaka(at)iki(dot)fi> wrote:
> If it's a good idea to use -moutline-atomics, I would expect the
> compiler or distribution to enable it by default. And as you pointed
> out, many have.

-moutline-atomics is only enabled by default on the gcc-10 branch where
it was originally developed. It was important enough to be backported
to previous versions and picked up by e.g. ubuntu and amazon-linux.
However, outline-atomics is not enabled by default in any backports that
I'm aware of. Ubuntu 20.04 even turned it off by default for gcc-10,
which seems like a compatibility step with the main gcc-9 compiler.
Always-enabled outline-atomic is, sadly, many years in the
future for release systems.

> For the others, there are probably reasons they haven't,
> like begin conservative in general. Whatever the reasons, IMHO we should
> not second-guess them.

I assume GCC chose conservatively not to add code by default that
won't help old CPUs when increasing minor versions (although I see
no performance degradation in real software).
On the other hand, the feature was important enough to be
back-ported to allow software to take advantage of it.
Postgresql should be the most advanced open source database.
As I understand it, it should be able to handle as well as possible
large workloads on large modern machines like Graviton2, and
that means using LSE.

> I'm marking this as Rejected in the commitfest. But thanks for the
> benchmarking, that is valuable information nevertheless.

Could additional data change your mind?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2020-09-30 17:56:42 Re: BUG #16419: wrong parsing BC year in to_date() function
Previous Message Robert Haas 2020-09-30 15:53:44 Re: VACUUM PARALLEL option vs. max_parallel_maintenance_workers