关于gcc：为什么c ++ std :: max_element这么慢？

why is c++ std::max_element so slow?

我需要在向量中找到max元素，所以我使用std::max_element，但我发现它是一个非常慢的函数，所以我编写了自己的版本并设法使x3获得更好的性能，下面是代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

#include <string>
#include <iostream>
#include <vector>
#include

#include <sys/time.h>

double getRealTime()
{
struct timeval tv;
gettimeofday(&tv, 0);
return (double) tv.tv_sec + 1.0e-6 * (double) tv.tv_usec;
}

inline int my_max_element(const std::vector<int> &vec, int size)
{
auto it = vec.begin();
int max = *it++;
for (; it != vec.end(); it++)
{
if (*it > max)
{
max = *it;
}
}
return max;
}

int main()
{
const int size = 1 << 20;
std::vector<int> vec;
for (int i = 0; i < size; i++)
{
if (i == 59)
{
vec.push_back(1000000012);
}
else
{
vec.push_back(i);
}
}

double startTime = getRealTime();
int maxIter = *std::max_element(vec.begin(), vec.end());
double stopTime = getRealTime();
double totalIteratorTime = stopTime - startTime;

startTime = getRealTime();
int maxArray = my_max_element(vec, size);
stopTime = getRealTime();
double totalArrayTime = stopTime - startTime;

std::cout <<"MaxIter =" << maxIter << std::endl;
std::cout <<"MaxArray =" << maxArray << std::endl;
std::cout <<"Total CPU time iterator =" << totalIteratorTime << std::endl;
std::cout <<"Total CPU time array =" << totalArrayTime << std::endl;
std::cout <<"iter/array ratio: =" << totalIteratorTime / totalArrayTime << std::endl;
return 0;
}

输出：

1
2
3
4
5

MaxIter = 1000000012
MaxArray = 1000000012
Total CPU time iterator = 0.000989199
Total CPU time array = 0.000293016
iter/array ratio: = 3.37592

平均来说，std::max_element比my_max_element多花了3倍的时间。那么，为什么我能这么容易地创建一个更快的std函数呢？既然std太慢，我应该停止使用std并编写自己的函数吗？

注意：起初我认为这是因为我在for循环中使用和整数i，而不是使用迭代器，但现在接缝无关紧要。

编译信息：

G+(GCC)4.8

G++-O3-墙-C-FEMIT长度＝0 -STD= C++0X

相关讨论

您使用的是什么编译器和STL？
您是否使用优化进行编译？
您是如何编译代码的？是否启用了优化(例如，如果使用gcc…，则使用g++ -Wall -O2编译)？
我添加了所有的信息，@alex我在哪里得到STL版本？
你试过颠倒通话顺序吗？缓存可能在这里工作。
这就是我得到的。Max_元素太慢了，即使Max_元素也快了70%。
@是的，下降到2.5……很好，但还不够。
@VLADP和我的电脑没什么区别。几乎相同的输出！
大多数差异似乎来自矢量化(只有一个版本是矢量化的)。在海湾合作委员会的Bugzilla申请公关？
取下EDOCX1[1]使其更靠近
尝试将-DNDEBUG添加到命令行。可能在标准库中有断言。
my_max_element在空向量上中断，而std::max_element需要检测和处理这种情况。
@Mattmcnab，这种支票的成本在这种情况下绝对可以忽略不计。
这是NDEBUG和my_max_element在std::max_element之前的结果。iter/array ratio: = 0.995192，这对标准库来说是一个非常微薄的胜利。
使用g++4.8和-O2时，差异消失了(两个时间都与-O3的std::max_element的时间一致)；正是优化器带来了一些奇怪的技巧。
这也许可以很好地解释为什么会发生这种情况。
如果使用带有随机元素的数组，会发生这种情况吗？
您的计时代码实现了灾难性的取消，这使得整个问题毫无意义。请正确处理时间值(并且，按有意义的比例执行，而不在计划程序的变化范围内)。也就是说，不要做任何类似的事情，比如减去两个几乎相同的浮点/双精度值，也不要在时间上使用双精度值。另外，做运行时间至少为2-3秒(最好是10或20秒)而不是几微秒的基准测试。一个中断或类似的情况很容易导致你看到的东西。
@达蒙：不是真的。运行基准x次，中断偏差可以忽略不计。另外，Double还有52位精度，这使得它们非常适合存储32位的电视测量时间。
@Xryl669：一点也不。浮点运算使用的是2的幂，而10e-6不是2的幂，因此与之相乘并不是很好，因为它会失去精度。另外，减去两个几乎相同的数字(仅在第5位不同)会失去精度。因此，这些测量结果完全是假的。网上有很多关于这个的文章。每一个测量的差异可能是真实的、随机的、舍入/灾难性的取消、调度抖动或其他不同的东西。你看不出来。在你开始之前，任何精确的测量都不会失去其他一切。
@angew，libstdc++不在任何地方使用assert，NDEBUG不会影响它。

