win平台下最新版Gaussian16使用经验分享

tjchkj

看到论坛里几乎是清一色的在linux下使用Gaussian16的交流，使我这个linux门外汉感到居然找不到在windows平台下的任何前人的经验可以借鉴。找遍整个互联网也是没有什么发现，所以不得不潜心自己摸索一下。
先说一下运行环境：
软件：Gaussian 版本： Gaussian 16R A.03 WIN64, VERSION 1.1 单用户版。win10 64位版，win7旗舰版 64位版.
硬件：双路E5-22696v4（44核心）@2.2G ，超微X10DAL-i主板，三星原厂REG ECC 8G*8 总计64G内存。OCZ VECTOR 180 256G固态盘，显卡GTX750-2G，硬盘ST2000NM0033 ES.03 企业级2T。电源900瓦。满载cpu最高温度62度。
在win10下，无论是否打开和关闭超线程，观察Gaussian 各个模块，明显比I5 4440 的机器跑相同任务慢一个量级，因此不是两种cpu主频高低差别问题造成。在win7下也发现类问题。而关闭超线程后，win7下各个模块运行速度完全正常了。因此，可以得到结论就是在windows平台下使用Gaussian16，必须关闭超线程。
下面针对44核心的机器，做一些使用方面的经验，少于44核心的机器，可以类似参考。
一、Link 0中cpu使用的方法
1、老指令%nprocshared，可以用到所有的cpu核心。所以这个机器可以使用到44核心，即%nprocshared=44 可正常用，但这样使用每个cpu核心的使用率不很充分，瞬间cpu总使用率可达99%，但平均总使用率不到50%。测试发现，如果空出几个核心，可以达到计算用时短的效果，我这里是%nprocshared=42最佳。
2、新指令%CPU。该指令可以在任务中选择特定的核心。参数后面跟随用逗号分隔的核心列表例如%CPU=4，5，6，33，43等，或者用核心范围，例如%CPU=3-17 等.
探索发现这里存在bug，就是说%CPU这行核心列表里到最后一位字符，最长字符不能超过57个（win10里不能超过60个），去掉%CPU=这5个字符，在win7中核心列表字符最长是52个。即便你使用核心范围表示也是如此规则。
二、cpu核心限制
1、由于2中所出现的BUG问题，导致目前该版本的核心使用受到制约，采用%CPU指令时，最多核心的上限是21个（win10中是22个），如果你的核心列表里，没有使用到0-9这样单个字符表示的核心，那样能使用的核心只更会少而不会多。因为用范围表示的时候都是转换为列表来进行的。
2、采用多开的方式可以同时运行多个任务。我们知道在win平台下开一个Gaussian窗口只可以跑一个任务，但可以多开窗口实现同时跑多个任务。实验中可以做到1分钟同时运行起32个窗口，每个窗口都是调用BCF文件去运行。每个bcf中可以有上千行任务。这样可以一次投递几万个任务进去。
3、测试表明，Gaussian16 用%CPU=格式指定cpu使用的核心上限是32.不知道是他们用于开发的机器是只有32核心呢，还是在程序中存在BUG，定位核心的时候，采用了MOD函数，把你输入的cpu核心按32整除后得到的余数来定位cpu核心。也就是说，你即便是使用一个核心，这个值大于32就会按整除32后的余数去找核心。这样你多的核心就无法使用了。
三、从cpu负荷率来换个角度看并行效率
    我们采用一个测试样本，由于指定核心职能最多用21个，测试了两种方式的cpu使用，完成任务时间比较接近。
    以下研究的是多开计算的对比数据：
    单开 share = 44  时间是7：46 ；单开 最佳42 核心 用时3分41秒。
    四开 share = 11  用时10分10秒。      折算为 单个用时2分32秒，
    可见，如果算多任务，宜采用多开。
    另外 如果采用指定核心方式，则对于多任务计算的最佳方式就是32开每个指定1核心，折算后单个任务花费的时间是最少的。比较数据就略去不再赘述。如果你一次计算的任务不超过32个，可以适当组合一下，可以采用16开双核心，8开4核心，4开8核心，2开16核心的方式。或者是采用多开不均匀核心，比如三开：两个11核心加一个10核心这样做。四、采用缓存，利用机器的大内存对运算中的临时文件做缓存，我把scratch单独放在磁盘靠近中心的盘符里，用superchche 64位的来做缓存，大大降低磁盘的读写频次。懒写延迟可以任意设置。注意对系统盘不要做懒写。图中可以看到浅蓝色是读缓存命中。

