По традиции приебусь к мелочам.
Там в бенчмарке десятки считают, и считалку эту заоптимизировали в вот это. В скрин не влезло, но там выше ещё убедили компилятор, что данные в памяти выровнены по 4096 байтам, так что обращения за границы не вылезут. Это важно, потому что теперь компилятор может со спокойной совестью векторизировать это всё.
Выглядит страшно. Но идея здесь в том, чтобы показать компилятору, что все 16 путей в теле цикла - независимы, включая персональные счётчики (чтобы всё в один регистр не нести). Теперь, если не векторизирует, то хоть камушек по всем доступным АЛУ раскидает, больше операций за такт перемолет.
Сложения ниже отыгрывают ту же роль. Хоть в gcc это практически ничего и не даст (с -O2 вырезаны подчистую), другим компиляторам это может очень даже помочь. Clang вот выдал лесенку сложений, которые уже процессор сам дальше переварит.
В общем, оптимизации - дело тонкое. Не менее тонкое, чем бенчмарки:)
Post #622
338
Чайник из Юты https://www.bitflux.ai/blog/memory-is-slow-part2/ TL;DR и IO тоже делать надо грамотно. А ещё mmap() ощущается неправильным, и файлы им читать не очень круто - даже если уже в кэше лежит, всё равно на каждую страницу придётся прерываться.
