From: Willy Tarreau
> Sent: 11 October 2022 07:21
>
> On Mon, Oct 10, 2022 at 10:03:53AM +0000, David Laight wrote:
> > From: Willy Tarreau <w@xxxxxx>
> > > Sent: 09 October 2022 19:36
> > ...
> > > By the way, just for the sake of completeness, the one that consistently
> > > gives me a better output is this one:
> > >
> > > size_t strlen(const char *str)
> > > {
> > > const char *s0 = str--;
> > >
> > > while (*++str)
> > > ;
> > > return str - s0;
> > > }
> > >
> > > Which gives me this:
> > >
> > >
> > > 0000000000000000 <strlen>:
> > > 0: 48 8d 47 ff lea -0x1(%rdi),%rax
> > > 4: 48 ff c0 inc %rax
> > > 7: 80 38 00 cmpb $0x0,(%rax)
> > > a: 75 f8 jne 4 <len+0x4>
> > > c: 48 29 f8 sub %rdi,%rax
> > > f: c3 ret
> > >
> > > But this is totally ruined by the addition of asm() in the loop. However
> > > I suspect that the construct is difficult to match against a real strlen()
> > > since it starts on an extra character, thus placing the asm() statement
> > > before the loop could durably preserve it. It does work here (the code
> > > remains the exact same one), but for how long, that's the question. Maybe
> > > we can revisit the various loop-based functions in the future with this in
> > > mind.
> >
> > clang wilfully and persistently generates:
> >
> > strlen: # @strlen
> > movq $-1, %rax
> > .LBB0_1: # =>This Inner Loop Header: Depth=1
> > cmpb $0, 1(%rdi,%rax)
> > leaq 1(%rax), %rax
> > jne .LBB0_1
> > retq
> >
> > But feed the C for that into gcc and it generates a 'jmp strlen'
> > at everything above -O1.
>
> Interesting, that's not the case for me here with 12.2 from kernel.org
> on x86_64, which gives this at -O1, -O2, -O3 and -Ofast:
>
> 0000000000000000 <strlen>:
> 0: 48 8d 47 ff lea -0x1(%rdi),%rax
> 4: 0f 1f 40 00 nopl 0x0(%rax)
> 8: 48 83 c0 01 add $0x1,%rax
> c: 80 38 00 cmpb $0x0,(%rax)
> f: 75 f7 jne 8 <strlen+0x8>
> 11: 48 29 f8 sub %rdi,%rax
> 14: c3 ret
>
> Out of curiosity what version were you using ?
Clang 12.0.0 onwards, see https://godbolt.org/z/67Gnzs8js
> > I suspect that might run with less clocks/byte than the code above.
>
> Certainly for large strings, but not for short ones.
For short strings not needing the final sub and not having
the read depend on the increment should make the leal one faster.
(The nop to align the loop label is monumentally pointless.)
For long strings what matters is how many clocks it takes
to schedule the 4 uops in the loop.
It might be possible to get down to 2 clocks - but I think
both the loops are 3 clocks (assuming the adjacent cmp/jne fuse).
I'm not going to try to instrument the loops though!
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
