字符串长度函数不稳定

Question

所以我不久前做了这个 strlen，一切看起来都很好。但是我开始注意到我的代码库中的错误，过了一段时间我将其追踪到这个 strlen 函数。我使用 SIMD 指令来编写它，而且我是编写内部函数的新手，所以代码可能也不是最好的。

函数如下：

inline size_t strlen(const char* data) {
        const __m256i terminationCharacters = _mm256_setzero_si256();
        const size_t shiftAmount = ((size_t)&data) & 31;
        const __m256i* pointer = (const __m256i*) (data - shiftAmount);

        size_t length = 0;

        for (;; length += 32, ++pointer) {
            const __m256i comparingData = _mm256_load_si256(pointer);
            const __m256i comparison = _mm256_cmpeq_epi8(comparingData, terminationCharacters);

            if (!_mm256_testc_si256(terminationCharacters, comparison)) {
                const auto mask = _mm256_movemask_epi8(comparison);

                return length + _tzcnt_u32(mask >> shiftAmount);
            }
        }
    }

Answer 1

您尝试将启动处理结合到对齐向量循环中至少有 2 个显示停止错误：

• 如果对齐的加载找到任何零字节，则退出循环，即使它们来自字符串的正确开始之前。 （@James Griffin 在 cmets 中发现了这一点）。您需要执行mask >>= shiftAmount 并检查它是否为非零，以查看在字符串开始之后的负载部分是否有任何匹配。 （不要使用_mm256_testc_si256，只需移动掩码并检查）。

• _tzcnt_u32(mask >> shiftAmount); 对于任何向量在第一个都是错误的。整个向量来自字符串开头之后的字节，因此您需要 tzcnt 才能查看所有位。相反，你想要_tzcnt_u32(mask) - shiftAmount，我想。

在实际字符串之前但在第一个对齐向量内使用0 字节为自己制作一些测试用例。并在相对于向量的不同位置使用最终的0 测试用例，并且非零并针对libc strlen 测试您的版本。 （甚至可能是前 32 个字节内的一些随机 0 位置，然后是之后的前 64 个字节内。）

如果您将其与循环分开，您处理未对齐启动的策略应该会奏效。 (Is it safe to read past the end of a buffer within the same page on x86 and x64?)。

另一个选项是在从字符串的实际开头加载第一个未对齐向量之前进行页面交叉检查。 （但是你需要回退到别的东西）。然后对齐：重叠很好；只要你正确计算出最终的长度，你是否两次检查同一个字节是否为零都没关系。

---

（你也不希望编译器在循环中浪费指令来增加一个指针和一个单独的长度，所以检查生成的asm。循环后的指针减法应该做诀窍。甚至投到uintptr_t。
此外，您可以从初始函数 arg 中减去最终的零位置，而不是从对齐的指针中减去，因此除了初始对齐之外，您根本不使用它，而不是两次减去 shiftAmount。）

根本不要使用 vptest 内在函数 (_mm256_testc_si256)，即使在应该检查所有字节的主循环中也是如此； _mm_cmp* 结果并不好。 vptest 是 2 微指令，不能与分支指令进行宏融合。但是vpmovmskb eax, ymm0 是 1 uop，test eax,eax / jz .loop 是另一个宏融合的 uop。更好的是，您实际上需要循环后的整数移动掩码结果，所以您已经有了它。

---

相关

• Is it safe to read past the end of a buffer within the same page on x86 and x64?

• Why does glibc's strlen need to be so complicated to run quickly?（包括用于 glibc 的 strlen 实现的手写 x86-64 asm 的链接。）除非您使用的平台具有更差的 C 库，否则通常您应该使用它，因为 glibc 在动态链接期间使用 CPU 检测为您的 CPU 选择一个好的 strlen 版本（和 memcpy 等）。 strlen 的未对齐启动有点棘手，我认为 glibc 做出了合理的选择，除非函数调用开销是一个大问题。它还具有针对大字符串的良好循环展开技术（例如_mm256_min_epu8，如果 2 个输入向量中的任何一个具有零，则在向量元素中获取零，因此它可以将实际的移动掩码/分支工作摊销到整个缓存行数据的）。不过，对于中等长度的字符串，它可能过于激进。

  请注意，glibc 的许可证是 LGPL，因此您不能只将 glibc 中的代码复制到您的项目中，除非您的许可证兼容。甚至编写与其 asm 等效的内在函数也可能存在问题。

• Why is this code using strlen heavily 6.5x slower with GCC optimizations enabled? - 一个简单的 SSE2 strlen，不处理错位，手写 asm。和 cmets 进行基准测试。

• https://agner.org/optimize/ - 指南和指令表，他的子程序库（手写 asm）包括一个 strlen。 （但请注意，它是 GPL 许可的。）

我假设某些 BSD 和 MacOS 在更宽松的许可下具有 asm strlen，如果您的项目不兼容 GPL，您可以使用/查看。

Answer 2

没有冒犯，但是

size_t strlen(char *p)
{
    size_t ret_val = 0;

    while (*p++) ret_val++;

    retirn ret_val;
}

很久以前它的工作就做得很好。此外，今天的优化编译器为它获得了非常紧凑的代码，并且您的代码无法阅读。