极客时间已完结课程限时免费阅读

33|性能测试的正确姿势:性能、时间和优化

33|性能测试的正确姿势:性能、时间和优化-极客时间

33|性能测试的正确姿势:性能、时间和优化

讲述:吴咏炜

时长18:15大小16.67M

你好,我是吴咏炜。
在上一讲讲完后,原本计划是要聊一聊内存池的。不过,要说内存池的好坏,就得讨论性能,而之前并没有专门讲过性能测试这个话题。鉴于这个问题本身有一定的复杂性,我们还是先专门用一讲讨论一下性能测试的相关问题。

意外的测试结果

假设你想测试一下,memset 究竟有没有性能优势。于是,你写下了下面这样的测试代码:
#include <stdio.h>
#include <string.h>
#include <time.h>
int main()
{
constexpr int LOOPS = 10000000;
char buf[80];
clock_t t1;
clock_t t2;
t1 = clock();
for (int i = 0; i < LOOPS; ++i) {
memset(buf, 0, sizeof buf);
}
t2 = clock();
printf("%g\n", (t2 - t1) * 1.0 /
CLOCKS_PER_SEC);
t1 = clock();
for (int i = 0; i < LOOPS; ++i) {
for (size_t j = 0;
j < sizeof buf; ++j) {
buf[j] = 0;
}
}
t2 = clock();
printf("%g\n", (t2 - t1) * 1.0 /
CLOCKS_PER_SEC);
}
然后你运行一下,啊哈,使用 memset 要快出 50 倍以上!
0.044433
2.53513
好奇如你,也许就会想到,开启优化会不会有区别呢?于是,你加上了 -O2 命令行选项。在某些编译器上,你可能会对类似下面的结果目瞪口呆的:
2e-06
1e-06
memset 更慢?优化比不优化快了一百万倍?编译器这是疯掉了吗?😱
到了这里,我们需要复习一下第 20 讲里关于内存模型和优化的这两句话:
为了优化的必要,编译器是可以调整代码的执行顺序的。唯一的要求是,程序的“可观测”外部行为是一致的。
当时我这么写是要说明,单线程下正确的行为可能到了多线程就有问题。但从性能测试的角度,即使单线程也一样会遇到鬼!编译器非常聪明,它看到了:你往内存里写数据了,又没有使用写到内存的数据;同时这是本地变量,你也没有把变量的引用或指针传到其他地方去。所以,外界不会观测到数据的改变。没人看到的东西,干吗需要存在?于是乎,编译器就把写内存的代码彻底优化没了,没了……
你模模糊糊想起来,volatile 关键字可以影响编译器优化。那加上这个关键字是不是有效呢?经过一番折腾,你把代码改成了下面这个样子:
volatile char buf[80];
for (int i = 0; i < LOOPS; ++i) {
memset(const_cast<char*>(buf),
0, sizeof buf);
}
运行之后,可能得到下面这样的结果:
0.104638
0.467247
哈,这就合理多了!看起来,我们可以得出结论,memset 确实比手工填充数据要快不少啊。
不过,这个结论真的正确吗?
答案为否。
volatile 关键字确实阻止了编译器优化。但这回它反向影响了。volatile 在 C++ 里的语义是,严格按照代码的指示对内存进行读写:你写一次,编译器就产生相应写的代码;你读一次,编译器就产生相应读的代码——一个不多,一个不少。这就导致了对内存操作的性能劣化。通常,你只在进行内存映射的输入输出时才有这么用的必要。
如果不用 volatile,那编译器至少在理论上是可以对上面的代码做出更好的优化的。我们把 buf 改成一个普通的全局变量,就能测到一个更接近真实的效果了。我们可以看到,GCC 和 Clang 都做出了更好的优化,对 memset 和循环清零产生了完全相同的代码。GCC 在 Core i7 架构(-march=corei7)上产生的汇编代码如下(参见 https://godbolt.org/z/xeohT4v1P):
pxor xmm0, xmm0
movaps XMMWORD PTR buf[rip], xmm0
movaps XMMWORD PTR buf[rip+16], xmm0
movaps XMMWORD PTR buf[rip+32], xmm0
movaps XMMWORD PTR buf[rip+48], xmm0
movaps XMMWORD PTR buf[rip+64], xmm0
也就是说,编译器洞察了你要做的事情是往 buf 里写入 80 个零,因而采取了最高效的方式,一次写 16 个零,连写五次,根本就没有循环了……

如何进行性能测试

我上面给出了答案,但我忽略了一些测试细节。很遗憾,这个问题真的有点复杂。我们现在再回过来讨论一下。

内存屏障问题

使用全局变量并不意味着我们一定就能测到真实数据。以上面的这个测试为例,虽然编译器看到我们往全局变量写入,就一定不可能把写入完全忽略掉,但它完全可能会做一些写入的合并。事实上,实测下来 Clang 就做了写入的合并,因此测试的结果数据看起来比 GCC 和 MSVC 要漂亮很多。从测试上面两种写法的区别上讲,问题还不算大,但如果我们想拿这个数据来计算代码的性能数据的话,那就要了命了。
一种可能的解法是加入内存屏障,告诉编译器到现在为止的内存修改都得给我完成了。全局锁就是一种通用的内存屏障,但在上面的代码里加入全局锁的话,加解锁的开销就会完全掩盖我们要测试部分的开销了。每种处理器架构都有自己的内存屏障指令,这比 C++ 或操作系统的锁要轻量一点,但对于我们上面的测试来讲,仍然是重了(约 10 倍的性能下降)。每一种编译器,基本上也都有非标准的轻量级内存屏障指令,只影响编译器优化,而不影响 CPU 的处理性能。
最后一种方式看起来最有希望,但遗憾的是,在我们上面的例子里,加入内存屏障本身会影响 GCC 产生的代码。仅针对目前的代码,我们可以写出下面这样一个内存屏障的函数:
#ifdef _MSC_VER
#include <intrin.h>
#endif
inline void memory_fence()
{
#ifdef _MSC_VER
_ReadWriteBarrier();
#elif defined(__clang__)
__asm__ __volatile__("" ::: "memory");
#endif
}
然后我们在测试代码后调用这个函数,确保对内存的写入会生效。注意我们仍需使用全局变量作为写入目标才行。
这种解法的问题是,它实在太脆弱了。从原理上来讲,它能不能工作并没有任何人可以保证。对于一个新的编译器,代码很可能会无效;对于当前工作的编译器的一个新版本,代码也可能会变为无效……
目前最可靠也最跨平台的解决方案仍然是用锁。如果想使用锁,我们需要有一种比 clock() 精度高得多的测量时间的办法。

时间测量问题

不同的平台有不同的时间测量函数。具体的细节我就不讨论了,直接给出我的测试结果。
Linux:
Windows:
精度的测量是取当函数返回的数值变化时的差值。当连续调用某一个计时函数时,它返回的结果是可能不变的。当它变化时,变化的数值就是它的测时精度。表中展示的就是这些精度测量结果的平均值(及方差,如果测试结果不完全一样的话)。
精度受 API 设计的影响,也受函数实现的影响。比如,Windows 上定义 CLOCKS_PER_SEC 为 1000,显然 clock() 也就不可能获得高于一毫秒的精度了。C++11 的三种时钟从目前实现的接口上来看都允许实现一纳秒的精度,但实际精度则要远远低于一纳秒。
测试结果当然跟具体的硬件也可能有关系,但至少这里可以看到一些基本的共性:
首先,clock() 函数不是个好选择,它的精度可能很差,本身耗时也可能会比较长。
其次,C++11 带来的三种时钟不管是精度还是自身开销都还算不错。既然其他方面没有区别,我们就选择使用能提供稳定增长保证的 steady_clocksystem_clock 是不稳定的,系统时间被调整时,时钟返回的数值也会变化;high_resolution_clock 的稳定性在标准中没有进行规定)[1]
最后,如果时间戳计数器(Time Stamp Counter [2])可用的话,它能提供最高的精度和最短的耗时。它是处理器上的硬件计数器,精度高,速度快,在多核系统上也能提供正确的读数;但在多 CPU 插槽的系统上则不一定能提供相应的保证,因而在那种情况下可能需要把测试程序绑定到某个核上运行。
rdtsc 返回的数值单位是时钟周期数(但频率可能跟处理器的实际运行频率不同)。上表中测量各个函数的耗时用的就是 rdtsc
我目前在代码库里加入了 rdtsc.h 文件。它的实现就是优先使用 x86 和 x86-64 平台提供的 rdtsc 的实现,在找不到时转而使用 stead_clock 作为替代。有兴趣的可以自行查看。
额外提一句,我这边讲的性能测试是微观层面的测试,即所谓的 microbenchmarking,一般以函数为单位。这种测试是单线程的,需要干扰尽可能少。可能的干扰有:
其他的应用程序——应尽可能关闭其他应用,尤其是会耗 CPU 的。
处理器的自动频率变化——最好关闭这类功能,如 Intel 的 Turbo Boost。
不同性能核之间的迁移——如果你的测试系统上有所谓的大小核,而你又没办法把程序绑定到某个核上面的话,那这样的系统不适合用来做微观层面的性能测试。

