为什么没有优化 std::count 和 std::find 以使用 memchr？

Question

我正在阅读 sehe's answer 到 this question 并惊讶地发现使用 std::memchr 的手写循环比使用 std::count 快 3 倍以上（请参阅 cmets ）。使用std::count的代码可以在编辑2中看到，但它基本上归结为：

const auto num_lines = std::count(f, l, '\n');

对比

uintmax_t num_lines = 0;
while (f && f != l)
    if ((f = static_cast<const char*>(memchr(f, '\n', l - f))))
        num_lines++, f++;

我原以为std::count 版本至少与std::memchr 版本一样快——原因与using std::copy should be at least as fast as std::memcpy 类似。

我检查了我的标准库 (libc++) 的 std::count 实现，并没有尝试优化 char 输入类型（std::find 同上）。

这是为什么？如果提供char* 迭代器和char 值，实现是否不能分派到std::memchr？

Answer 1

只有在匹配之间的平均距离不小的情况下，使用对memchr 的实际函数调用才是胜利。

特别是对于count，调用memchr 可能会慢很多，如果您计算t 字符时它们平均每2 个或每4 个出现一次。（例如，使用ACGT 字母表的DNA 碱基对)。

我对使用memchr 循环作为std::count 而不是char 数组的默认实现持怀疑态度。更有可能有其他方法来调整源代码，使其编译为更好的 asm。

对于find，它会更有意义，即使与简单的逐字节循环相比，如果前几个字节有命中，它确实可能会显着增加开销。

---

您也可以将其视为编译器错过的优化。如果编译器为 std::count 和 std::find 中的循环编写了更好的代码，那么调用手写 asm 库函数的收益就会更少。

gcc 和 clang 在进入循环之前不知道行程计数时从不自动矢量化循环。 （即他们不进行搜索循环，这是对小至字节的元素大小的主要优化缺失）。 ICC 没有这个限制，并且可以矢量化搜索循环。不过，我还没有研究过它如何处理 libc++ 的 std::count 或 find 。

std::count 必须检查每个元素，所以它应该自动矢量化。但是如果 gcc 或 clang 甚至不使用-O3，那么这很不幸。它应该在 x86 上使用pcmpeqb（打包比较字节）很好地矢量化，然后paddb 0/-1 比较结果。 （至少每 255 次迭代，psadbw 对零水平求和字节元素）。

库函数调用开销至少是使用来自内存的函数指针的间接调用（可以缓存未命中）。在具有动态链接的 Linux 上，通常还有一个额外的 jmp 通过 PLT（除非您使用 -fno-plt 编译）。 memchr 比 strchr 更容易以较低的启动开销进行优化，因为您可以快速检查 16B 向量加载是否可以超过末尾（与对齐 strchr 或 strlen 的指针以避免跨页或缓存行边界）

如果调用 memchr 是在 asm 中实现某些东西的最佳方式，那么理论上这就是编译器应该发出的。 gcc/clang 已经优化了对 libc memcpy 的调用的大型复制循环，具体取决于目标选项 (-march=)。例如当副本足够大以至于 libc 版本可能决定在 x86 上使用 NT 存储时。