在对该答案进行投票之前，请在您的计算机上测试(并验证)并评论/添加结果。注意，我的测试使用了1000*1000*1000的向量大小。目前，这个答案有19个赞成票，但只有一个公布的结果，这些结果没有显示下面描述的效果(虽然获得了不同的测试代码，见评论)。

似乎存在优化器错误/工件。比较以下时间：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

template<typename _ForwardIterator, typename _Compare>
_ForwardIterator
my_max_element_orig(_ForwardIterator __first, _ForwardIterator __last,
_Compare __comp)
{
if (__first == __last) return __first;
_ForwardIterator __result = __first;

while(++__first != __last)
if (__comp(__result, __first))
__result = __first;

return __result;
}

template<typename _ForwardIterator, typename _Compare>
_ForwardIterator
my_max_element_changed(_ForwardIterator __first, _ForwardIterator __last,
_Compare __comp)
{
if (__first == __last) return __first;
_ForwardIterator __result = __first;
++__first;

for(; __first != __last; ++__first)
if (__comp(__result, __first))
__result = __first;

return __result;
}

第一个是最初的libstdc++实现，第二个应该是一个没有任何行为或需求变化的转换。clang++为这两个函数生成非常相似的运行时间，而G++4.8.2的运行速度是第二个版本的四倍。

根据Maxim的建议，将矢量从int改为int64_t，修改后的版本不是4，而是比原来的版本(g++4.8.2)快1.7倍。

区别在于*result的预测通用性，即存储当前max元素的值，这样就不必每次从内存中重新加载它。这就提供了一个更清晰的缓存访问模式：

1
2
3
4
5
6
7
8

w/o commoning with commoning
* *
** *
** *
** *
* * *
* * *
* * *

下面是用于比较的asm(rdi/rsi分别包含第一个/最后一个迭代器)：

使用while循环(2.88743 ms；gist)：

1
2
3
4
5
6
7
8
9
10

movq %rdi, %rax
jmp .L49
.L51:
movl (%rdi), %edx
cmpl %edx, (%rax)
cmovl %rdi, %rax
.L49:
addq $4, %rdi
cmpq %rsi, %rdi
jne .L51

对于for循环(1235.55μs)：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

leaq 4(%rdi), %rdx
movq %rdi, %rax
cmpq %rsi, %rdx
je .L53
movl (%rdi), %ecx
.L54:
movl (%rdx), %r8d
cmpl %r8d, %ecx
cmovl %rdx, %rax
cmovl %r8d, %ecx
addq $4, %rdx
cmpq %rdx, %rsi
jne .L54
.L53:

如果在开始时和更新result时，我强制将*result显式存储到变量prev中，并且在比较中使用prev而不是*result，我会得到更快的循环(377.601μs)：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

movl (%rdi), %ecx
movq %rdi, %rax
.L57:
addq $4, %rdi
cmpq %rsi, %rdi
je .L60
.L59:
movl (%rdi), %edx
cmpl %edx, %ecx
jge .L57
movq %rdi, %rax
addq $4, %rdi
movl %edx, %ecx
cmpq %rsi, %rdi
jne .L59
.L60:

这比for循环更快的原因是，上面的条件移动(cmovl)是悲观的，因为它们很少执行(Linus说，如果分支不可预测，cmov只是一个好主意)。请注意，对于随机分布的数据，分支预计取h_{n_{times，这是一个可忽略的比例(h_{n_{以对数方式增长，因此h_{n_{/n快速接近0)。条件移动代码只在病理数据上更好，例如[1，0，3，2，5，4，…]。}}}}}}

