我开发了一个高性能 Cholesky分解程序,它应该在单个CPU上具有大约10.5 GFLOP的峰值性能(没有超线程)。但是当我测试它的性能时,有一些我不明白的现象。在我的实验中,我通过增加矩阵维数N(从250到10000)来测量性能。
我希望无论我在测试什么N,性能(在GFLOP中)都应保持在10.5左右。但是在实验中间观察到显着的性能下降,如第一个图所示。
CPU频率和CPU温度见第2和第3位数字。实验在400年代结束。实验开始时温度为51度,CPU忙时迅速升至72度。之后,它慢慢增长到78度的最高点。 CPU频率基本稳定,温度升高时不会下降。
所以,我的问题是:
CPU信息
System: Ubuntu 14.04 LTS
Laptop model: Lenovo-YOGA-3-Pro-1370
Processor: Intel Core M-5Y71 CPU @ 1.20 GHz * 2
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0,1
Off-line CPU(s) list: 2,3
Thread(s) per core: 1
Core(s) per socket: 2
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 61
Stepping: 4
CPU MHz: 1474.484
BogoMIPS: 2799.91
Virtualisation: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 4096K
NUMA node0 CPU(s): 0,1
CPU 0, 1
driver: intel_pstate
CPUs which run at the same hardware frequency: 0, 1
CPUs which need to have their frequency coordinated by software: 0, 1
maximum transition latency: 0.97 ms.
hardware limits: 500 MHz - 2.90 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 500 MHz and 2.90 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 1.40 GHz.
boost state support:
Supported: yes
Active: yes
更新1(对照实验)
在我原来的实验中,CPU一直忙于工作,从N = 250到N = 10000.许多人(主要是那些在重新编辑之前看过这篇文章的人)怀疑CPU过热是性能受损的主要原因。然后我回去安装lm-sensors
linux软件包来跟踪这些信息,实际上,CPU温度上升了。
但为了完成图片,我做了另一个对照实验。这次,我给每个N之间的CPU一个冷却时间。这是通过要求程序在循环迭代开始时暂停几秒钟来实现的。
请注意,冷却时间远远大于计算所用的时间。对于N = 10000,在峰值性能下Cholesky分解只需要30s,但我要求60s冷却时间。
这在高性能计算中肯定是一种非常无趣的设置:我们希望我们的机器始终以最佳性能运行,直到完成一项非常大的任务。所以这种停顿毫无意义。但它有助于更好地了解温度对性能的影响。
这次,我们看到所有N都达到了峰值性能,正如理论支持一样! CPU频率和温度的周期性特征是冷却和提升的结果。温度仍然呈上升趋势,仅仅因为随着N的增加,工作负荷越来越大。正如我所做的那样,这也证明了冷却时间更长的冷却时间。
峰值性能的实现似乎排除了温度以外的所有影响。但这真的很烦人。基本上它说计算机会在HPC中累了,所以我们无法获得预期的性能提升。那么开发HPC算法有什么意义呢?
我不知道为什么我无法上传第6个数字。添加第6个数字时,我根本不允许我提交编辑。所以我很抱歉我无法附上CPU频率数字。
更新2(我如何测量CPU频率和温度)
感谢Zboson添加x86标签。以下bash
命令是我用于测量的命令:
while true
do
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq >> cpu0_freq.txt ## parameter "freq0"
cat sys/devices/system/cpu/cpu1/cpufreq/scaling_cur_freq >> cpu1_freq.txt ## parameter "freq1"
sensors | grep "Core 0" >> cpu0_temp.txt ## parameter "temp0"
sensors | grep "Core 1" >> cpu1_temp.txt ## parameter "temp1"
sleep 2
done
由于我没有将计算固定为1个核心,因此操作系统将交替使用两个不同的核心。采取
更有意义freq[i] <- max (freq0[i], freq1[i])
temp[i] <- max (temp0[i], temp1[i])
作为整体测量。
答案 0 :(得分:3)
TL:DR :您的结论是正确的。你的CPU的持续性能远未达到顶峰。这是正常的,因为峰值性能仅仅是作为其额定可持续性能之上的短期“奖金”。
根据您发布的CPU信息,您有一个dual-core-with-hyperthreading Intel Core M with a rated sustainable frequency of 1.20 GHz。它的最大涡轮增压为2.9GHz,它的TDP-up持续频率为1.4GHz。
因此,对于短暂的爆发,它可以更快地运行更多并且比它需要冷却系统处理更多的热量。这就是Intel's "turbo" feature的全部内容。它可以让像你这样的低功耗超便携笔记本电脑在网页浏览器等网页上有出色的UI性能,因为来自交互式的CPU负载几乎总是很大。
桌面/服务器CPU(Xeon和i5 / i7,但不是i3)仍然具有turbo功能,但持续频率很多更接近最大turbo。例如a Haswell i7-4790k的持续“额定”频率为4.0GHz。在该频率及以下频率下,它不会使用(并转换为热量)超过其额定TDP为88W。因此,它需要一个可以处理88W的冷却系统。当功率/电流/温度允许时,它可以高达4.4GHz的时钟并使用超过88W的功率。 (用于计算电源历史以保持持续功率为88W的滑动窗口有时可在BIOS中配置,例如20秒或5秒。根据运行的代码,4.4GHz可能不会将电流需求增加到接近峰值的任何地方。例如有很多分支误预测的代码仍然受到CPU频率的限制,但这并不会使256b AVX FP单元饱和。)
笔记本电脑的最大涡轮增压是额定频率的2.4倍。那款高端Haswell台式机CPU只能超频1.1倍。最大持续频率已经非常接近最大峰值限制,因为它需要一个良好的冷却系统,可以跟上这种热量产生。一个可以提供大电流的坚固电源。
Core M的目的是拥有一个可以将自己限制在超低功耗水平的CPU(额定TDP为4.5 W,1.2GHz,6W,1.4GHz)。因此,笔记本电脑制造商可以安全地设计一个小而轻的冷却和电力输送系统,并且只能处理那么多电力。
达到最佳表现似乎排除了所有影响 除了温度。但这真的很烦人。基本上它说 计算机会在HPC中感到厌倦,所以我们无法预料到 性能提升。那么开发HPC算法有什么意义呢?
关键是要在硬件上运行它们,这些硬件不受热量限制!像Core M这样的超低功耗CPU是一个不错的开发平台,但不是一个优秀的HPC计算平台。
即使是配备xxxxM CPU而非xxxxU CPU的笔记本电脑也可以。 (例如“游戏”或“工作站”笔记本电脑,旨在持续运行CPU密集型产品)。