是的，应该进行基准测试。我以编辑、作者和审稿人的身份提出此声明。下面，我稍微夸张地代表这些角色的立场。

但是，让我先强调你的论点。除了以下声明

基准测试没有说明算法 A 与算法 B 的内在速度——它只是告诉我们算法 A 的实现恰好比算法 B 的实现快。

[...] 它是在做出断言（A 比 B 快），而事实上这样的断言完全取决于代码作者的编码和优化能力。

我认为您可能同意甚至隐含地提出额外的主张：

如果算法 A 具有明显的算法 B 的理论优势，那么在实践中没有必要将两者进行比较。例如，如果算法 A 在 O(N) 时间内运行，而算法 B 在 O(N^2) 时间内运行，那么比较它们是没有意义的。

你会宁愿：

1. 生活在一个作者实现他们的算法并使他们的代码可供普通人使用的世界中？
2. 还是您更喜欢生活在一个作者取得“出色”进步但从不费心编写代码的世界中，将其留作“读者练习”？

我更喜欢第一个世界。当我遇到问题时，对我来说最好的办法是查看文献，找到带有 Github 存储库链接的清晰文章，然后去下载注释良好的源代码以用作库我的工作。可能需要几轮理论才能达到这一点，但我认为这是一个客观上更好的世界状态。

作为编辑，我如何创造这个世界？通过要求作者连同他们的论文一起提交代码。

作为作者，我如何创造这个世界？通过使我的代码可用并获得引用。

作为审稿人：通过建议修改和拒绝没有实现的论文。

另一个问题。你会宁愿：

1. 生活在一个很清楚应该使用哪种代码的世界中。

2. 在这个世界中，每个作者都声称他们的代码是最好的代码，并且将其作为“读者练习”来验证这些主张。

我更喜欢第一个世界。

作为一名编辑，我收到的每篇论文都声称比任何其他论文都更好地解决了 X。我的工作是保护你的时间，作为抵御一波 BS 的第一道防线（相反：通过帮助人们看到好作品来保护你的时间）。有时这很容易。作者减少了$O(N^2)$解决方案$O(N)$. 其他时候一切都是$O(N)$.

在后一种情况下，我有几个选择：接受每一篇写得很好的论文，声称由于理论上的原因他们的工作更好，拒绝所有新论文，因为现状显然足够好，或者要求作者进行基准测试。

最后一个选项让作者承担举证责任以支持他们的主张，重要的是，它鼓励他们编写性能良好的实现，因为他们知道我将要求未来的作者将他们的工作用作基线。

因此，通过不断地要求进行基准比较，我鼓励作者 (a) 实现他们的代码，(b) 将他们的实现与现状联系起来，以及 (c) 限制他们对自己工作所做的声明。

作为一名编辑，我可以要求作者重写其他人的代码以进行“公平”比较。但我不能相信他们是公平的：他们没有动力去做这项工作，很可能会错过一些东西。因此，我只要求改进新工作。如果较旧的作品没有得到正确的实施细节，那对他们来说太糟糕了。

作为一名编辑，我是一名志愿者。我工作过度了。我每周收到几十篇论文。如果有一种简单的方法可以确定它们是否符合进一步出版的标准，那不是很好吗？

作为审稿人，我更喜欢第一世界。我是一名志愿者。我工作过度了。我想做一个名义上的好工作，但我没有时间或动力去做一个伟大的工作。等等，有基准吗？问题解决了。

作为一个作家，我也更喜欢第一世界。我背景部分的每篇论文都声称它是有史以来最好的论文。为了将我的工作与喧嚣的海洋区分开来，我使用基准以清晰且令人信服的方式证明我的主张是真实的。

tl;dr 编辑、审稿人和读者都被激励想要基准。作者也应该如此，但他们有利益冲突，因为他们希望通过最小化每个出版物的工作来最大化他们的出版物数量。编辑和审稿人提供了作者需要做正确事情的借口。

你说得对，R 让编写缓慢、蹩脚的代码变得容易。但这正是基准测试很重要的原因：它是我们提高性能的唯一机制。

基准是有用的，但没有基准能说明全部情况。有许多有用的基准。例如，Julia 微基准测试是一个有趣的隔离基准测试案例：它尝试一次更改一件事。最好的例子是斐波那契基准。基准是递归算法。这是一种计算斐波那契数的糟糕方法，但这不是它要测试的：它专门测试不同的语言如何处理递归。当然，这不是关于一种语言性能的最终陈述，甚至不是关于一种语言在递归方面做得如何的最终陈述，但它是构建故事的一个数据点。

当谈到更大范围的科学计算时，您正确地指出有很多事情需要评估。同样，每个基准测试只是整个故事中的一个数据点。例如，在 SciPy、Julia、R (deSolve)、Fortran 和 C++ 之间的 ODE 求解器性能基准以及在DifferentialEquations.jl 和 torchdiffeq 之间的这个基准是一个综合基准：它说，在一天结束时，所有这些库做出的选择，这些库的表现如何？从这里你可以看到，如果有人对 CVODE 与他们在 MATLAB 中编写的东西进行基准测试，他们会因为语言的纯粹性能差异而损失 100 倍，因此这可能不是一种有趣的方式来证明算法“好” ”。

