V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
yanyuechuixue
V2EX  ›  问与答

同一个程序包,核多的不如核少的快,可能的原因有哪些?

  •  
  •   yanyuechuixue · 2017-04-21 08:44:58 +08:00 · 3159 次点击
    这是一个创建于 2533 天前的主题,其中的信息可能已经有所发展或是发生改变。

    同样的程序源码,同样的编译方式,同样的执行方式(mpirun -np 2 ./program),发现核多的机器更慢一些。

    核心多的机器是 Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz 核心少的机器是 E3-1225 v5

    用的程序包是对多线程支持不错的。且能看到在两个机器上, cpu 都跑满了。

    那么可能的原因是哪些?

    两个机器都是机械硬盘。

    第 1 条附言  ·  2017-04-21 09:38:17 +08:00
    对对对,忘了说, E5 核多的机器是双路 2cpu
    23 条回复    2017-04-22 20:04:28 +08:00
    SourceMan
        1
    SourceMan  
       2017-04-21 09:23:01 +08:00 via iPhone
    那张图你看过吗,一核工作,多核围观
    irenicus
        2
    irenicus  
       2017-04-21 09:26:57 +08:00
    看了一下, e3 的主频是 3.1GHz , e5 是 2.4GHz
    不过核数相差有点大

    e5 只跑了 4 个线程的话,从主频上看应该是 e3 快
    但如果 e5 每个线程都跑满的话,只能猜是线程间通信时 cpu 的 cache 一致性引起的了,不过影响应该不会这么大吧。。。
    zmj1316
        3
    zmj1316  
       2017-04-21 09:30:42 +08:00
    E5 该不会是多路 CPU 吧? NUMA ?
    ihuotui
        4
    ihuotui  
       2017-04-21 09:31:26 +08:00
    吞吐量 不一定多线程就快了。
    Ouyangan
        5
    Ouyangan  
       2017-04-21 09:33:31 +08:00
    会不会是线程创建+上下文切换开销太大.
    yanyuechuixue
        6
    yanyuechuixue  
    OP
       2017-04-21 09:38:46 +08:00
    @zmj1316 对对对,是双路 CPU 跟这个相关么?
    yanyuechuixue
        7
    yanyuechuixue  
    OP
       2017-04-21 09:39:21 +08:00
    @Ouyangan 这个会这么高么?请问怎么查看这种开销?
    Ouyangan
        8
    Ouyangan  
       2017-04-21 09:46:12 +08:00
    @yanyuechuixue #7 Lmbench3
    macworld
        9
    macworld  
       2017-04-21 10:05:40 +08:00   ❤️ 1
    用了代码里有类似全局锁之类的东西?
    jarlyyn
        10
    jarlyyn  
       2017-04-21 10:09:08 +08:00 via Android
    主频的问题吧
    yanyuechuixue
        11
    yanyuechuixue  
    OP
       2017-04-21 10:10:37 +08:00
    @macworld 那应该不会有,我是在做计算物理的,这个包能在泰坦超算上跑,所以应该不会是全局锁之类的东西。
    yanyuechuixue
        12
    yanyuechuixue  
    OP
       2017-04-21 10:11:27 +08:00
    @jarlyyn 哪怕双核并不是 1x2, 就算是 1x0.6 , 那 56 个核心,光算主频叠加, 也比四个强啊
    domty
        13
    domty  
       2017-04-21 10:12:14 +08:00   ❤️ 1
    阿姆达尔定律?
    并发程序的串行处理部分比率过高,导致程序的伸缩性不好,在少核心高主频上的执行效果反而好于多核心低主频?
    coderluan
        14
    coderluan  
       2017-04-21 10:47:04 +08:00   ❤️ 1
    都没人提 MPI ,我认为这个问题起码应该先不用 MPI ,直接跑一遍./program ,看看结果是否还是这样再讨论,否则现在就两种可能:是 MPI 的原因(不分布式跑 MPI 变慢很正常)和不是 MPI 的原因(上边提到的可能)。
    ericls
        15
    ericls  
       2017-04-21 10:56:07 +08:00 via iPhone
    可能 overhead 太大?
    yanyuechuixue
        16
    yanyuechuixue  
    OP
       2017-04-21 12:01:37 +08:00
    @domty 只是这个程序设计的时候就是为多核心设计的啊。。。
    yanyuechuixue
        17
    yanyuechuixue  
    OP
       2017-04-21 12:03:40 +08:00
    @coderluan 多谢,可是不知道程序作者怎么想的,强制使用 mpirun , 而且要求 -np 不小于 2 ...
    zmj1316
        18
    zmj1316  
       2017-04-21 12:31:01 +08:00
    @yanyuechuixue 把线程限制到单 CPU 核心数目, NUMA 架构跨 CPU 通信会导致内存和 cache 性能下降,还是放一个 CPU 上面跑比较快
    wulin
        19
    wulin  
       2017-04-21 13:12:16 +08:00
    主频高的那个可能快很多,我之前 go 写的文件内容查找程序也是, cpu 多,主频低的 E5606 @ 2.13GHz 服务器的反而跑不过办公的 I5 @3.2GHZ
    shalk
        20
    shalk  
       2017-04-21 13:31:13 +08:00
    你的程序没有把多核性能发挥出来,两个 CPU 的 speccpu 分差是明显的
    cy18
        21
    cy18  
       2017-04-21 13:38:45 +08:00
    操作系统是 windows 还是 linux ?
    如果是 windows 的话可以在任务管理器,详细信息,右击,设置相关性里面设置进程使用哪几个 cpu 核心,只勾选同一个 CPU 的核心,看看是不是多路 cpu 之间通信导致的性能下降。
    我之前也遇到过类似的问题。
    yanyuechuixue
        22
    yanyuechuixue  
    OP
       2017-04-22 12:13:48 +08:00
    @coderluan 大神啊~果然是不用 mpirun 就能跑的更快,要快 20 倍左右。 但是我需要的那个配置需要 mpirun ……
    请问有什么办法能找到问题么?
    coderluan
        23
    coderluan  
       2017-04-22 20:04:28 +08:00
    @yanyuechuixue 我 mpi 之是之前顺手学了下,实际没写什么代码,你这也没代码,我肯定找不到问题,不过一般来说 mpi 程序不用 mpirun 肯定也能跑,而且 mpi 程序一般都是运行在多台计算机上的(你有电脑可以试试),没什么道理非得在单机上跑 mpi
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1091 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 18:52 · PVG 02:52 · LAX 11:52 · JFK 14:52
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.