有了大量多开，多窗口友好的界面，加上缓存运用，配合Gaussian View6 直接可视化的工具，在windows下直接运行Gaussian1做计算，就是一件愉快而高效的事情了，相信更多的人会越来越喜欢在windows下做运算了吧？运算的同时，你可以办公，写论文，娱乐休闲，一台机器就解决问题了。鉴于最后那个缓存scratch读写硬盘很多。我后来直接把scratch用RAMdisk 用内存虚拟成一个盘符，这样直接连supercache都不用给它分配内存了。而且是比supercache效率高的没法比。

tjchkj

另外用linux来做的大师们看看，上述cpu核心数的使用限制，在linux版里是否存在？

sobereva

linux没%CPU最多设32核这个问题，如这个帖子的情况，%CPU指定用36核心没问题
正确看待超线程(HT)技术对计算化学运算的影响
http://sobereva.com/392

Win32 Gaussian用的人很多，只不过没有对计算资源限制的Win64 Gaussian极少有人用，网上没有，售价也太贵，Site license比Linux版都贵，再加上跑计算的机子绝大多数都是Linux的，因此极少有人讨论Win64 Gaussian的使用。

tjchkj

sobereva 发表于 2017-12-4 16:33
linux没%CPU最多设32核这个问题，如这个帖子的情况，%CPU指定用36核心没问题
正确看待超线程(HT)技术对计 ...

后来加上了缓存的使用，使得scratch文件的磁盘读写得到最大的优化。看了你那篇超线程的文，和我测试基本一致。但我这里在超线程下，模块没有优化，所以反而更慢的多。而且指定cpu不能超21个，编号还有上限32这个问题。看来linux版他们还是下了功夫，而windwos64位版，他们还是有很多漏洞。G16w 的win64 单用户版没有人在用吗？我现在最关心的是超过32核心那富裕的12核心要是能用上就好了。如果你不用指定核心，采用shared方式，在多开的时候，会导致不同的任务去混用相同的核心，出现调度混乱争抢cpu核心，大大降低了效率。

liyuanhe211

其他先不说。关于同时运行多个任务的问题，注意需要考虑每个任务不是同时结束的，且结束的时间很难有明确的预期，这使得有多个任务（但又不太多）时，会出现任务拖尾的问题。

例如有32核，共4个任务，跑4*8核任务的总CPU时间会比1*32核任务要短，但其中一个任务的耗时可能比其他三个都长，这使得任务最后只余耗时最长的任务在只用8个核跑，其他核闲着，使得Wall time不一定低。如果变成32*1核任务，这个问题就更显著了。
当然这种情况在：（1）机器特别多 或/和（2）任务特别多 时可以忽略。但大部分人并不会有这样的情况，对耗时较长的任务，同一时刻每台机器不会有很多任务等着。

P.S.只考虑并行效率就觉得32*1核这样的布局最好其实比较幼稚，很多情况即使在理想条件下测试，32*1核也还不如16*2核好。最多同时跑8个任务还凑合。

另外只用很有限的功能、比如只跑高斯、只本地控制、只手动排队等等的时候，Windows是不错的。但任务越来越复杂，涉及的软件种类变多，对计算自动化、管理自动化的要求越来越高的时候还是会体现出计算任务对 Linux 是更友好的。很多功能在Windows上确实都可以实现，但对初学者来说常不“自然”，需要折腾且常不甚可靠。对不太熟练“不会折腾”的人常常反而Linux更省时间。

tjchkj

