[PATCH next] string: Optimise strlen()

[david . laight . linux]

From: David Laight <david.laight.linux@xxxxxxxxx>

Unrolling the loop once significantly improves performance on some CPU.
Userspace testing on a Zen-5 shows it runs at two bytes/clock rather than
one byte/clock with only a marginal additional overhead.

Using 'byte masking' is faster for longer strings - the break-even point
is around 56 bytes on the same Zen-5 (there is much larger overhead, then
it runs at 16 bytes in 3 clocks).
But the majority of kernel calls won't be near that length.
There will also be extra overhead for big-endian systems and those
without a fast ffs().

Signed-off-by: David Laight <david.laight.linux@xxxxxxxxx>
---

For reference 'rep scasb' comes in at 150 + 3 per byte on Zen-5.

I've not tested any Intel CPU, I don't think they can run a
'1 clock loop' but the change might improve performance from
2 clocks/byte to 1 clock/byte.
I can test Intel up to i7-7xxx but don't have any older AMD CPU
or any other architecutes (apart from a pi-5).

Other architectures may well see an improvement.
If only because of a reduced number of taken branches.

I did notice that arm64 uses a very large asm block that is clearly
optimised for very long strings - I suspect the C version will be
faster in the kernel.

 lib/string.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/lib/string.c b/lib/string.c
index b632c71df1a5..31de9aa86409 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -415,11 +415,13 @@ EXPORT_SYMBOL(strnchr);
 #ifndef __HAVE_ARCH_STRLEN
 size_t strlen(const char *s)
 {
-	const char *sc;
+	size_t len;
 
-	for (sc = s; *sc != '\0'; ++sc)
-		/* nothing */;
-	return sc - s;
+	for (len = 0; likely(s[len]); len += 2) {
+		if (!s[len + 1])
+			return len + 1;
+	}
+	return len;
 }
 EXPORT_SYMBOL(strlen);
 #endif
-- 
2.39.5