相关讨论

如果您可以在不同的machine/g++版本上运行此程序，请评论/添加您的结果。
我在测试中使用了1000*1000*1000元素，但我不太相信OP的测量代码。每项测试都进行了几次，并按正常+相反的顺序进行。
我对G++4.8.2没有这样的区别。我马上把结果贴出来。
我有这个：manwe.rmf.io:9876/max_element.html
@R.Martinhofernandes有趣。我以前没有使用过nonius；我下载了git repo，包括nonius/main，并使用了nonius/nonius.h++头文件。向量大小为1000*1000*1000时，平均值为54.12 ns，而向量大小为34.06 ns；对于这两种情况，"异常值严重夸大了方差"。
"异常值严重夸大了方差"通常是一个信号，表明结果可能会受到外部因素的影响(但现在我怀疑我在这个逻辑中有一个错误，因为"发现0个异常值[…]异常值严重夸大了方差"是没有意义的；)但这不是主题。关键是我无法重现你所经历的那种差异。我认为我们需要查看生成的程序集。
@R.Martinhofernandes同意"我认为我们需要看看生成的组件"。我做了一些额外的测试，因为你稍微改变了函数模板，得到了一个不同的方法。在使用局部与命名空间范围lambda谓词时，我还得到了第三组不同的值。--这是一个有目的的社区wiki，可以随意添加一些程序集(我在程序集方面没有太多经验，更不用说优化程序或nonius了)。如果这确实是一个优化器问题，那么当嵌入到nonius中时，它可能会消失。
我以后再看一看，再加上我发现的。Sorta现在很忙：)
@R.Martinhofernandes偏离主题："Harward Information"(看起来像个打字错误)
哦，谢谢。这是一个非常实验性的特性。
提示将差异本地化，已在注释中提到：-fno-tree-vectorize。请不要忘记在某个时候向海湾合作委员会的Bugzilla报告。
GCC-4.9.1，英特尔酷睿i5：平均2.88743毫秒，1235.55μs。我正在使用函数指针来防止内联和volatile，以防止没有op消除；这将导致测试主体具有相同的asm，而不是对max_元素函数的精确调用。
@Dyp如果你看到ns，我认为这个循环是不可阻挡的。尝试使用volatile来防止出现这种情况：gist.github.com/ecatmur/8c0b50dc4e30e1206a98 file-max诳elemen&zwnj；&误8203；t-c
@r.martinhofernandes我试过了你的代码，但电话没有中断；我不得不添加volatile:gist.github.com/ecatmur/8c0b50dc4e30e1206a98 file-max诳elemen&zwnj；&误8203；t-c
啊！我尝试了1000*1000*100个元素的代码，结果是240 ms/100 ms/30 ms，G++4.8.2，Intel Xeon E3；原始的1<<20个元素，结果是2.5 ms/1 ms/0.3 ms，谢谢您的贡献。

您可能在64位模式下运行测试，其中sizeof(int) == 4，但sizeof(std::vector<>::iterator) == 8，因此循环中分配给int(my_max_element所做的)比std::vector<>::iterator更快(这是std::max_element所做的)。

如果将std::vector改为std::vector结果改为std::max_element有利：

1
2
3
4
5

MaxIter = 1000000012
MaxArray = 1000000012
Total CPU time iterator = 0.00429082
Total CPU time array = 0.00572205
iter/array ratio: = 0.749875

一个重要的注意事项是：当基准测试禁用CPU频率缩放时，CPU不会在基准测试中间切换档位。

但我认为这里还有其他一些因素在起作用，因为仅仅将循环变量从int更改为long不会改变结果…

相关讨论

这是缓存的一个简单问题。也就是说，第一次加载内存时，在本例中是向量的内容，它总是比最近访问时慢得多。我用GCC4.9复制并粘贴了您的代码。

当函数反转时，比率为1。当它们按原始顺序排列时，比率为1.6。

对于我来说，在max_元素的情况下，这仍然是gcc的一个基本错误优化。但是，您的功能时间非常短，它们将由CPU噪声控制，如上面的缓存效果，而不是任何有意义的比较。

反转，原始

相关讨论