|
|
@@ -24,7 +24,7 @@ but are interested in this topic, mail me.
|
|
|
在 2016 年西电 ACM/ICPC 校赛的最后准备工作中，为了测试评测效率，
|
|
|
本人写了一道题目（
|
|
|
[XDOJ 1152](http://acm.xidian.edu.cn/problem.php?id=1152)
|
|
|
-）的效率极其低劣的[代码](/blog/files/cache-unfriendly/xdu1152_bad.cc)。
|
|
|
+）的效率极其低劣的[代码](/files/cache-unfriendly/xdu1152_bad.cc)。
|
|
|
提交这一代码后，果然得到了预期的上千毫秒的运行时间。
|
|
|
于是本人开心地徒手把这个代码交了几次，结果令人吃惊的事情发生了：
|
|
|
这些提交全都超时了！把时间限制改大，再进行测试，发现了下列经验规律：
|
|
|
@@ -42,7 +42,7 @@ k 倍。
|
|
|
|
|
|
后来大家就把这件事忘了，不料在 2016 年的暑期集训中，这个问题又出现了。
|
|
|
这道题目是 [XDOJ 1179](http://acm.xidian.edu.cn/problem.php?id=1179)。
|
|
|
-本人求解这一问题的代码在[这里](/blog/files/cache-unfriendly/xdu1179.cc)。
|
|
|
+本人求解这一问题的代码在[这里](/files/cache-unfriendly/xdu1179.cc)。
|
|
|
注意这份代码并不像上次那样，是一份专门编写的效率低劣的代码，而是正确的解法
|
|
|
其他选手解决这道题的代码也是大同小异的。结果在吃了两个答案错以后，
|
|
|
本人发现输入数据有错，就呼叫命题人做了改正。之后裁判要进行重判，
|
|
|
@@ -157,11 +157,11 @@ L1 miss 本身并不是什么可怕的问题，
|
|
|
从而增大跨越内存页面的访问，严重干扰硬件预取，更加恶化缓存性能。
|
|
|
比如说，对于 `xdu1179.cc`，根据题目描述的限制，
|
|
|
将数组 `f` 改为使用 8 位整数
|
|
|
-（[xdu1179_better.cc](/blog/files/cache-unfriendly/xdu1179_better.cc)），
|
|
|
+（[xdu1179_better.cc](/files/cache-unfriendly/xdu1179_better.cc)），
|
|
|
可以将运行时间从 3.0s 降低到 1.8s 。
|
|
|
|
|
|
* 从 OJ 开发和运维的角度来说，
|
|
|
-可以考虑[对某些题目强行串行评测][1]。另外，注意及时更新 CPU 微码，
|
|
|
+可以考虑对某些题目强行串行评测。另外，注意及时更新 CPU 微码，
|
|
|
有时能够提高缓存命中率。
|
|
|
|
|
|
* 从科研人员的角度来说，买工作站的时候要注意考虑内存总线带宽和缓存大小，
|
|
|
@@ -171,5 +171,4 @@ L1 miss 本身并不是什么可怕的问题，
|
|
|
|
|
|
最后推荐 [Brendan Gregg 的一篇文章][2]。
|
|
|
|
|
|
-[1]: https://linux.xidian.edu.cn/git/XDU_ACM_ICPC/XDOJ-next/issues/13
|
|
|
[2]: http://brendangregg.com/blog/2017-05-09/cpu-utilization-is-wrong.html
|
