From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com> |
Subject: | Re: call popcount32/64 directly on non-x86 platforms |
Date: | 2021-08-12 05:25:55 |
Message-ID: | CAApHDvr-+Ucf9JVTUGi6AyPz3v6vMkkdH7WXPWBPJaNAXTJH+w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 12 Aug 2021 at 14:02, John Naylor <john(dot)naylor(at)enterprisedb(dot)com> wrote:
>
>
> On Wed, Aug 11, 2021 at 8:13 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> >
> > On Thu, 12 Aug 2021 at 05:11, John Naylor <john(dot)naylor(at)enterprisedb(dot)com> wrote:
> > > 0001 moves some declarations around so that "slow" popcount functions are called directly on non-x86 platforms.
> >
> > I was wondering if there was a reason that you didn't implement this
> > by just changing pg_popcount32 and pg_popcount64 to be actual
> > functions rather than function pointers when TRY_POPCNT_FAST is not
> > defined? These functions would then just return
> > pg_popcountNN_slow(word);
> >
> > This would save from having to change all the current callers of the
> > functions to use the macro instead. That might be nice for any
> > extensions which are using these functions.
>
> Hmm, it wasn't obvious to me that would work, but I tried it and came up with v2. Is this what you had in mind?
Closer, but I don't see why there's any need to make the fast and slow
functions external. It should be perfectly fine to keep them static.
I didn't test the performance, but the attached works for me.
Going by https://godbolt.org/z/ocv1Kj5K4 f2 seems to inline f1
David
Attachment | Content-Type | Size |
---|---|---|
v3-0001-Use-direct-function-calls-for-pg_popcount-32-64-o.patch | application/octet-stream | 3.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2021-08-12 05:53:15 | Re: Skipping logical replication transactions on subscriber side |
Previous Message | Amit Kapila | 2021-08-12 04:55:20 | Re: Added schema level support for publication. |