12

我不确定这个问题有一个正确的答案，但我们开始吧。虽然许多数值问题可以用线性代数形式表示，但从我有限的经验来看，使用 Math.NET 的简单操作比在原始数组上编写等效操作会产生性能开销。

作为一个测试用例，我编写了代码来计算一个向量和一个列表中最近的向量之间的距离，有 3 个版本：对数组进行操作，对密集向量进行操作，以及使用 MKL 提供程序对密集向量进行操作。处理数组比处理向量快 4 倍，比使用 MKL 提供程序快 3 倍。

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

所以我的问题如下：在我看来，使用更高级别的抽象是以性能为代价的。一般情况下是这样吗，还是在某些情况下（例如实例的稀疏矩阵），使用 Math.NET 的性能有望优于手动编写的数组操作？

如果是这种情况，我倾向于认为使用 Math.NET 的线性代数部分对于涉及矩阵的“真实”代数最有用，以避免重新实现更复杂的计算/算法，并可能提高代码的可读性，但对于更简单的逐个向量操作的操作，处理原始数组可能是一个更好的主意。

任何关于何时使用图书馆的好主意与何时应该推出自己的图书馆将不胜感激！

4

1 回答 1

27

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

像 Math.NET Numerics 这样的工具包试图提供的主要价值是开发人员的生产力，特别是对于那些没有该主题的博士学位的人来说，他们将很难或浪费大量时间自己实现这些有时非常复杂的算法，甚至可能很糟糕 - 相反花时间在他们的实际问题上。

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

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

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

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

特定于 Math.NET 数值

  • 一个非常具体的托管实现总是可以胜过一般的托管实现。但是，我们的托管实现不应比任何托管替代方案慢很多。毕竟，我们的算法在内部也直接在数组上运行（如果经过适当优化）。如果另一种算法更快，似乎我们最好用那个替代方法替换我们的实现，所以请让我们知道它（或者更好地贡献更改）。
  • 如果您碰巧找到了一条我们可以并确实利用像 MKL 这样的本地提供程序并且您处理大数据的路径，我希望 Math.NET 的速度更快，尽管抽象级别更高。
  • 并非 Math.NET Numerics 中的所有代码路径都经过同等优化，或者利用本机提供程序。在过去的几个小版本中，线性代数已经投入了大量工作，所以我们正在变得更好，但速度很慢；还有很多工作要做（尤其是对于稀疏类型）。在您的情况下，您可能遇到了一些几乎没有优化的路径。所以我实际上对你的代码示例非常感兴趣，所以我们可以处理这个特定的案例。

Math.NET 数值性能提示

  • 使用本机提供程序
  • 对 Control 类中的并行化设置进行一些实验（但请注意，我们已经意识到直到 v2.4 的并行化实现实际上非常糟糕，并计划在 v2.5 中完全替换它。第一个基准测试很有希望）
  • 在实现自己的操作时尝试避免访问任何 At/indexer，而是直接访问原始数组（请参阅 .Storage）
  • 许多操作允许指定结果向量/矩阵，有时甚至可以与操作数之一（就地）相同。避免在每次操作中创建新数组，从而在处理非常大的数据时降低内存压力。不幸的是，也让代码变得丑陋。
于 2013-03-22T10:01:44.997 回答