> On 01/12/2020, 16:59, "Alexander Korotkov" <aekorotkov@gmail.com> wrote:
> On Tue, Dec 1, 2020 at 1:10 PM Amit Khandekar <amitdkhan.pg@gmail.com> wrote:
> > FWIW, here is an earlier discussion on the same (also added the
> > proposal author here) :
Thanks for looping me in!
> >
> > https://www.postgresql.org/message-id/flat/099F69EE-51D3-4214-934A-1F28C0A1A7A7%40amazon.com
>
>
> Thank you for pointing! I wonder why the effect of LSE on Graviton2
> observed by Tsahi Zidenberg is so modest. It's probably because he
> runs the tests with a low number of clients.
There are multiple possible reasons why I saw a smaller effect of LSE, but I think an important one was that I
used a 32-core instance rather than a 64-core one. The reason I did so, was that 32-cores gave me better
absolute results than 64 cores, and I didn't want to feel like I could misguide anyone.
The 64-core instance results is a good example for the benefit of LSE. LSE becomes most important in edges,
and with adversarial workloads. If multiple CPUs try to acquire a lock simultaneously - LSE ensures one CPU
will indeed get the lock (with just one transaction), while LDRX/STRX could have multiple CPUS looping and
no-one acquiring a lock. This is why I believe just looking at "reasonable" benchmarks misses out on effects
real customers will run into.
Happy to see another arm-optimization thread so quickly :)
Thank you!
Tsahi.