通用测试方法

下面我们讨论一种我个人经常使用的通用的性能测试方法。由于编译器的很多优化机制并不能由代码来控制,这也只能算是一种最佳实践而已。根据你的特定平台,也许你可以找出更好的测试方法。
我的基本方法是:
把待测的代码放到一个函数里,这样容易消除一些其他干扰。
可选地,把这个函数用 __attribute__((noinline)) [3]__declspec(noinline) [4] 标注为不要内联。
确保有一个依赖函数执行结果的数值会被写到某个全局变量里。根据代码的规模和组织,可以直接在这个函数里写入,或者通过外部传入的一个全局变量的指针或引用来写入。
在函数的开头和结尾测量时间,并把测得的时长累加到某个地方。
在循环里反复调用被测函数,并在每次调用函数前后进行加解锁,产生内存屏障。
比如,memset 的测试代码可能就会变成这个样子:
char buf[80];
uint64_t memset_duration;
std::mutex mutex;
void test_memset()
{
uint64_t t1 = rdtsc();
memset(buf, 0, sizeof buf);
uint64_t t2 = rdtsc();
memset_duration += (t2 - t1);
}
int main()
{
constexpr int LOOPS = 10000000;
for (int i = 0; i < LOOPS; ++i) {
std::lock_guard guard{mutex};
test_memset();
}
printf("%g\n", memset_duration * 1.0 / LOOPS);
}
使用这种方法,我们确实可以验证出在 GCC 和 Clang 下,两种清零方法在缓冲区大小已知的情况下可以获得相同的性能(如果大小要运行时才能决定,那就是另外一个需要单独测试的问题了)。

