John Naylor writes:
> v2 had an Assert that was only correct while experimenting with
> eliding right shift. Fixed in v3.
I think there must have been something wrong with your test that
said that eliminating the right shift from the non-CLZ code made
it slower. It should be an unconditional
v2 had an Assert that was only correct while experimenting with
eliding right shift. Fixed in v3.
--
John Naylorhttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
v3-0001-Use-the-CLZ-instruction-in-AllocSetFreeIndex.patch
On Fri, Dec 27, 2019 at 9:16 PM David Fetter wrote:
> On Fri, Dec 27, 2019 at 07:02:02PM -0500, John Naylor wrote:
> > The lookup table case is less clear. Removing the shift results in
> > assembly that looks more like the C code and is slower for me. The
> > standard lookup table code uses some
On Fri, Dec 27, 2019 at 07:02:02PM -0500, John Naylor wrote:
> On Fri, Dec 27, 2019 at 11:05 AM Tom Lane wrote:
> >
> > John Naylor writes:
> > > On Fri, Dec 27, 2019 at 9:54 AM Tom Lane wrote:
> > >> ... but couldn't the
> > >> right shift be elided in favor of changing the constant we
> > >>
On Fri, Dec 27, 2019 at 11:05 AM Tom Lane wrote:
>
> John Naylor writes:
> > On Fri, Dec 27, 2019 at 9:54 AM Tom Lane wrote:
> >> ... but couldn't the
> >> right shift be elided in favor of changing the constant we
> >> subtract clz's result from? Shifting off those bits separately
> >> made
Alvaro Herrera writes:
> On 2019-Dec-27, Tom Lane wrote:
>> ... Perhaps what we really ought to be working on is
>> finding MSVC equivalents for __builtin_clz and friends.
> Apparently clz() can be written using _BitScanReverse(), per
> https://stackoverflow.com/a/20468180
>
On Fri, Dec 27, 2019 at 01:29:47PM -0300, Alvaro Herrera wrote:
> On 2019-Dec-27, Tom Lane wrote:
>
> > This kind of leads me to wonder if we don't need to expend more
> > effort on the non-CLZ version of pg_leftmost_one_pos32; it seems
> > like it shouldn't be losing this badly to the
On 2019-Dec-27, Tom Lane wrote:
> This kind of leads me to wonder if we don't need to expend more
> effort on the non-CLZ version of pg_leftmost_one_pos32; it seems
> like it shouldn't be losing this badly to the only-slightly-
> improved logic that's currently in AllocSetFreeIndex. On the
>
John Naylor writes:
> On Fri, Dec 27, 2019 at 9:54 AM Tom Lane wrote:
>> ... but couldn't the
>> right shift be elided in favor of changing the constant we
>> subtract clz's result from? Shifting off those bits separately
>> made sense in the old implementation, but assuming that CLZ is
>> more
On Fri, Dec 27, 2019 at 9:54 AM Tom Lane wrote:
>
> Anyway, getting back to the presented patch, I find myself a bit
> dissatisfied with it because it seems like it's leaving something
> on the table. Specifically, looking at the generated assembly
> code on a couple of architectures, the setup
Alvaro Herrera writes:
> On 2019-Dec-26, John Naylor wrote:
>> In commit ab5b4e2f9ed, we optimized AllocSetFreeIndex() using a lookup
>> table. At the time, using CLZ was rejected because compiler/platform
>> support was not widespread enough to justify it. For other reasons, we
>> recently added
On 2019-Dec-26, John Naylor wrote:
> In commit ab5b4e2f9ed, we optimized AllocSetFreeIndex() using a lookup
> table. At the time, using CLZ was rejected because compiler/platform
> support was not widespread enough to justify it. For other reasons, we
> recently added bitutils.h which uses
Hi all,
In commit ab5b4e2f9ed, we optimized AllocSetFreeIndex() using a lookup
table. At the time, using CLZ was rejected because compiler/platform
support was not widespread enough to justify it. For other reasons, we
recently added bitutils.h which uses __builtin_clz() where available,
so it
13 matches
Mail list logo