忘了说一句，我已经把scrarch这个的缓存去掉了，不再用supercache去缓存它了，直接把它放进内存去了，这样整个gaussian计算，除了读下输入文件和写进输出的结果文件.out ，基本就不再去读写硬盘了。这个办法比用固态盘解决大量读写的快的多的多了。那些需要在运算中大量读写硬盘的就知道这个好处了。

liyuanhe211

tjchkj 发表于 2017-12-6 21:56
忘了说一句，我已经把scrarch这个的缓存去掉了，不再用supercache去缓存它了，直接把它放进内存去了，这样 ...

一共才64G内存就要把内存当硬盘用了 （；￣ェ￣） 64G考虑“正常的问题”内存自己都能满了，别说还要塞scratch，你还要同时开32个任务。。。每个任务内存+scratch不超过2G......。640G内存还差不多

tjchkj

liyuanhe211 发表于 2017-12-7 07:42
一共才64G内存就要把内存当硬盘用了 （；￣ェ￣） 64G考虑“正常的问题”内存自己都能满了，别说还要塞sc ...

"每个任务内存+scratch不超过2G......。640G内存还差不多"  首先我这个任务不占内存，可能是差别吧。可以观察到，一个G16W 本身占用10MB内存，一个迭代计算模块占用80MB，l302占112MB，一个l702占91MB。这里真正表述严格的话图里的是KB的数还要除以1204才是MB，我就按不除的这样大约说。即便是有的任务占用一些内存，也不是说你定义了多少%mem它就用满，%mem只是说可以占用的上限。所以正真占用还是要在运行中去看。内存是共享的，并不是每个任务都同时占用那么多。     所以这个图里只用了物理内存64G的27%。而这27%里，scratch内存我分了2G，supercache给系统分了11G。所以，除去这13G，16开gaussian和win7系统一才共用4.4G，也就是说，16个gaussian 只用了不到2G。就算32开也大不到哪里去。可能如果有的任务会用到很大的内存的话，那样就不会去多开到32了，这个应该根据任务使用内存的大小而掌握的，这种情况下你就是不把scratch放内存里，想要还多开32个，那可能吗？所以和把scratch放不放内存关系不大。再说这个scratch就是放内存里，也不是说按照每个任务去各自分配一个啊。所以不是“每个任务内存+scratch不超过2G......。” 你这样等于是32开，要开32个scratch了。

zhaoyangwx

没有windows版的话也可以通过WSL在windows下直接运行Linux版的g16，效率感觉还挺高

tjchkj

liyuanhe211 发表于 2017-12-7 07:42
一共才64G内存就要把内存当硬盘用了 （；￣ェ￣） 64G考虑“正常的问题”内存自己都能满了，别说还要塞sc ...

小任务可以这样，需要大量硬盘的就不能这样了，最近做了一个MP2 好么，占用了400多G的临时文件。

Peter_zhong

sobereva 发表于 2017-12-4 16:33
linux没%CPU最多设32核这个问题，如这个帖子的情况，%CPU指定用36核心没问题
正确看待超线程(HT)技术对计 ...

游客，本帖隐藏的内容需要积分高于 150 才可浏览，您当前积分为 0

qinzhong605

Peter_zhong 发表于 2020-9-30 09:23
**** 本内容被作者隐藏 ****

是。很明显的EM64W了呀，如果是linux不会有w字样的，一般是ES64L-G16Rev。

Peter_zhong

qinzhong605 发表于 2020-9-30 13:35
是。很明显的EM64W了呀，如果是linux不会有w字样的，一般是ES64L-G16Rev。

那这么说 win64算的速度应该和Linux版差不多吧？ 我见本帖子说win64没有资源限制 可以全开

qinzhong605

Peter_zhong 发表于 2020-9-30 15:45
那这么说 win64算的速度应该和Linux版差不多吧？ 我见本帖子说win64没有资源限制 可以全开

win版本只是小任务可以，真正干活还是用linux版本的来。

sobereva

Peter_zhong 发表于 2020-9-30 15:45
那这么说 win64算的速度应该和Linux版差不多吧？ 我见本帖子说win64没有资源限制 可以全开

核数多的时候Win64版慢得要死，没实用性。