L P*_*ari 2 c++ linux cpu intel cpu-architecture
我强调我的系统，看看它如何影响我使用stress-ng编写的一些程序。
程序本身是一个神经网络，主要由一些嵌套循环组成，进行一些乘法运算，并使用大约 1G 的 RAM 整体用 C++ 编码。
我使用以下方法对系统施加了一些内存压力：
stress-ng --vm 4 --vm-bytes 2G -t 100s
这会创建 4 个工作人员在 mmap 上旋转，每个工作人员分配 2G 的 RAM。这显着减慢了我的程序的执行速度（从大约 150 毫秒到 250 毫秒）。但是程序变慢的原因不是缺少内存或内存带宽之类的。相反，CPU 周期从 3.4GHz（无压力 ng）减少到 2.8GHz（有压力 ng）。正如预期的那样，CPU 利用率保持大致相同 (99%)。
我使用以下方法测量了 CPU 频率
sudo perf stat -B ./my_program
有人知道为什么内存压力会降低 CPU 的速度吗？
我的 CPU 是 Intel(R) Core(TM) i5-8250U，我的操作系统是 Ubuntu 18.04。
亲切的问候 lpolari
Skylake 衍生的 CPU 在加载/存储瓶颈时会降低其核心时钟速度，在能源与性能设置有利于更省电。令人惊讶的是，您可以构建人为的情况，即使存储全部命中 L1d 缓存，或者从未初始化的内存（仍然 CoW 映射到相同的零页），也会发生这种降频。
Skylake 引入了 CPU 频率的全硬件控制（硬件 P 状态 = HWP）。https://unix.stackexchange.com/questions/439340/what-are-the-implications-of-setting-the-cpu-governor-to-performance 频率决策可以考虑内部性能监控，它可以注意到诸如花费大多数周期停滞，或者它停滞在什么地方。我不知道 Skylake 到底使用了什么启发式方法。
您可以通过循环遍历一个大数组而不进行任何系统调用来重现这个1。如果它很大（或者您在人工测试中跨过缓存线），perf stat ./a.out将显示平均时钟速度低于正常的 CPU 绑定循环。
理论上，如果内存完全跟不上 CPU，降低核心时钟速度（并保持内存控制器恒定）应该不会对性能造成太大影响。实际上，降低时钟速度也会降低非核心时钟速度（环形总线 + L3 缓存），也会在一定程度上恶化内存延迟和带宽。
缓存未命中的部分延迟是获取从 CPU 内核到内存控制器的请求，而单核带宽受最大并发（一个内核可以跟踪的未完成请求）/延迟的限制。 为什么 Skylake 在单线程内存吞吐量方面比 Broadwell-E 好得多？
例如，我的 i7-6700k 在运行微基准测试时从 3.9GHz 下降到 2.7GHz，该测试仅在默认启动设置下在 DRAM 上出现瓶颈。（此外，它只能达到 3.9GHz，而不是 4.0 全核或 4.2GHz，如 BIOS 中配置的 1 或 2 个内核处于活动状态balance_power，启动时或使用默认EPP 设置balance_performance。）
这个默认值似乎不太好，对于“客户端”芯片来说太保守了，其中单核几乎可以使 DRAM 带宽饱和，但只能在全时钟速度下使用。或者在节能方面过于激进，如果您从另一个 POV 来看，尤其是对于像我的台式机这样具有高 TDP (95W) 的芯片，即使在运行 x265 视频编码等耗电量大的东西时也可以无限期地维持全时钟速度。 AVX2。
它可能使一个ULV 15W芯片更有意义喜欢你i5-8250U，试图离开时，CPU的更热/功率余量是做一些更有趣。
这取决于他们的能源/性能偏好 (EPP) 设置。它在默认balance_power设置下发生得相当强烈。它根本不会发生performance，一些快速的基准测试表明，这balance_performance也避免了这种节能减慢。我balance_performance在我的桌面上使用。
Ice Lake 之前的“客户端”（非至强）芯片将所有内核锁定在一起，因此它们以相同的时钟速度运行（如果其中一个运行不受内存限制的东西，例如while(1) { _mm_pause(); }循环，它们都会运行得更高）。但是每个逻辑核心仍然有一个 EPP 设置。我一直只是更改所有内核的设置以保持它们相同：
在 Linux 上，读取设置：
$ grep . /sys/devices/system/cpu/cpufreq/policy[0-9]*/energy_performance_preference
/sys/devices/system/cpu/cpufreq/policy0/energy_performance_preference:balance_performance
/sys/devices/system/cpu/cpufreq/policy1/energy_performance_preference:balance_performance
...
/sys/devices/system/cpu/cpufreq/policy7/energy_performance_preference:balance_performance
写入设置：
sudo sh -c 'for i in /sys/devices/system/cpu/cpufreq/policy[0-9]*/energy_performance_preference;
do echo balance_performance > "$i"; done'
也可以看看
x86_energy_perf_policy(8) 手册页每个缓存行存储 1 个双字，通过连续的缓存行前进直到缓冲区结束，然后将指针包装回开始。重复固定数量的存储，而不管缓冲区大小。
;; t=testloop; nasm -felf64 "$t.asm" && ld "$t.o" -o "$t" && taskset -c 3 perf stat -d -etask-clock,context-switches,cpu-migrations,page-faults,cycles,instructions,uops_issued.any,uops_executed.thread ./"$t"
;; nasm -felf64 testloop.asm
;; ld -o testloop testloop.o
;; taskset -c 3 perf stat -etask-clock,context-switches,cpu-migrations,page-faults,cycles,instructions,uops_issued.any,uops_executed.thread -r1 ./testloop
; or idq.mite_uops
default rel
%ifdef __YASM_VER__
; CPU intelnop
; CPU Conroe AMD
CPU Skylake AMD
%else
%use smartalign
alignmode p6, 64
%endif
global _start
_start:
lea rdi, [buf]
lea rsi, [endbuf]
; mov rsi, qword endbuf ; large buffer. NASM / YASM can't actually handle a huge BSS and hit a failed assert (NASM) or make a binary that doesn't reserve enough BSS space.
mov ebp, 1000000000
align 64
.loop:
%if 0
mov eax, [rdi] ; LOAD
mov eax, [rdi+64]
%else
mov [rdi], eax ; STORE
mov [rdi+64], eax
%endif
add rdi, 128
cmp rdi, rsi
jae .wrap_ptr ; normally falls through, total loop = 4 fused-domain uops
.back:
dec ebp
jnz .loop
.end:
xor edi,edi
mov eax,231 ; __NR_exit_group from /usr/include/asm/unistd_64.h
syscall ; sys_exit_group(0)
.wrap_ptr:
lea rdi, [buf]
jmp .back
section .bss
align 4096
;buf: resb 2048*1024*1024 - 1024*1024 ; just under 2GiB so RIP-rel still works
buf: resb 1024*1024 / 64 ; 16kiB = half of L1d
endbuf:
resb 4096 ; spare space to allow overshoot
测试系统：Arch GNU/Linux，内核 5.7.6-arch1-1。（以及 NASM 2.14.02，ld来自 GNU Binutils 2.34.0）。
balance_power，只能达到 3.9GHz。我的引导脚本更改为balance_pwerformance3.9GHz，因此风扇保持安静，但不那么保守。超线程已启用，但系统处于空闲状态，内核不会在另一个逻辑内核（我将其固定到的同级内核）上调度任何内容，因此它有一个物理内核。
然而，这意味着 perf 不愿意为一个线程使用更多的可编程 perf 计数器，因此perf stat -d要监视 L1d 负载和替换，而 L3 命中/未命中将意味着测量精度较低cycles，等等。它可以忽略不计，例如 424k L1-dcache-loads（可能在内核页面错误处理程序、中断处理程序和其他开销中，因为循环没有负载）。 L1-dcache-load-misses实际上L1D.REPLACEMENT甚至更低，例如 48k
我使用了一些性能事件，包括exe_activity.bound_on_stores-[存储缓冲区已满且没有未完成负载的周期]。（有关perf list说明和/或英特尔手册了解更多信息，请参阅）。
balance_power3.9GHz 之外的 2.7GHz 降频EPP 设置：balance_power与sudo sh -c 'for i in /sys/devices/system/cpu/cpufreq/policy[0-9]*/energy_performance_preference;do echo balance_power > "$i";done'
有是基于什么代码做节流; 在另一个核心上有一个暂停循环保持时钟高，这会在这段代码上运行得更快。或者在循环中使用不同的指令。
# sudo ... balance_power
$ taskset -c 3 perf stat -etask-clock:u,task-clock,context-switches,cpu-migrations,page-faults,cycles,branches,instructions,uops_issued.any,uops_executed.thread,exe_activity.bound_on_stores -r1 ./"$t"
Performance counter stats for './testloop':
779.56 msec task-clock:u # 1.000 CPUs utilized
779.56 msec task-clock # 1.000 CPUs utilized
3 context-switches # 0.004 K/sec
0 cpu-migrations # 0.000 K/sec
6 page-faults # 0.008 K/sec
2,104,778,670 cycles # 2.700 GHz
2,008,110,142 branches # 2575.962 M/sec
7,017,137,958 instructions # 3.33 insn per cycle
5,217,161,206 uops_issued.any # 6692.465 M/sec
7,191,265,987 uops_executed.thread # 9224.805 M/sec
613,076,394 exe_activity.bound_on_stores # 786.442 M/sec
0.779907034 seconds time elapsed
0.779451000 seconds user
0.000000000 seconds sys
碰巧，这恰好得到了 2.7GHz。通常会有一些噪音或启动开销，而且会低一些。请注意，5217951928 个前端 uops / 2106180524 个周期 = 每个周期发出 ~2.48 个平均 uops，管道宽度为 4，因此这不是低吞吐量代码。由于宏融合比较/分支，指令计数更高。（我可以展开更多，所以更多的说明是商店，更少的添加和分支，但我没有。）
（我重新运行了perf stat几次命令，所以 CPU 不只是在定时间隔开始时从低功耗睡眠中唤醒。间隔中仍然存在页面错误，但 6 个页面错误在 3/ 4 秒基准。）
balance_performance：全 3.9GHz，此 EPP 的最高速度没有基于代码正在做什么的限制。
# sudo ... balance_performance
$ taskset -c 3 perf stat -etask-clock:u,task-clock,context-switches,cpu-migrations,page-faults,cycles,branches,instructions,uops_issued.any,uops_executed.thread,exe_activity.bound_on_stores -r1 ./"$t"
Performance counter stats for './testloop':
539.83 msec task-clock:u # 0.999 CPUs utilized
539.83 msec task-clock # 0.999 CPUs utilized
3 context-switches # 0.006 K/sec
0 cpu-migrations # 0.000 K/sec
6 page-faults # 0.011 K/sec
2,105,328,671 cycles # 3.900 GHz
2,008,030,096 branches # 3719.713 M/sec
7,016,729,050 instructions # 3.33 insn per cycle
5,217,686,004 uops_issued.any # 9665.340 M/sec
7,192,389,444 uops_executed.thread # 13323.318 M/sec
626,115,041 exe_activity.bound_on_stores # 1159.827 M/sec
0.540108507 seconds time elapsed
0.539877000 seconds user
0.000000000 seconds sys
在时钟对时钟的基础上大致相同，尽管存储缓冲区已满的总周期略多。（那是在核心和 L1d 缓存之间，而不是在核心之外，所以我们期望循环本身大致相同。使用-r10重复 10 次，该数字在运行中稳定 +- 0.01%。）
performance：4.2GHz，全涡轮增压至最高配置频率没有基于代码正在做什么的限制。
# sudo ... performance
taskset -c 3 perf stat -etask-clock,context-switches,cpu-migrations,page-faults,cycles,instructions,uops_issued.any,uops_executed.thread -r1 ./testloop
Performance counter stats for './testloop':
500.95 msec task-clock:u # 1.000 CPUs utilized
500.95 msec task-clock # 1.000 CPUs utilized
0 context-switches # 0.000 K/sec
0 cpu-migrations # 0.000 K/sec
7 page-faults # 0.014 K/sec
2,098,112,999 cycles # 4.188 GHz
2,007,994,492 branches # 4008.380 M/sec
7,016,551,461 instructions # 3.34 insn per cycle
5,217,839,192 uops_issued.any # 10415.906 M/sec
7,192,116,174 uops_executed.thread # 14356.978 M/sec
624,662,664 exe_activity.bound_on_stores # 1246.958 M/sec
0.501151045 seconds time elapsed
0.501042000 seconds user
0.000000000 seconds sys
整体性能与时钟速度呈线性关系，因此与balance_power. （1.44balance_performance具有相同的 3.9GHz 全时钟速度。）
由于缓冲区足够大以导致 L1d 或 L2 缓存未命中，因此内核时钟周期仍然存在差异。
| 归档时间： |
|
| 查看次数： |
622 次 |
| 最近记录： |