`wmemchr` optimization and its throughput impact

[AlexGuteniev]

This include:

STL/stl/inc/xutility

Line 15 in 313964b

#include <cwchar>

Is used for wmemchr optimization, it was introcuded in 2024.

The <cwchar> brings in <intrin.h>, which we have always been avoided for throughput reasons. Probably it started bringing it in specifically for wmemchr optimization.

What should we do now? I see three opposite paths forward:

• Drop #include <cwchar> and current wmemchr optimizations. Almost no impact as vector_algorithms.cpp is preferred most of the time anyway.
• Get SDK fixed to use <intrin0.h>.
• Do nothing, accept throughput impact.

[StephanTLavavej]

See #3631:

STL/stl/inc/limits

Line 12 in 313964b

#include <cwchar> // TRANSITION, see GH-3631: Lots of user code assumes that <limits> drags in <cwchar>

I am not super inclined to do anything here. intrin0.h was added for the STL, and I am not sure if the UCRT should be using it, but <intrin.h> is really quite big. I wonder what intrinsics <wchar.h> actually needs.

[AlexGuteniev]

I am not super inclined to do anything here

I don't agree. I think, if we are not willing to remove wmemchr optimization to get the throughput back, then we should at least take the full advantage of it, and use it in all paths.

// TRANSITION, see GH-3631: Lots of user code assumes that drags in

Still it is <limits>, which is heavier and less frequent than <xutility>, and it is only been there for about a year in <xutility>

I wonder what intrinsics <wchar.h> actually needs

I suspect it needs intrinsics specifically to vectorize wmemchr for x86, x64, AR6M64, ARM64EC and nothing much else.
For x86/x64 it is the spread, load, compare, and move mask for AVX2 and SSE2, SSE2 path additionally has 8-bytes load. It doesn't do AVX2 mask stuff on its AVX2 path.

[AlexGuteniev]

I've edited the issue description to match the current situation.