Julia多进程效率下降原因及性能评估方法问询

在20核PC上启动8个Julia进程（$ julia -p 8），针对易并行问题预期接近8倍加速比，但测试出现差异：

• 单浮点数求和：多进程版本获得约7倍加速比（N增大时接近8倍）
• 单浮点数数组求和：多进程加速比仅约4倍，且数组越大加速比越低、N增大无改善

对应的测试代码及基准结果如下：

单浮点数求和测试代码 #

using BenchmarkTools
using Distributed
@everywhere using Random

@everywhere mt = MersenneTwister.(1:nworkers())

@everywhere function run_floats(N::Int64, m::Int64)
    sum = 0
    for i in 1:N
        sum += rand(mt[m])
    end
    return sum
end

function run_dist(N::Int64)
    sum = @distributed (+) for m=1:nworkers()
        run_floats(ceil(Int, N/nworkers()), m)
    end
    return sum
end

基准测试结果 #

julia> const N=10^8
100000000

julia> @btime run_floats(N,1);
  2.871 s (200000000 allocations: 2.98 GiB)

julia> @btime run_dist(N);
  391.685 ms (595 allocations: 26.83 KiB)

单浮点数数组求和测试代码 #

@everywhere function run_arrays(N::Int64, m::Int64)
    sum = zeros(1)
    for _ in 1:N
        sum += rand(mt[m],1)
    end
    return sum
end

function run_dist(N::Int64)
    sum = @distributed (+) for m=1:nworkers()
        run_arrays(ceil(Int, N/nworkers()), m)
    end
    return sum
end

基准测试结果 #

julia> const N=10^8
100000000

julia> @btime run_arrays(N,1);
  5.512 s (200000001 allocations: 11.92 GiB)

julia> @btime run_dist(N);
  1.535 s (563 allocations: 27.03 KiB)

1. 内存分配与GC开销放大
   单浮点数求和每次仅分配8字节（Float64），而数组求和每次分配的长度为1的数组包含指针、长度、容量等额外元数据，内存开销远大于单个浮点数。单进程时数组版本的内存分配量是单浮点数版本的4倍，多进程下每个worker高频分配小数组，独立的GC操作总开销被放大，直接抵消并行收益。

2. 缓存效率低下
   单个浮点数可直接存放在CPU寄存器或L1缓存中，求和操作几乎是寄存器级运算；而长度为1的数组是堆分配对象，每次访问需通过指针间接寻址，无法利用缓存局部性优势。多进程下多个worker同时进行大量堆内存访问，会加剧缓存竞争，导致缓存命中率下降、内存访问延迟增加，这是加速比上不去的核心原因之一。

3. 数组运算的额外固定开销
   sum += rand(mt[m],1)本质是数组逐元素加法，相比单个浮点数加法，需要额外的数组边界检查、内存拷贝（即便长度为1，数组操作的固定开销依然存在），这些开销在1e8次循环后被放大，并行时无法有效分摊。

• Julia内置性能分析：
  运行@profile run_arrays(N,1)，通过Profile.print()查看热点函数，重点关注内存分配、GC相关调用栈；用@allocated测量单循环的内存开销，对比单浮点数版本的差异。
• 硬件性能计数器：
  使用Linux的perf工具，执行perf stat -e cache-misses,cache-references julia -e 'run_arrays(10^8,1)'，对比单浮点数版本的缓存命中率，若数组版本命中率显著降低，即可确认缓存是瓶颈。

• 计算密集度评估：若问题计算量远大于数据传输、内存操作开销，多进程通常能获得较好加速比，比如矩阵乘法、大规模数值模拟这类计算密集型任务，内存访问局部性好、缓存命中率高，并行效率优异。
• 内存访问模式判断：连续、可预测的内存访问（如遍历大数组）能充分利用CPU缓存，多进程效率更高；随机、零散的小内存分配（如本案例中的长度1数组）会导致缓存失效，并行收益有限。
• 任务拆分粒度控制：确保每个worker的任务足够大，能抵消进程间通信和启动开销。本案例中可改为批量生成数组再求和，而非每次生成单个长度1的数组，能有效提升效率。

内容的提问来源于stack exchange，提问作者Daphne