Re: [PATCH] riscv: Use LMUL=8 for RVV strchr

Peter Bergner <[email protected]>
Newsgroups gmane.comp.lib.glibc.alpha
Message-ID <[email protected]>
On 7/6/26 7:54 AM, Ning Tian wrote:
> The RVV strchr implementation currently uses LMUL=1.  On VLEN=128
> hardware this processes 16 bytes per iteration, so the fixed cost of
> the fault-only-first load, two byte comparisons, two vfirst.m
> operations, and scalar branch logic is paid every 16 bytes.
> 
> Use LMUL=8 so each iteration processes 128 bytes on VLEN=128 systems.
> The character-match mask is moved from v9 to v16 because v0-v7 is now
> used by the m8 data vector group.  The end-of-string mask remains in
> v8.
> 
> On Sophgo SG2044 (VLEN=128, GCC 12.3.1), bench-strchr over 445 cases
> shows a 4.63x geometric-mean speedup compared with the LMUL=1 RVV
> version.  Full-scan cases improve by 5.52x to 8.96x for lengths from
> 64 to 8192 bytes.  Short strings that complete in the first vector
> chunk regress by about 50% because LMUL=8 has higher vector setup cost;
> a later scalar fast path can address that case.


First off, we are currently in a freeze for the upcoming release, so this
will have to wait until after the release (~Aug 1st).

Secondly, these routines are supposed to work on a wide range of riscv
hardware.  Before making a change like this, I'd like some performance numbers
from other systems.  Preferably the recently available K3.  I do not yet
have access to a K3, so maybe you or someone else can test it there?
If it's a win on the K3, then I'm fine with the change....after the release.

Peter
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.