From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
cc: Matthias van de Meent <boekewurm+postgres@gmail.com>,
        "Amonson,
    Paul D" <paul.d.amonson@intel.com>,
        "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>,
        "Shankaran,
    Akash" <akash.shankaran@intel.com>
Subject: Re: Popcount optimization using AVX512
In-reply-to: <20231107022240.GA729644@nathanxps13>
References: <BL1PR11MB5304097DF7EA81D04C33F3D1DCA6A@BL1PR11MB5304.namprd11.prod.outlook.com> <CAEze2WjaFLhp7=Eo-mbSaHsoeq7ZEs00yZ2+FpSpijH+KN_hbA@mail.gmail.com> <20231107022240.GA729644@nathanxps13>
Comments: In-reply-to Nathan Bossart <nathandbossart@gmail.com>
	message dated "Mon, 06 Nov 2023 20:22:40 -0600"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <36328.1699325578.1@sss.pgh.pa.us>
Date: Mon, 06 Nov 2023 21:52:58 -0500
Message-ID: <36329.1699325578@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/36329.1699325578%40sss.pgh.pa.us>
Precedence: bulk

Nathan Bossart <nathandbossart@gmail.com> writes:
> Like I said, I don't have any proposals yet, but assuming we do want to
> support newer intrinsics, either open-coded or via auto-vectorization, I
> suspect we'll need to gather consensus for a new policy/strategy.

Yeah.  The function-pointer solution kind of sucks, because for the
sort of operation we're considering here, adding a call and return
is probably order-of-100% overhead.  Worse, it adds similar overhead
for everyone who doesn't get the benefit of the optimization.  (One
of the key things you want to be able to say, when trying to sell
a maybe-it-helps-or-maybe-it-doesnt optimization to the PG community,
is "it doesn't hurt anyone who's not able to benefit".)  And you
can't argue that that overhead is negligible either, because if it
is then we're all wasting our time even discussing this.  So we need
a better technology, and I fear I have no good ideas about what.

Your comment about vectorization hints at one answer: if you can
amortize the overhead across multiple applications of the operation,
then it doesn't hurt so much.  But I'm not sure how often we can
make that answer work.

			regards, tom lane