У меня не влияет.
Pos: 131; KMP: 274; SSE4: 11; SSE2: 15
Не знаю в чём дело. Могу предположить агрессивные настройки энергосбережения, при которых CPU можно расшевелить только TIME_CRITICAL на достаточно долгом интервале.
defecatorкстати, если искомого слова вообще нет, то алгоритм крэшится с Access Violation
Ну и SearchKMP в случае, если ничего не найденоИсправил.
https://drive.google.com/open?id=1zVWYmnSq0Lki4_8Ju9E9jnYHHkhKqZvD
s62когда-то обсуждали на другом форуме скорость "простого" поиска и упрощенного БМХ (Бойер-Мур-Хорспул). Пришли к выводу, что выигрыш есть для относительно длинных строк, а для искомой подстроки длиной до 6 символов разницы практически нет.В моей реализации зависимость от данных ещё более жёсткая.
(ну как - в моей, алгоритм позаимствован отсюда: http://0x80.pl/articles/simd-strfind.html )
В лучшем случае (большой размер основной строки, нет совпадений) будет скорость N/8, для блока в 16 байт делается 2 сравнения. Но в худшем, если подсунуть такую строку, чтобы срабатывал детальный поиск на каждой итерации, получается хуже брут-форса.
При этом у Агнеровской функции нет такого падения скорости на неудобных данных. Возможно, стоит всё-таки попробовать PcmpEstrM.

До более продвинутых алгоритмов у меня наверное руки не дойдут, если интересно - добавляйте.