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

mrks

>>>numa对FAH这种CLONE_VM的多线程程序的调控能力似乎不大好

我想，这是这类多线程运算的特性。FAH 本身就在操作同一个数据集，必然涉及到数据争用。一般人的电脑，内存直接和 CPU 相连，
访问内存数据速度都一样，无所谓了；但 BIGADV 跑多路，对这唯一的数据集，必然要跳过 numa 节点访问数据，导致延迟。

BIGADV 可能就是不适合切分，这是跑大数据集必须付出的代价，不是 numactl 什么的能解决的，要改进必须改硬件架构，没必要
纠结。

>>>应该没这么严重， 如果编译参数使得内核有缺陷，一般来说应该是造成内核panic，而不会对FAH程序正确性造成影响。

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

>>>此外FAH程序也有一些错误检测机制保证数据一致性，如果出现计算错误能够检测出来并中止计算。这在超频的时候是经常见到的。

相对来说，硬件错误的检测比较容易。

用来编译 FAH 7.1.52 linux 的 gcc 4.1.2 编译参数为
-std=gnu++98 -O3 -funroll-loops -mfpmath=sse -ffast-math -fno-unsafe-math-optimizations -msse2

优化级别到 -O3，用 sse 做浮点运算，最高用到 sse2 指令，附带打开 -ffast-math，但关闭其中 unsafe 不安全的优化。

喜欢玩编译器参数的，那么按照 -ffast-math -fno-unsafe-math-optimizations 这个来吧。

最后，不知道有没有人尝试过用 google 的高性能分配器 tcmallac 替换 glibc 自带的 malloc 做内存分配。

http://code.google.com/p/gperftools/

据说对某些程序，tcmalloc 能提高性能 20% - 30%。用法很简单，编译 gerftools 后执行

[$] LD_PRELOAD="/usr/lib64/libtcmalloc_minimal.so" FAHClient

cuda

FAH程序应该是静态链接的，没有使用任何本地库文件，这种情况下应该难以产生效果吧？

最后，不知道有没有人尝试过用 google 的高性能分配器 tcmallac 替换 glibc 自带的 malloc 做内存分配。
http://code.google.com/p/gperftools/
据说对某些程序，tcmalloc 能提高性能 20% - 30%。用法很简单，编译 gerftools 后执行
[$] LD_PRELOAD="/usr/lib64/libtcmalloc_minimal.so" FAHClient
mrks 发表于 2012-9-11 09:50

mrks

FAH程序应该是静态链接的，没有使用任何本地库文件，这种情况下应该难以产生效果吧？
cuda 发表于 2012-9-11 10:11

对不起我搞错了。

一时糊涂 ldd 的是 FAHClient，这个不管计算的。ldd FahCore_a4 确认是静态链接的，因此 tcmalloc 不起作用。

刚还在奇怪为什么是动态链接的。

因为这种科学计算的程序，为了提高对不同平台的兼容性，同时也防止遇到有 bug 的外部库，因此一般都是静态链接的。
我记得 SETI classic 就是静态的。

cuda

回复 93# mrks

此类优化估计要对二进制文件动手才有可能做到。
对了，我曾经用strace发现FAH BA程序的大量内核态CPU占用都是在执行sched_yield系统调用，而显然这是完全多余的：
http://www.equn.com/forum/viewthread.php?tid=34809
你觉得有没有可能在可执行文件中把这条指令找到并把它替换成nop？这样应该能提高不少效率。我曾经试图反汇编过一次，但是没能找到。

mrks

回复  mrks

此类优化估计要对二进制文件动手才有可能做到。
对了，我曾经用strace发现FAH BA程序的大量内 ...
cuda 发表于 2012-9-11 10:40

这个 sched_yield() 是在做线程同步吧，不一定能随便去掉。

已经没有折腾的热情了，对此没想法。

cuda

回复 95# mrks

这个曾有人试过在kernel里面把sys_sched_yield()函数直接改成return 0，结果是可以的。我刚才也试了一下，这样改过的内核中top显示的SYS占用也有所下降，可惜性能却几乎没有提高(如果有也在千分之一以下)。
不过，如果能直接在可执行文件里面改效果应该会好一些，因为系统调用的主要开销在于用户态到内核态的切换，我猜测这样改也许能提升性能1%以上。

我测试的4P 4650目前离1M PPD的TPF只差2%，诸位多帮我出出主意。

vmzy

歪一下楼，说个题外话啊。
我知道这个帖子主要是讨论系统内核级编译优化，关注理论ppd的。
我只是想提醒一下，如果升级至v7客户端，预下载功能基本上可以保证cpu全速ppd输出，这个也应该可以提高实际ppd输出吧？因为即使使用了上传代理（比如置顶镜像系统），貌似v6在下载时cpu也是闲置状态无法输出ppd吧？
所以如果真想打造3213专用的跑分系统，我建议还是上v7比较合适。同平台下，v7的实际ppd输出理论上（如果没遇到下载模块挂起的严重bug）应该大于v6。

cuda

回复 97# vmzy

不知v7使用预下载功能后，斯坦福计算包的开始时刻是从预下载时刻算起还是从真正开始计算时算起？如果是前者，也可能会对BA包的奖励分造成略微影响吧。

vmzy

是从预下载时刻算起。
v6也是从下载时刻开始计时的，不过v6下载时cpu是没有ppd输出的。
当然v7在预下载完成，到当前任务完成这段空白时间，是会影响下一个任务的奖励分的，不过肯定比v6的ppd停止输出要小的多（甚至可以忽略不计）。具体的是可以利用公式量化计算的，不过这个算起来就比较麻烦了。最理想的状态是根据平均网速，调整预下载触发百分比，使得下载完成时间和任务完成时间尽量接近（v7默认是99%，如果你的tpf是15分，而平均下载耗时是1小时，那么可以把参数设置为96%）。
举个粗糙的例子：
下载/上传耗时1，计算耗时10，每个任务的分值为1。
那么1000个时间里，v6可以完成1000/(1+10+1)=83.33……v6镜像版可以完成1000/(1+10)=90.91，而v7可以完成1000/(10)=100。
即使假设由于下载完成时间早于任务完成时间，造成奖励分下降，使任务分值变为0.99999，那么输出分值也有99.999，远高于v6啊。

Keyco

如果你们谁需要双路E5来做试验，可以之呼我一下，我愿意奉献个三五月让你们来研究。

cuda

回复 99# vmzy

明白了，谢谢。看来这个功能挺有用的。

cuda

回复 100# Keyco

支持Keyco的无偿奉献。
推荐ONLY，有机器在手测试会方便很多。

vmzy

回复 100# Keyco
其实偶们最需要的是，乃去研究下在韩国怎么开代理服务器，以提高兄弟们的下载/上传速度，尽量减少ppd损耗。
同时也可以避免FAH被墙时，中国区ppd暴降的问题。这次没墙BA服务器，下次呢？
这才是大事啊。

Keyco

代理服务器，OK，我14号问一下，13号晚上去韩国。

Keyco

代理有什么硬件上的指标么？我网络白痴，不懂这东西。