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

From Zidenberg, Tsahi
Subject Re: [PATCH] audo-detect and use -moutline-atomics compilation flag for aarch64
Date
Msg-id A0D2F7B7-9531-41EC-A2B0-861F0023D651@amazon.com
Whole thread Raw
In response to Re: [PATCH] audo-detect and use -moutline-atomics compilation flag for aarch64  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: [PATCH] audo-detect and use -moutline-atomics compilation flag for aarch64
Re: [PATCH] audo-detect and use -moutline-atomics compilation flag for aarch64
List pgsql-hackers

On 29/09/2020, 10:21, "Heikki Linnakangas" <hlinnaka@iki.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?




pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: VACUUM PARALLEL option vs. max_parallel_maintenance_workers
Next
From: Bruce Momjian
Date:
Subject: Re: BUG #16419: wrong parsing BC year in to_date() function