[Bug string/26852] aarch64/strcmp has performance regression for some cases
goldstein.w.n at gmail dot com
sourceware-bugzilla@sourceware.org
Sat Mar 5 19:31:27 GMT 2022
https://sourceware.org/bugzilla/show_bug.cgi?id=26852
Noah Goldstein <goldstein.w.n at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |goldstein.w.n at gmail dot com
--- Comment #9 from Noah Goldstein <goldstein.w.n at gmail dot com> ---
(In reply to yangyanchao6@huawei.com from comment #8)
> (In reply to Szabolcs Nagy from comment #1)
> > which core are you measuring?
> >
> > the code was committed based on the measurements in
> > https://sourceware.org/pipermail/libc-alpha/2020-June/115109.html
> >
> > | length | align1 | align2 | uplift A72 | uplift A53 | uplift N1 |
> > ...
> > | 19 | 19 | 19 | 1.00x | 1.05x | 1.00x |
> > | 19 | 19 | 19 | 1.01x | 1.06x | 1.00x |
> > | 19 | 19 | 19 | 1.00x | 1.06x | 1.00x |
> > | 20 | 20 | 20 | 1.03x | 1.07x | 1.04x |
> > | 20 | 20 | 20 | 1.00x | 1.07x | 1.00x |
> > | 20 | 20 | 20 | 0.99x | 1.06x | 1.00x |
> > | 21 | 21 | 21 | 1.03x | 1.07x | 1.04x |
> > | 21 | 21 | 21 | 1.03x | 1.07x | 1.04x |
> > | 21 | 21 | 21 | 1.05x | 1.07x | 1.04x |
> > | 22 | 22 | 22 | 1.03x | 1.08x | 1.04x |
> > | 22 | 22 | 22 | 1.03x | 1.07x | 1.04x |
> > | 22 | 22 | 22 | 1.03x | 1.07x | 1.04x |
> > | 23 | 23 | 23 | 1.02x | 1.07x | 1.03x |
> > | 23 | 23 | 23 | 1.03x | 1.07x | 1.04x |
> > | 23 | 23 | 23 | 1.03x | 1.07x | 1.04x |
> > ...
> > | 16 | 0 | 0 | 1.01x | 1.02x | 1.01x |
> > | 16 | 0 | 0 | 1.00x | 0.97x | 1.01x |
> > | 16 | 0 | 0 | 1.00x | 1.00x | 0.76x |
> > | 16 | 0 | 0 | 1.00x | 1.00x | 0.97x |
> > | 16 | 0 | 0 | 1.00x | 1.00x | 0.97x |
> > | 16 | 0 | 0 | 1.00x | 1.00x | 0.97x |
> > | 16 | 0 | 3 | 0.86x | 1.00x | 0.88x |
> > | 16 | 3 | 4 | 1.00x | 0.93x | 1.10x |
> > | 32 | 0 | 0 | 1.07x | 1.04x | 1.08x |
> > | 32 | 0 | 0 | 1.08x | 1.04x | 1.08x |
> > | 32 | 0 | 0 | 1.04x | 1.05x | 1.05x |
> > | 32 | 0 | 0 | 1.04x | 0.96x | 1.05x |
> > | 32 | 0 | 0 | 1.04x | 0.96x | 1.05x |
> > | 32 | 0 | 0 | 1.04x | 0.98x | 1.05x |
> > | 32 | 0 | 4 | 0.91x | 1.03x | 0.93x |
> > | 32 | 4 | 5 | 0.94x | 1.00x | 1.00x |
> > ...
> > | 16 | 1 | 2 | 0.96x | 0.96x | 1.08x |
> > | 16 | 2 | 1 | 0.86x | 0.95x | 0.97x |
> > | 16 | 1 | 2 | 0.97x | 0.96x | 1.08x |
> > | 16 | 2 | 1 | 0.86x | 0.95x | 0.97x |
> > | 16 | 1 | 2 | 0.95x | 0.95x | 1.19x |
> > | 16 | 2 | 1 | 0.86x | 0.95x | 1.07x |
> > | 32 | 2 | 4 | 0.91x | 0.98x | 1.00x |
> > | 32 | 4 | 2 | 0.92x | 0.93x | 0.97x |
> > | 32 | 2 | 4 | 0.89x | 0.96x | 1.00x |
> > | 32 | 4 | 2 | 0.92x | 0.92x | 0.97x |
> > | 32 | 2 | 4 | 0.91x | 0.96x | 1.00x |
> > | 32 | 4 | 2 | 0.92x | 1.00x | 0.97x |
>
> I've also do some test on this issue:
>
> Use "attachment 13992 [details]" to test:
> [root@localhost test]# ./a.out 50 50
> 0xaaaae0ac12a0,0xaaaae0ac12e0
> base:50, diff:50, postion:0, cycle=48677957
> base:50, diff:50, postion:8, cycle=60936950
> base:50, diff:50, postion:16, cycle=277960241
> base:50, diff:50, postion:24, cycle=69354865
> base:50, diff:50, postion:32, cycle=78853402
> base:50, diff:50, postion:40, cycle=90342072
> base:50, diff:50, postion:48, cycle=101327114
> Performance deteriorates only when the 16 to 23 characters are different.
>
> This question involves two submissions:
> https://sourceware.org/git/ ? p=glibc.git;a=commit; h=adac54ffc5
> From adac54ffc5ded48cba7deb18e46df984b213b0ac Mon Sep 17 00:00:00 2001
> From: Alex Butler <Alex.Butler@arm.com>
> Date: Tue, 16 Jun 2020 12:42:38 +0000
> Subject: [PATCH] aarch64: MTE compatible strcmp
>
> https://sourceware.org/git/ ? p=glibc.git;a=commit; h=34f0d01d5e
> From 34f0d01d5e43c7dedd002ab47f6266dfb5b79c22 Mon Sep 17 00:00:00 2001
> From: Wilco Dijkstra <wdijkstr@arm.com>
> Date: Wed, 15 Jul 2020 16:50:02 +0100
> Subject: [PATCH] AArch64: Align ENTRY to a cacheline
>
> At the beginning of adac54ffc5ded48cba7deb18e46df984b213b0ac, the
> performance is good, but after 34f0d01d5e43c7dedd002ab47f6266dfb5b79, the
> performance deteriorates.
>
> This problem also has something to do with alignment?
>
> diff --git a/sysdeps/aarch64/strcmp.S b/sysdeps/aarch64/strcmp.S
> index f225d718..7a048b66 100644
> --- a/sysdeps/aarch64/strcmp.S
> +++ b/sysdeps/aarch64/strcmp.S
> @@ -71,8 +71,6 @@ ENTRY(strcmp)
> b.ne L(misaligned8)
> cbnz tmp, L(mutual_align)
>
> - .p2align 4
> -
> L(loop_aligned):
> ldr data2, [src1, off2]
> ldr data1, [src1], 8
>
> I removed the first alignment in strcmp and the 300% performance degradation
> disappeared.
Not an expert of the microarch but that sounds like a benchmark artifact.
Possibly check the decode path? If the change in alignment causes decode
to run / not-run out of the trace cache that would severely impact the
benchmark but not necessarily affect real-world performance (where
presumably strcmp is just run back-to-back-to-back in a loop).
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the Glibc-bugs
mailing list