Performance 使用Julia的内置函数时性能降低

我所属的一个研究小组最近决定尝试从我们以前的编码语言迁移到Julia，因为与其他用户友好的语言相比，它声称具有高速性能。然而，在我们最初翻译代码片段时，我的一位合作伙伴注意到，与使用简单的循环技术相比，使用Julia的内置函数（特别是“find”之类的简单函数）会导致速度下降十倍。有没有其他人遇到过这种情况，或者我们应该调查其他可能的原因？

请原谅我的评论，因为我没有代表做适当的评论

我对Julia的理解是，如果您想获得最高性能，通常编写循环会更好。这是事实已经有相当一段时间了；参见，例如，林大华的。编辑：但将来可能会改变；请参阅Colin T.Bowers关于多线程的讨论和下面的评论

请记住，判断性能可能很棘手。事实上，我在自己的代码中使用了很多find，因为我可以简洁地要求稀疏向量中非零的Int索引，而稀疏向量的长度并不是很长。与等效循环相比，find相对灵活、快速且清晰。例如：

# problem dimensions
p = 10000
k = 10

# a "sparse" vector with k random nonzeroes
b = zeros(p)
b[1:k] = randn(k)
shuffle!(b)

# use `find` to get the indices
@time bidx = find( x -> x .!= 0.0, b)

# is `find` faster than looping?
function find_nonzeroes(b, k)
    bnz = zeros(Int,k);
    j = 0
    @inbounds for i = 1:length(b)
        if b[i] .!= 0.0
            j += 1
            bnz[j] = i
        end
        j >= k && break
    end
    return bnz
end

@time bnz = find_nonzeroes(b, k);

# are results same?
println("Return arrays equal? ", isequal(bidx,bnz))

在我的机器上，运行两次后，结果是：

0.001795 seconds (10.03 k allocations: 158.402 KB)
0.004593 seconds (2.57 k allocations: 131.876 KB)
Return arrays equal? true

但是如果你把b的维数提升到p=1000000，那么结果就完全不同了：

0.028236 seconds (1.00 M allocations: 15.261 MB, 7.70% gc time)
0.005493 seconds (2.57 k allocations: 131.876 KB)
Return arrays equal? true

find_nonzeores函数比find函数更复杂，灵活性更低，但它可以更好地扩展到更高的p。在高维中，这种折衷可能是值得的，特别是如果您经常在代码中调用find

---

既然你没有提供你移植给朱莉娅的东西的细节，那么就很难给你比这更具体的建议了。上的Julia页面是我的参考资料，重读它经常帮助我提高代码的速度。

如果没有任何细节，回答这个问题是不可能的，但有一些明显的缺陷，您应该知道。阅读他们。很可能你在全球范围内做所有事情。谢谢你的提示：正如其他评论所提到的，这个问题不够具体，不适合StackOverflow。这就是为什么它吸引了大量的选票。我理解发布专有代码的限制，但也许您可以构建一个简单的工作示例而不泄露任何专有信息？如果你能做到这一点，我认为这将是一个非常好的问题…非常感谢你的详细评论。我将编辑我的代码以使用find_nonzeres，并将该计时与循环进行比较。我们正在为这个范围进行几十到几十万次迭代。我只是不太具体，因为我不完全确定我是否可以公开发布我们的代码/详细信息。回答得好。但我认为值得指出的是，一旦本机多线程可用，实验例程已经在v0.5中，devectorize everything启发式将不再一定是真的。这只是在我的脑海里，因为我在几天前回答了一个关于这一点的问题@ColinTBowers谢谢你的提醒！在花了大量时间思考如何并行化我自己的数值计算之后，我急切地期待着Julia中的原生多线程。没问题，很高兴能提供帮助：-事实上，我应该补充一件事给未来的读者，那就是BLAS可以完成的任何计算都不应该被开发，因为BLAS优化几乎每次都会胜过额外的临时内存分配。