Re: [PATCH] libcpp: Optimize AArch64 search_line_fast

Hi Alexander,

>> On Fri, 14 Aug 2026, Wilco Dijkstra wrote:
>> It's just measuring the throughput of the search_line_fast function for different sizes.
>> Then calculate the average from the speedup of each size times the frequency of the
>> distribution. As it happens, the old code was doing a lot of unnecessary initialization,
>> checks etc, so the speedup goes from ~85% for 1-16 chars to ~50% at 80 chars.
>
> Thanks. It's good to know that new code is that much faster for short lines,
> but I suspect averaging in this manner is not ideal if measurements are taken
> as if final branch is perfectly predictable.

Yes I measured pure max throughput since that was easy to do...

>> > I wonder if you looked at something like that? Doing two 16-character matches
>> > per one iteration, then combining results into one GPR for the final CBZ?
>> > Not sure if there's a way to make the epilogue cheap enough, though.

Doing 2 vectors per iteration turned out ~15% slower. I guess the predictor is good
enough so the extra cost from double the number of instructions is not worth it.

> With 'perf stat -r 9 cc1plus -fsyntax-only -quiet t-rawstr.cc' where t-rawstr.cc
> is a big C++ file created by preprocessing '#include <regex>' (see Makefile in
> the attachment). It was posted with my SSSE3-based search_line_fast at
> https://inbox.sourceware.org/gcc-patches/[email protected]/
> (attaching it again to this message)
> and my measurements can be seen at
> https://inbox.sourceware.org/gcc-patches/[email protected]/

Thanks - I tried this but the variations are too large to figure out which variant is best.
So in the end I saved a huge trace and replay that similar to your benchmark. The speedups are
smaller (only 53%) since it includes branch misprediction and L2/L3 misses but should be close
to actual scanner behaviour.

>> while (s < end)
>>   ... loop
>> // no tail code, just return end since it is known that *end == '\n'.
>> return end;  
>
> No, I meant you can just have an infinite loop because the test in the loop
> will work properly when *end is reached.

That works well for the AdvSIMD variant, but the SVE2 version ends up slower if I use a
while (1) loop. I'll post a clean up of the SVE2 version anyway. The AdvSIMD version is
here: https://gcc.gnu.org/pipermail/gcc-patches/2026-August/728009.html

> PS: unfortunately I didn't get a copy of your response to my inbox and had to
> fish it out of the mailing list archive

Yes, somehow emails don't get through...

Cheers,
Wilco