近一周来折腾Gentoo Linux的一点点成果～～～

金鹏

回复 75# cuda

好吧，明空了加上语句重新试试

ONLY

的确如此。FAH采用静态链接，未使用本地库，也不能重新编译。我们想要优化能做的东西不多，只能隔靴搔痒。 ...
cuda 发表于 2012-9-10 21:00

以前试过，用置顶的Linux镜像，对于2600K来说，选择i7或者i7-avx核心（大约便是AVX指令的差异了），跑分效能要相差10%左右！

cuda

回复 77# ONLY

10%会不会还有别的东西产生了影响？你现在编译的几个内核加了AVX参数吗？

ONLY

回复  ONLY

10%会不会还有别的东西产生了影响？你现在编译的几个内核加了AVX参数吗？ ...
cuda 发表于 2012-9-10 21:31

应该没有其他因素影响，只是在web配置页面选择Nehelem和Sandy Bridge的区别～～～

现在编译的内核编译参数均为：“-march=corei7-avx  -mtune=corei7-avx -Ofast -flto -pipe”～～～

目前仅是CFLAGS和CXXFLAGS设置为以上参数，FCFLAGS和FFLAGS均为默认的-O2 -pipe参数～～～

不过偶在虚拟机中试着改FCFLAGS和FFLAGS为上面的参数，不过貌似没什么效果～～～

且编译过程中满屏滚动提示的时候，还能见到-O2 -pipe的提示字样～～～   

（具体来说，满屏滚动提示的时候，编译选项可以见到是：-march=corei7-avx  -mtune=corei7-avx -O2 -pipe，貌似自动屏蔽了O3以上级别的优化）～～～

mrks

>>>lilo的帮助文档中要求每次更新内核后执行一次lilo，可能是需要在引导区写一些数据。 ...

lilo 需要重新执行，是因为开机时 lilo 没有文件系统的概念，是用直接读取特定硬盘磁道的方式来加载内核的。
更新的内核写入文件系统时所处的磁道是不确定的，所以必须运行 lilo 来把这个信息写到引导区。

grub 内置了缩微只读版本的文件系统，所以无需反复执行。

>>>现在编译的内核编译参数均为：“-march=corei7-avx  -mtune=corei7-avx -Ofast -flto -pipe”～～～
-Ofast / -O3 会打开某些可能影响结果正确性的优化，不建议用于科学运算。

>>>不过偶在虚拟机中试着改FCFLAGS和FFLAGS为上面的参数，不过貌似没什么效果～～～
FCFLAGS 和 FFLAGS 是编译 FORTRAN 程序用的，不影响。

ONLY

>>>lilo的帮助文档中要求每次更新内核后执行一次lilo，可能是需要在引导区写一些数据。 ...

lilo 需要重新 ...
mrks 发表于 2012-9-10 22:20

曾经用-Ofast -flto编译出来的内核运行了prime95严酷拷机模式12小时，未见报错～～～

这个，是说明科学运算也木有出错么？

难道，要跑够7×24未出错才算合格？

cuda

这个测试现在还能做吗？能否拿这两个核心的效率和你新编译的几个核心做个全面比较，期待可以把这个问题完全搞清楚。
我也曾经将原生环境的i7-avx核心和我目前用的3.2.9内核进行过对比，但好像FAH性能基本没发现什么差别。(同频下)

以前试过，用置顶的Linux镜像，对于2600K来说，选择i7或者i7-avx核心（大约便是AVX指令的差异了），跑分效能要相差10%左右！
ONLY 发表于 2012-9-10 21:28

ONLY

这个测试现在还能做吗？能否拿这两个核心的效率和你新编译的几个核心做个全面比较，期待可以把这个问题完全 ...
cuda 发表于 2012-9-10 22:56

当然可以做了，不过或许要稍等几天～～～

其实，如果在编译核心的时候显式的指定了CPU的架构（例如-march=corei7-avx），那么编译器便会使用优化过的代码～～～

在最近几天的“核心编译大战”中，最初，仅使用了原版核心与GCC 4.7.1，指定了CPU架构，使用-Ofast -flto参数，编译出的核心执行效能大约和301-BFS基本相当（见一楼测试结果）～～～

为内核打上最新的0.424 BFS补丁后，才要快上数秒的时间～～～

但这个补丁貌似又和睿频有些冲突，难以在双路E5上取得明显的成效～～～

期待金版测试test6、test7的结果，这些是不同BFS参数编译出的核心，可以据此进行调整，以取得最优的效能～～～

mrks

曾经用-Ofast -flto编译出来的内核运行了prime95严酷拷机模式12小时，未见报错～～～
ONLY 发表于 2012-9-10 22:26

刚看了一下，-O3 似乎没有什么大问题。但 -Ofast 会打开 -ffast-math，这个 -ffast-math 是一系列开关的总称，gcc 编译器手册上说

