为了磨练我的C技能,我下载了eglibc源代码,我遇到了strncpy。我不明白他为什么要区分n <= 4并进行4次测试的情况。
int
STRNCMP (const char *s1, const char *s2, size_t n)
{
unsigned char c1 = '\0';
unsigned char c2 = '\0';
if (n >= 4)
{
size_t n4 = n >> 2;
do
{
c1 = (unsigned char) *s1++;
c2 = (unsigned char) *s2++;
if (c1 == '\0' || c1 != c2)
return c1 - c2;
c1 = (unsigned char) *s1++;
c2 = (unsigned char) *s2++;
if (c1 == '\0' || c1 != c2)
return c1 - c2;
c1 = (unsigned char) *s1++;
c2 = (unsigned char) *s2++;
if (c1 == '\0' || c1 != c2)
return c1 - c2;
c1 = (unsigned char) *s1++;
c2 = (unsigned char) *s2++;
if (c1 == '\0' || c1 != c2)
return c1 - c2;
} while (--n4 > 0);
n &= 3;
}
while (n > 0)
{
c1 = (unsigned char) *s1++;
c2 = (unsigned char) *s2++;
if (c1 == '\0' || c1 != c2)
return c1 - c2;
n--;
}
return c1 - c2;
}
可能它与内存布局有关,我不知道,请赐教。
答案 0 :(得分:6)
它是unrolled loop。以使二进制文件大一点为代价,它通过消除每4个字节的3个减量,3个分支和3个条件来加速字符串比较。
使用与Duff's device相同的技术甚至可以进一步优化,但不清楚这实际上会更快。从链接页面
对剩余部分的自动处理可能不是所有系统和编译器的最佳解决方案 - 在某些情况下,两个循环实际上可能更快(一个循环,展开,执行主副本,以及第二个循环来处理剩余部分) )。问题似乎归结为编译器正确优化设备的能力;它还可能干扰某些体系结构上的流水线和分支预测。当在版本4.0中从XFree86服务器中删除了大量Duff设备实例时,性能得到了改进,并且可执行文件的大小明显减少。因此,在考虑使用此代码时,可能需要运行一些基准来验证它实际上是目标体系结构上目标体系结构中目标体系结构最快的代码。