From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Yuqi Gu <Yuqi(dot)Gu(at)arm(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Optimize Arm64 crc32c implementation in Postgresql |
Date: | 2018-04-01 17:32:54 |
Message-ID: | 20180401173254.46tgmqh5n6nxymc2@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2018-03-06 02:44:35 +0800, Heikki Linnakangas wrote:
> On 02/03/18 06:42, Andres Freund wrote:
> > On 2018-03-02 11:37:52 +1300, Thomas Munro wrote:
> > > So... that stuff probably needs either a configure check for the
> > > getauxval function and/or those headers, or an OS check?
> >
> > It'd probably be better to not rely on os specific headers, and instead
> > directly access the capabilities.
>
> Anyone got an idea on how to do that? I googled around a bit, but couldn't
> find any examples.
Similar...
> * Use compiler intrinsics instead of inline assembly.
+many
> * I tested this on Linux, with gcc and clang, on an ARM64 virtual machine
> that I had available (not an emulator, but a VM on a shared ARM64 server).
Have you seen actual postgres performance benefits with the patch?
- Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-04-01 17:38:15 | Rethinking -L switch handling and construction of LDFLAGS |
Previous Message | Alexander Korotkov | 2018-04-01 17:13:55 | Re: Diagonal storage model |