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
