gpt4 book ai didi

c++ - 不同机器之间标准时钟的显着性能差异

转载 作者:IT老高 更新时间:2023-10-28 22:05:35 25 4
gpt4 key购买 nike

测试其他东西我偶然发现了一些我还没有弄清楚的东西。

让我们看看这个片段:

#include <iostream>
#include <chrono>

int main () {
int i = 0;
using namespace std::chrono_literals;

auto const end = std::chrono::system_clock::now() + 5s;
while (std::chrono::system_clock::now() < end) {
++i;
}
std::cout << i;
}

我注意到计数在很大程度上取决于我执行它的机器。
我用 gcc 7.3,8.2 和 clang 6.0 用 std=c++17 -O3 编译过。

在 i7-4790(4.17.14-arch1-1-ARCH 内核)上:~3e8
但在 Xeon E5-2630 v4 (3.10.0-514.el7.x86_64) 上:~8e6

现在这是我想了解的差异,所以我检查了 perf stat -d

在 i7 上:

       4999.419546      task-clock:u (msec)       #    0.999 CPUs utilized          
0 context-switches:u # 0.000 K/sec
0 cpu-migrations:u # 0.000 K/sec
120 page-faults:u # 0.024 K/sec
19,605,598,394 cycles:u # 3.922 GHz (49.94%)
33,601,884,120 instructions:u # 1.71 insn per cycle (62.48%)
7,397,994,820 branches:u # 1479.771 M/sec (62.53%)
34,788 branch-misses:u # 0.00% of all branches (62.58%)
10,809,601,166 L1-dcache-loads:u # 2162.171 M/sec (62.41%)
13,632 L1-dcache-load-misses:u # 0.00% of all L1-dcache hits (24.95%)
3,944 LLC-loads:u # 0.789 K/sec (24.95%)
1,034 LLC-load-misses:u # 26.22% of all LL-cache hits (37.42%)

5.003180401 seconds time elapsed

4.969048000 seconds user
0.016557000 seconds sys

至强:

       5001.000000      task-clock (msec)         #    0.999 CPUs utilized          
42 context-switches # 0.008 K/sec
2 cpu-migrations # 0.000 K/sec
412 page-faults # 0.082 K/sec
15,100,238,798 cycles # 3.019 GHz (50.01%)
794,184,899 instructions # 0.05 insn per cycle (62.51%)
188,083,219 branches # 37.609 M/sec (62.49%)
85,924 branch-misses # 0.05% of all branches (62.51%)
269,848,346 L1-dcache-loads # 53.959 M/sec (62.49%)
246,532 L1-dcache-load-misses # 0.09% of all L1-dcache hits (62.51%)
13,327 LLC-loads # 0.003 M/sec (49.99%)
7,417 LLC-load-misses # 55.65% of all LL-cache hits (50.02%)

5.006139971 seconds time elapsed

出现的是 Xeon 上每个周期的低指令量以及我不理解的非零上下文切换。但是,我无法使用这些诊断来做出解释。

为了让问题更奇怪,在尝试调试时,我还在一台机器上静态编译并在另一台机器上执行。

在 Xeon 上,静态编译的可执行文件的输出降低了约 10%,而在 Xeon 或 i7 上编译没有区别。
在 i7 上做同样的事情,计数器实际上从 3e8 下降到 ~2e7

所以最后我有两个问题:

  • 为什么我看到两台机器之间有如此显着的差异。
  • 为什么静态链接的可执行文件执行得更差,而我期望相反?

编辑:在将 centos 7 机器上的内核更新到 4.18 后,我们实际上看到了从 ~ 8e65e6 的额外下降。

虽然有趣的是,perf 显示了不同的数字:

   5002.000000      task-clock:u (msec)       #    0.999 CPUs utilized          
0 context-switches:u # 0.000 K/sec
0 cpu-migrations:u # 0.000 K/sec
119 page-faults:u # 0.024 K/sec
409,723,790 cycles:u # 0.082 GHz (50.00%)
392,228,592 instructions:u # 0.96 insn per cycle (62.51%)
115,475,503 branches:u # 23.086 M/sec (62.51%)
26,355 branch-misses:u # 0.02% of all branches (62.53%)
115,799,571 L1-dcache-loads:u # 23.151 M/sec (62.51%)
42,327 L1-dcache-load-misses:u # 0.04% of all L1-dcache hits (62.50%)
88 LLC-loads:u # 0.018 K/sec (49.96%)
2 LLC-load-misses:u # 2.27% of all LL-cache hits (49.98%)

5.005940327 seconds time elapsed

0.533000000 seconds user
4.469000000 seconds sys

有趣的是,没有更多的上下文切换,每个周期的指令显着增加,但周期和 colck 非常低!

最佳答案

感谢@Imran 上面的评论,我已经能够在两台机器上重现各自的测量值。 (发布此答案以结束问题,如果 Imran 应该发布一个我很乐意接受他的答案)

确实与可用的时钟源有关。不幸的是,XEON 在其内核参数中有 notsc 标志,这就是为什么 tsc 时钟源不可用和选择的原因。

因此对于遇到此问题的任何人:
1. 在/sys/devices/system/clocksource/clocksource0/current_clocksource
中检查你的时钟源2. 查看/sys/devices/system/clocksource/clocksource0/available_clocksource
中可用的时钟源3.如果找不到tsc,检查dmesg | grep tsc 检查你的内核参数 notsc

关于c++ - 不同机器之间标准时钟的显着性能差异,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/51872518/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com