所以归根结底，如果你想非常清楚你的算法是好的，我认为你需要有一个好的高性能实现。如果你这样做，然后证明这组算法优于人们通常使用的标准方法，那么我认为你已经准备好了。因此，在一天结束时：

因此，与另一种算法相比，编写一个恰好次优的算法实现是非常非常容易的，即使如果以更好的方式实现该算法会更快。

我认为您确实必须与真正已知的软件进行比较，如果您想说服任何人您的方法是好的，否则它只是“可能好”。始终与 C++ 和 Fortran 进行比较，否则您会留下疑问。

但这当然会带来实现细节，这可能对现实世界的性能产生的影响比大多数数值分析师想要听到的要大。我最喜欢的例子是，与刚性 ODE 求解器的其他方法相比，BDF 积分器通常采取非常小的步骤，因此是因为它们的高阶不稳定性和它们的大截断系数。CVODE 快速的原因不是因为这些属性，而是因为它在保持不同时间步长之间已经分解的雅可比矩阵和检测牛顿迭代散度方面做得非常好。我可以告诉你，如果你做得不好，CVODE 将比简单的隐式 Runge-Kutta 实现快大约 30 倍，即使 IRK 可能需要更大的时间步长，只是因为它' s 做了更多的因式分解。更好的算法是什么？如果不优化实现，可能很难说！与 BDF 相比，具有多个阶段的 IRK 的较大时间步长有多好？这（对我来说）是一个开放的问题，如果不完全优化代码（无论这意味着什么），你就无法回答它。这意味着它仍然只是一个数据点，因为在一天结束时，您不知道任何一个代码是否真的“优化”了，或者其他硬件将如何影响结果！如果没有完全优化代码（无论这意味着什么），您将无法回答它。这意味着它仍然只是一个数据点，因为在一天结束时，您不知道任何一个代码是否真的“优化”了，或者其他硬件将如何影响结果！如果没有完全优化代码（无论这意味着什么），您将无法回答它。这意味着它仍然只是一个数据点，因为在一天结束时，您不知道任何一个代码是否真的“优化”了，或者其他硬件将如何影响结果！

但是如果你不能写出最优的代码（这很费时间），你仍然可以在文献中增加知识。当然它会有一些警告，但是训练有素的读者在阅读时会考虑到这一点。例如，事实证明，隐式 ODE 求解器将大量时间花在矩阵分解内核上，这些内核通常是 BLAS 调用，因此当从“慢" 像 MATLAB/Python/R 这样的语言。出于这个原因，您会发现在这些语言中隐式求解器与显式求解器的开销较小，这仅仅是由于语言行为，这使得像 LSODA 这样的东西在高级语言中成为一个很好的默认值。事实上，由于这种行为，它会赢得一些“它不应该”的基准。仅仅知道这一点就足以让我在阅读文献时“纠正这种效果”，所以如果你展示一些 IRK 和 MATLAB 的 ode15s 一样好，我会感到惊讶并想更深入地研究它。肯定更好吗？不，但它有一些证据表明这可能是一个好主意。

所以，你可以做什么？随便你。

所有基准在某些情况下都是有效的，问题是基准的作者经常没有提供有意义地解释其基准输出的上下文。

基准的上下文是它测量的事物以及为确保它实际测量它声称的事物而不是其他事物而采取的所有步骤。基准应该很好地衡量一件事，并仔细控制可能影响该衡量的所有变量。然后，该基准的作者应该传达他们采取的所有步骤，以确保他们的基准衡量的是他们声称的内容，而不是其他内容。理想情况下，这应该以两种方式同时传达：

1. 目标受众可以理解的通俗易懂的散文。在一个完美的世界中，某人应该能够在不查看代码的情况下理解所做的事情，但这并不总是可能的。
2. 源代码、构建脚本和运行脚本以重现结果，理想情况下在不同的上下文中生成新结果。

此外，算法的数值结果应始终伴随可能影响它的所有相关信息：环境、编程语言、操作系统、硬件。要尽可能具体。如果您的操作系统是“Ubuntu”，您应该指定版本。如果您有“英特尔至强”处理器，则应指定其 SKU。如果您使用从 GitHub 克隆的库的开发版本，则应准确指定版本上的最新提交。

在特定情况下，您提到了在 R 中实现的统计算法。这对于实现和比较非常有意义，但是如果不花精力来控制 R 的性能特性，那么基准测试的结论应该反映这一点——因为它不仅仅衡量算法质量，但实现+算法质量在一起。在我看来，这并没有使它无用，只是变弱了。

上述限制可能会使基准测试似乎无法进行，但事实并非如此。只需缩小基准的范围并对基准的结果做出较弱的结论，直到它确实满足上述限制。或者花更多时间加强基准测试，以便得出更全面的结论。

我认为这应该清楚地表明，没有单一的基准可以让每个人都开心。由于您必须挑选出一件事来衡量和控制其他所有内容，因此您将遗漏一些潜在受众。例如，不应使用旨在衡量计算硬件供应商之间性能差异的基准来比较不同的编程语言。

简而言之：基准必须附有对其测量内容的明确声明以及它确实测量所声称的内容的“证据”，以便其他人可以理解和审查该方法。

不是答案，只是Mittelmann的一个全面基准的初步概览图：8 个 LP 求解器（商业和开源） $\times$两种方法（单工和 IP） $\times$2打测试用例。