Vectorize find_end by AlexGuteniev · Pull Request #4943 · microsoft/STL (original) (raw)

📜 Overview

• Similar to Vectorize std::search of 1 and 2 bytes elements with pcmpestri #4745 in the opposite direction
• The algorithm is not very similar though. I have not attempted the one-index pcmpestri instruction and variable step, but it looked like multiple-indices pcmpestrm and fixed step would work better for this direction, because the former would return more partial false matches than in forward direction, as the match with higher index is more likely to be partial.
  • If that's not convincing enough, I can try the other approach
  • pcmpestrm approach could have been made more efficient if DevCom-10689455 is fixed, but honestly I don't hope for that much
• Also restructured control flow a vit in __std_search_impl, the place where _Match_1st_16 is introduced. I basically implemented the same thing from scratch, and the new attempt gave clearer control flow implementation. They are not shared though, as _First1 > _Stop1 check is needed for variable step, but not needed for fixed step, so here's still some variation.
• The types larger than 2 bytes were excluded from test and benchmark -- same way as we don't test replace with smaller elements.
• The benchmark patterns list is expanded to test small and large needle closer to the other end. I deliberately left coverage for search + closer to start and find_end + closer to end, It is useful to test the case where startup cost contributes more.
• Also added couple of "evil" patterns in benchmark. The goal for them is not to make them too much worse. I leave up to maintainers to decide if this goal is achieved

👿 The Evil case

Unlike many other algorithms, search algorithm run time highly depends on the data. It is possible to craft data which takes way more time than typical data of the same length.

The worst case could be haystack of a single repeating value, and the needle with the same repeating values and another value in the end. This is bad for plain search, although Boyer-Moore or similar algorithms are expected to handle that better.

⚠️ The results for find_end are much worse for that case ⚠️

⚠️ The results for search are also worse after vectorization for such case, but not that much as find_end ⚠️

It look possible to detect the evil case (by the amount of matched beginnings per some amount of data) and switch to another algorithm, or to modify the whole algorithm to be less affected. It can be done in this or subsequent PR.

I doubt how much the Evil case is important.

🏁 Benchmark results

Legend for the benchmark parameter:

Re-testong of the search PR against then-main as there are more cases in the benchmark: