Re: use CLZ instruction in AllocSetFreeIndex()

From: John Naylor <john(dot)naylor(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: use CLZ instruction in AllocSetFreeIndex()
Date: 2019-12-27 15:47:01
Message-ID: CACPNZCsJX8QE02mfM3qgV1dUgCb2kT8PSRcAocokVKpfeLLt6Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 27, 2019 at 9:54 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 logic generated by
>
> tsize = (size - 1) >> ALLOC_MINBITS;
>
> looks like it costs as much or more as the clz proper. I'm not
> sure we can get rid of the subtract-one step,

As I understand it, the desired outcome is ceil(log2(size)), which can
be computed by clz(size - 1) + 1.

> 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 or less constant-time, it doesn't with CLZ.

That makes sense -- I'll look into doing that.

--
John Naylor https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-12-27 16:05:22 Re: use CLZ instruction in AllocSetFreeIndex()
Previous Message Alvaro Herrera 2019-12-27 15:07:06 Re: Reorderbuffer crash during recovery