http://gcc.gnu.org/onlinedocs/gc ... ml#Optimize-Options

-ffast-math
    Sets -fno-math-errno, -funsafe-math-optimizations, -ffinite-math-only, -fno-rounding-math, -fno-signaling-nans and -fcx-limited-range.

    This option causes the preprocessor macro __FAST_MATH__ to be defined.

    This option is not turned on by any -O option besides -Ofast since it can result in incorrect output for programs that depend on an exact implementation of IEEE or ISO rules/specifications for math functions. It may, however, yield faster code for programs that do not require the guarantees of these specifications.

加黑的那句就是说可能会产生不正确的计算结果。如果是游戏程序，结果稍微差一点可能无所谓，但科学计算就说不准了。

这里不正确的计算结果，可能是因为位数的截断 / 误差的舍入等等。具体到个别的程序，它可能会或者不会受到影响，包括结果的正确性和算法的收敛性。就是说，可能会是变快/变慢，正确/错误的状态组合，也可能对某些输入数据结果是正确的，对某些输入数据又不正确的。

总之不确定，很难说。而且这样的问题一旦发生，又是特别难查找，因为必须深入检查汇编代码才能找出问题所在。

因此这样的计算结果是没有意义的，对科学研究而言是一种伤害。科学计算似乎没有听说过打开 -ffast-math 的。
我听说 NASA 编译航天器的代码时，是不允许编译器做任何优化的，只用 -O0。

既然扯到这里，顺便提一句，个人认为，挑甜包，对 FAH 也是有损害的。希望不要打击到金版的积极性哈。

具体到编译内核来说，估计 -ffast-math 没什么影响（因为没什么地方需要这个东西起作用），但也不会提高性能。

对于 -march=corei7-avx 参数，估计真正有用的地方在于这个 flag 会给出 CPU 的 cache 尺寸/发射数等的精确信息，帮助 gcc 决策。

AVX 指令本身对内核帮助不大。实际上内核应该根本没有浮点环境，不能执行浮点运算。

另外 -flto 要给内核打大量的补丁否则编译无法通过的，你确定你的标志起效了么？

我看 The Kraken 的原理也是调整 NUMA 调度策略，这个是有道理的。

从设置 affinity 的角度，内核开机有个 isolcpus 参数可以把某些 CPU 从内核的调度器中隔离出来，即内核不会给这些 CPU 分配任何
工作，然后用户可以将指定的程序不受任何干扰地运行在这些 CPU 上。不知道 BIGADV 界试过这个没有。

cuda

回复 83# ONLY

建议测试时可以关闭睿频，专注于公平比较内核的效率。

ONLY

刚看了一下，-O3 似乎没有什么大问题。但 -Ofast 会打开 -ffast-math，这个 -ffast-math 是一系列开关的 ...
mrks 发表于 2012-9-10 23:17

如果用O0选项和Ofast选项编译出两个不同的核心，然后跑同样的一个包～～～

最后对比result结果的md5值～～～

若一致，是否可以说明Ofast选项对FAH是有效的？

cuda

NUMA应该是提升性能的最关键所在了。
但有个麻烦的地方是，numa对FAH这种CLONE_VM的多线程程序的调控能力似乎不大好，FAH各个线程的numa_maps是完全相同的，用numactl或migratepages都无法很有效地操作。
thekraken没有直接使用numa，算是侧面利用吧；它的CPU binding顺序看起来也不是最优的，但奇怪的是实践中似乎找不到表现更好的binding顺序。
isolcpus这个东西似乎还没有人试过，多谢分享。有空打算试一下。

刚我看 The Kraken 的原理也是调整 NUMA 调度策略，这个是有道理的。
从设置 affinity 的角度，内核开机有个 isolcpus 参数可以把某些 CPU 从内核的调度器中隔离出来，即内核不会给这些 CPU 分配任何
工作，然后用户可以将指定的程序不受任何干扰地运行在这些 CPU 上。不知道 BIGADV 界试过这个没有。mrks 发表于 2012-9-10 23:17

mrks

回复 86# ONLY

我们不知道，问题的症结就在这里。

对于科学计算来说，我们还是应该让环境尽可能保持在程序设计者预想的范围内。

正确性是第一位的，速度是第二位的，分数/成就感是第三位的，群体认同感是第四位的。

Keyco

download和upload不要被墙是第五。

cuda

回复 88# mrks

应该没这么严重， 如果编译参数使得内核有缺陷，一般来说应该是造成内核panic，而不会对FAH程序正确性造成影响。
此外FAH程序也有一些错误检测机制保证数据一致性，如果出现计算错误能够检测出来并中止计算。这在超频的时候是经常见到的。
我觉得倒是FAH为了提高速度，大量采用单精度计算这一点不大好，可能会对结果精度带来比较大的影响。