Message-ID: <a325474f-5fd2-48f1-bdaf-5ded7af8c8b3@postgrespro.ru>
Date: Thu, 19 Dec 2024 13:01:07 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Fix bank selection logic in SLRU
To: Dilip Kumar <dilipbalaut@gmail.com>,
 "Andrey M. Borodin" <x4mmm@yandex-team.ru>
Cc: "pgsql-hackers@lists.postgresql.org"
 <pgsql-hackers@lists.postgresql.org>,
 Alvaro Herrera <alvherre@alvh.no-ip.org>
References: <9444dc46-ca47-43ed-9058-89c456316306@postgrespro.ru>
 <4009750D-3EAE-4375-A7A8-3AD9922CDE1F@yandex-team.ru>
 <CAFiTN-vwHHrsNdpwoQN-e495TXvGKAScW8XLsdUEqDEk1woGmA@mail.gmail.com>
Content-Language: en-US
From: Yura Sokolov <y.sokolov@postgrespro.ru>
In-Reply-To: <CAFiTN-vwHHrsNdpwoQN-e495TXvGKAScW8XLsdUEqDEk1woGmA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/a325474f-5fd2-48f1-bdaf-5ded7af8c8b3%40postgrespro.ru>
Precedence: bulk

10.12.2024 17:07, Dilip Kumar wrote:
> On Tue, 10 Dec 2024 at 6:32 PM, Andrey M. Borodin <x4mmm@yandex-team.ru 
> <mailto:x4mmm@yandex-team.ru>> wrote:
> 
> 
> 
>      > On 10 Dec 2024, at 15:39, Yura Sokolov <y.sokolov@postgrespro.ru
>     <mailto:y.sokolov@postgrespro.ru>> wrote:
>      >
>      > It is not critical bug, since it doesn't hurt correctness just
>     performance. In worst case only one bank will be used.
> 
>     Ugh... yeah. IMO the problem is that we do not have protection that
>     rejects values that are not power of 2.
>     If other values given system operates as if there are
>     2^(popcount(n)-1) banks. So if we just round down value to nearest
>     power of 2 - we will help incorrectly configured systems to use
>     proper amount of memory and keep performance of properly configured
>     systems.
> 
> 
> +1
> 
> 
> 
>     IMO doing modulo is not necessary. And hash function is pure waste
>     of CPU cycles.
> 
> 
> I agree

I did some measurement "divide-modulo" vs "modulo using multiplication by
reciprocal" vs "simple binary and" using simple C program [0].
(Note: loop is made to be dependent on previous iteration result so no
parallel computation happens).

Results on Ryzen 7 5825U:

     $ time ./div 100000000 15 3 # binary and
     real    0m0,943s
     $ time ./div 100000000 15 1 # multiply by reciprocal
     real    0m3,123s
     $ time ./div 100000000 15 0 # just plain `%`
     real    0m4,540s

It means:
- `&` takes 0.69ns
- `mult-rec` takes 2.94ns
- `%` takes 3.24ns.

I believe, compared to further memory accesses it could be count as
negligible.

(Certainly, it could be worse on some older processors. But I still doubt
it will be measurably worse on top of all other things SLRU does.)

[0] https://gist.github.com/funny-falcon/173923b4fea7ffdf9e02595a0f99aa74


Regards,
Yura Sokolov aka funny-falcon