Krunal Bauskar <krunalbauskar@gmail.com> writes: > On Mon, 30 Nov 2020 at 10:14, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> The results I posted at [1] seem to contradict this for Apple's new >> machines.
> For the results you saw on Mac-Mini was LSE enabled by default.
Hmm, I don't know how to get Apple's clang to admit what its default settings are ... anybody?
However, it does accept "-march=armv8-a+lse", and that seems to not be the default, because I get different results from my spinlock- pounding test than I did yesterday. Abbreviating into a table:
Some of us may be surprised by the fact that enabling lse is causing regression (1816 -> 892 or 714 -> 610) with HEAD itself.
While lse is meant to improve the performance. This, unfortunately, is not always the case at-least based on my previous experience with LSE.too.
I am still wondering why CAS is slower than TAS on M1. What is special on M1 that other ARM archs has not picked up.
Tom, Sorry to bother you again but this is arising a lot of curiosity about M1.
Whenever you get time can do some micro-benchmarking on M1 (to understand TAS vs CAS).
Also, if you can share assembly code is emitted for the TAS vs CAS.
Unfortunately, that still doesn't lead me to think that either LSE or CAS are net wins on this hardware. It's quite clear that LSE makes the uncontended case a good bit faster, but the contended case is a lot worse, so is that really a tradeoff we want?
> * I would also suggest if possible try with higher scalability (more than 4 > to check if with increase scalability CAS out-perform).
As I said yesterday, running more than 4 processes is just going to bring the low-performance cores into the equation, which is likely to swamp any interesting comparison. I did run the test with "-c 8" today, as shown in the right-hand columns, and the results seem to bear that out.
