我什么时候应该使用像Math.NET这样的线性代数库

Question

我不确定这个问题有一个正确答案,但我们走了.虽然可以用线性代数形式陈述许多数值问题,但从我有限的经验来看,使用Math.NET而不是在原始数组上编写等效操作的简单操作存在性能开销.

作为测试用例,我编写了代码来计算向量与列表中最接近的向量之间的距离,有3个版本:在数组上运行,在密集向量上运行,以及使用MKL提供程序在密集向量上运行.在数组上运行比在向量上运行快4倍,比使用MKL提供程序快3倍.

缺点是我必须手动编写距离计算,而不是利用内置的Norm函数.好处是它更快.注意:我没有发布代码,如果需要我会很乐意这样做,我可能也会使用Math.NET不正确.

所以我的问题如下:在我看来,使用更高级别的抽象会带来性能成本.这是一般的情况,还是有情况(如实例的稀疏矩阵),使用Math.NET预期会超过阵列上的手动编写操作？

如果是这种情况,我倾向于认为使用Math.NET的线性代数部分对于涉及矩阵的"真实"代数非常有用,以避免重新实现更复杂的计算/算法,并可能用于代码可读性,但对于通过向量操作更简单的向量的操作,对原始数组进行处理可能是更好的主意.

任何关于使用图书馆的好主意和你应该自己动手的事情都会受到赞赏!

Answer 1

免责声明:我正在维护Math.NET Numerics.

像Math.NET Numerics这样的工具包试图提供的主要价值是开发人员的工作效率,特别是对那些没有博士学位的人来说,他们会很难或者浪费很多时间来实现这些有时非常复杂的算法,可能很糟糕 - 相反花时间在他们的实际问题上.

然后,有些机会您之前已经使用过您需要的功能.他们中的一些人可能已经发现并指出了一些问题,并回馈了他们的改进.更多用户有助于提高代码质量和稳健性.不幸的是,这也给我们带来了一个主要的缺点:它还会使代码更加通用,这通常会使其效率低于高度专业化的实现,从而完全满足您的需求.

这就像Cody Gray的评论一样:如果它工作且足够快就使用它,否则要么帮助修复它并让它工作(和快速),选择另一个有效的工具包,或者实现你自己需要的东西.幸运的是,对于Math.NET Numerics,还有更多选项,见下文.

因此,我同意你的结论:如果你实际上不需要任何复杂的操作,不要使用非常大的数据,但性能很重要,直接使用数组或其他数据结构没有任何问题(特别是在F#中我个人会比C#更经常地考虑原始本机数据结构.当然,这是以失去一些便利为代价的风险,以及当您开始需要更多操作后,最终可能最终重新实现工具包的风险.最后,它还取决于这对您的项目有多重要,以及您是否可以花费资源和时间来维护自己的数学代码.

尽管如此,根据我自己的经验,拥有代码通常是一个优势(因此您可以进行更改,立即生效)并使其简单有针对性(因此它完全符合您的需要而且只有这一点).

特定于Math.NET Numerics

• 非常具体的托管实现总是优于通用托管实现.但是,我们的托管实施不应该比任何管理的替代方案慢.毕竟,我们的算法也在内部直接在阵列上运行(如果适当优化).如果替代算法更快,似乎我们更好地用我的替代方案替换我们的实现,所以请让我们知道它(甚至更好地贡献变化).
• 如果您碰巧遇到了我们能够并且利用像MKL这样的原生提供商并且处理大量数据的路径,那么我希望Math.NET的速度更快,尽管抽象级别更高.
• 并非所有Math.NET Numerics中的代码路径都是同等优化的,或者利用本机提供程序.在最后几个次要版本中,已经对线性代数进行了大量的工作,所以我们变得越来越好,但是越来越慢; 还有很多工作要做(特别是对于稀疏类型).在您的情况下,您可能会遇到一些难以优化的路径.所以我实际上对你的代码示例很感兴趣,所以我们可以处理这个特定的情况.

Math.NET Numerics Perf技巧

• 使用本机提供程序
• 使用Control类中的并行化设置进行一些实验(但请注意,我们已经意识到直到v2.4的并行化实现实际上非常糟糕,并且计划在v2.5中完全替换它.首先基准是有希望的)
• 在实现自己的操作时尝试避免访问任何At/indexer,而是直接访问原始数组(请参阅.Storage)
• 许多操作允许指定结果向量/矩阵,有时甚至可以与其中一个操作数相同(就地).避免在每次操作中创建新阵列,从而在处理非常大的数据时降低内存压力.不幸的是也让代码难看.