> but that algorithm requires costly preprocessing of the set to be matched. For string functions, input strings are usually very short > the advantage of longe

> but that algorithm requires costly preprocessing of the set to be matched. For string functions, input strings are usually very short > the advantage of longer vectors severely reduced when your input is unlikely to be longer than one or two of them. Both of those make sense. > Plus for AVX and later, we have to do a VZEROUPPER before return (to ensure other SSE code in the user's program is not impacted), Bummer, it's painful that we are still working around SW that hasn't been recompiled for the 13 year old now SNB. > shuffling data back and forth between general purpose and mask registers. Gcc and clang do a really poor job deciding which operations to do in GPRs and which to do in mask registers. Interesting. Was this using the _k intrinsics (e.g., _kshiftli_mask32 - requires fairly new clang) or just treating the AVX-512 mask as an int? > They also fail hard at hoisting constant loads out of hot loops. We often do that manually, no? > each loop trying to find something in a string must at the same time look for the nul terminator and be careful not to cross page boundaries while doing so. Yeah, that sounds not so fun. You're probably already rounding down to aligned vectors? (otherwise the 'load with junk' could also fault) > I recommend you try and implement some of these functions yourself. I am quite busy with another project and do not have any coding time for new undertakings :) The closest we have is https://github.com/google/highway/blob/master/hwy/contrib/algo/find-inl.h https://github.com/google/highway/blob/master/hwy/contrib/al... but that is much simpler and less-optimized than what you are describing.