一个小测试框架

利用 RAII(第 1 讲),我们可以使用一个框架把代码再整理一下,使得测试更加简单和自动。这个框架比较简单,设计和实现我就不讲了。下面给你简单介绍一下它的使用。
对于当前的例子,首先我们需要声明两个待测函数的索引:
enum profiled_functions {
PF_TEST_MEMSET,
PF_TEST_PLAIN_LOOP,
};
然后,我们需要声明函数索引和函数名的关系:
name_mapper name_map[] = {
{PF_TEST_MEMSET, "test_memset"},
{PF_TEST_PLAIN_LOOP, "test_plain_loop"},
{-1, nullptr}};
对于待测函数,我们需要在函数开头插入一行代码,表示要对这个函数进行性能测试(利用一个 RAII 对象):
void test_memset()
{
PROFILE_CHECK(PF_TEST_MEMSET);
memset(buf, 0, sizeof buf);
}
这样就行了。下面输出的代码也不需要了,程序会在最后进程退出的时候自动打印汇总测试数据(利用另外一个 RAII 对象),如下所示:
0 test_memset:
Call count: 10000000
Call duration: 240756468
Average duration: 24.0756
1 test_plain_loop:
Call count: 10000000
Call duration: 241429159
Average duration: 24.1429
完整代码请参考 GitHub 上的代码库。如果想检查不同架构下的性能差异的话,可以在 cmake 命令行上指定编译器和附加参数,如:
CXX='g++ -march=corei7' cmake …
此外,需要说明一下,跟 assert 类似,PROFILE_CHECK 宏在 NDEBUG 宏被定义时就不生效了。所以,上面的输出在使用了 cmake -DCMAKE_BUILD_TYPE=Release … 时就不会有了。
最后,注意我举这个例子,主要是为了说明测试的复杂性和测试的方法。对于这个例子本身,由于代码简单、运行时间非常短,测试带来的额外开销过大,因而检查汇编输出可能是最好的检查性能的方式。显然,对于更大更复杂的代码,从汇编代码推断性能就困难多了。在那时候,类似目前的测试框架这样的代码就会非常有用。

浅谈优化的问题

今天提到的测试困难,很大程度上都是 C++ 编译器的优化造成的。事实上,C++ 里很多未定义行为之所以成为未定义行为,也是跟性能有关的。为了追求性能,C++ 编译器是可谓无所不用其极。有些人觉得编译器忽略了人的意图,感到很不爽,但事实是,C++ 编译器在优化方面确实比大部分程序员做得更好。这也是现在基本上没人写汇编的原因——即使不考虑可移植性,在某一特定平台上要写出超过 C++ 编译器水平的汇编代码,也已经越来越困难了。
但这种优化,虽然常常对程序有好处,也常常是违背程序员的直觉的。我这里另外举两个简单的例子,来说明一下为什么 C++ 编译器需要违反程序员的直觉。

优化和未定义行为

