.net - 我什么时候应该使用像 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 这样的工具包试图提供的主要值(value)是 开发人员生产力 ，特别是对于那些没有该主题博士学位的人来说，他们将很难或浪费大量时间来实现这些有时非常复杂的算法本身，可能很糟糕- 而不是把时间花在他们的实际问题上。

然后，您需要的功能可能已经被其他人使用过。他们中的一些人可能已经发现并指出了一些问题并贡献了他们的改进。 更多用户有助于提高代码质量和健壮性 。不幸的是，这也给我们带来了主要缺点: 它还倾向于使代码更通用，这通常使其效率低于完全满足您需要的高度特化的实现。

这与 Cody Gray 的评论一致:如果它可以工作并且足够快，请使用它，否则要么帮助修复它并使其工作(并且快速)，要么选择另一个有效的工具包，或者完全实现你自己需要的东西。幸运的是，对于 Math.NET Numerics，还有更多选项，请参见下文。

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

尽管如此，根据我自己的经验，拥有代码通常是一个优势(因此您可以进行更改，立即生效)并使其保持简单和专注(因此它正是您需要它做的事情并且仅此而已)。

特定于 Math.NET 数字

非常具体的托管实现总是可以胜过一般托管实现。但是， 我们的托管实现不应该比任何托管替代方案 慢多少。毕竟，我们的算法直接在数组上运行，也可以在内部运行(如果优化得当)。如果替代算法要快得多，似乎我们最好用该替代算法替换我们的实现，所以请让我们知道它(或者更好地贡献更改)。

如果您碰巧遇到我们可以并且确实利用像 MKL 这样的 native 提供程序并且您处理大数据的路径，我希望 Math.NET 是 数量级，尽管抽象级别更高，但速度要快

并非 Math.NET Numerics 中的所有代码路径都经过同等优化，或利用 native 提供程序。在过去的几个小版本中，线性代数已经投入了大量工作，所以我们正在变得更好，但速度很慢；还有很多工作要做(特别是对于稀疏类型)。在您的情况下，您可能遇到了一些几乎没有优化的路径。 所以我实际上对你的代码示例非常感兴趣，所以我们可以处理这个特定的案例 。

Math.NET 数字性能技巧

使用 native 提供程序

对 Control 类中的并行化设置进行一些实验(但请注意，我们已经意识到 v2.4 之前的并行化实现实际上非常糟糕，并计划在 v2.5 中完全替换它。第一个基准测试很有希望)

尝试在实现自己的操作时避免访问任何 At/indexer，而是直接访问原始数组(请参阅 .Storage)

许多操作允许指定结果向量/矩阵，有时甚至可以与操作数之一相同(就地)。避免在每个操作中创建一个新数组，从而在处理非常大的数据时降低内存压力。不幸的是也使代码变得丑陋。