假如我们有一个 int 类型的变量 x,那 x * 2 / 2 的结果是几?
如果 C++ 把有符号整数运算溢出的结果定义为补码的内存表示,也就是说,32 位正整数 0x40'00'00'00)乘以 2 的结果就是 0x80'00'00'00),再除以 2 的话,我们就不能得回原先的数值,而是得到了 0xC0'00'00'00)。这样的话,x * 2 / 2 就不能优化为 x
那能不能使用异常呢?也不行。跟除零不一样,整数运算溢出不会产生硬件中断。而如果我们在每条加法、减法、乘法、除法(对,除法也可能溢出—— INT_MIN / -1 就会)上都加入指令来检查是否发生溢出、并在发生溢出时报告异常的话,性能的退步将是不可接受的 [5]
所以,C++ 的处理方式就是,规定有符号整数运算溢出为未定义行为 [6],即程序员需要保证这种情况不会发生,否则后果自负。这在允许编译器把 x * 2 / 2 优化成 x 的同时,也意味着,下面这样的代码返回的结果可能会跟程序员预想的不同(参见 https://godbolt.org/z/Ex5ad6vM9):
bool test(int n)
{
return (n + 1) == INT_MIN;
}
你想的是,如果 n + 1 溢出了,应该会得到 INT_MIN 这个特殊的结果。但编译器可以认为溢出是永远不会发生的(因为正确的程序里不应该有未定义行为),因此可以直接返回 false。——这也是实际可以在 GCC 和 Clang 上测到的结果。

优化和执行顺序

假设我们有三个全局 int 变量 xya,然后我们执行下面的代码:
x = a;
y = 2;
那是不是编译器会产生先写入 x、再写入 y 的代码呢?
我想你猜到了,答案为“不一定”。下面是某些编译器实际产生的汇编代码(参见 https://godbolt.org/z/zsfvsf63E):
mov eax, DWORD PTR a
mov DWORD PTR y, 2
mov DWORD PTR x, eax
我们可以看到,编译器产生的代码是:先读入 a,再写入 y,最后写入 x
为什么要这样?一样,是因为优化。读入 a 的数值到 eax 寄存器里,跟写入 2 到 y 里是两个不相关操作,可以同时执行。这样的代码,比起完全按程序员指定的执行顺序产生的代码,可望得到更高的性能。

内容小结

本讲我们通过一个小例子,讨论了优化跟性能测试的一些问题。希望你在学完这一讲之后,能够了解优化对代码和测试产生的影响,并能正确地测试代码的性能。

课后思考

请尝试修改代码,让编译器没法在编译期得到需要清零的数据块大小。测试这种情况下的性能。(提示:你这次需要上面讲到的要求不内联的标注了。)
如果对结果有疑惑,建议使用 Compiler Explorer 网站(第 21 讲有介绍)或编译器生成汇编代码(-S/Fa)的选项来仔细检视一下。
如果有任何疑问,欢迎留言和我讨论。

参考资料

[1] cppreference.com, “Date and time utilities – Clocks”. https://en.cppreference.com/w/cpp/chrono#Clocks
[1a] cppreference.com, “日期和时间工具 – 时钟”. https://zh.cppreference.com/w/cpp/chrono#.E6.97.B6.E9.92.9F
[2] Wikipedia, “Time Stamp Counter”. https://en.wikipedia.org/wiki/Time_Stamp_Counter
[3] GCC, “GCC 11.2 Manual – Common Function Attributes”. https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Common-Function-Attributes.html
[5] Will Dietz, Peng Li, John Regehr, and Vikram Adve, “Understanding Integer Overflow in C/C++”. https://www.cs.utah.edu/~regehr/papers/overflow12.pdf
[6] cppreference.com, “Undefined behavior”. https://en.cppreference.com/w/cpp/language/ub
[6a] cppreference.com, “未定义行为”. http://zh.cppreference.com/w/cpp/language/ub
分享给需要的人,Ta购买本课程,你将得18
生成海报并分享

赞 3

提建议

上一篇
32|容器里的内存管理:分配器
下一篇
34|快速分配和释放内存:内存池
 写留言

精选留言(2)

  • 王旧业
    2022-11-02 来自陕西
    原来UB还有积极正向的作用,以前没考虑过这种
  • 禾桃
    2022-04-23
    “clock_gettime精度是0.0265微秒” 也就是26.5纳秒 请问,如果Clock_gettime返回值是到纳秒,两次取时间的差值如果是15纳秒(小于26.5纳秒),是不是意味着这个15纳秒其实手机不准确的,因为精度是26.5纳秒,远大于15纳秒。
    展开

    作者回复: 差值是15纳秒,那精度显然就是15纳秒了(如果稳定的话)。事实上,对于这个函数,精度就是它的耗时——表达能力已经足够高了。