作为图书馆的作者之一，我当然希望 deal.II 在这个比较中脱颖而出。但我怀疑它可能不会，答案在于您在比较中忽略了一个因素：实现代码实际需要多长时间。

学术界很少有人具备从头开始实施 FEM 代码的技能，而在解决PDE 问题上花费的时间比实际实施PDE 的时间还要多。换句话说，实现事物的时间比代码的实际运行时间更有价值。这就是为我们带来诸如 deal.II、FEniCS、PETSc 等库的原因：是的，它们可能不是您想要做的任何事情的最有效实现，但它们是通用的，因为它们可以被使用针对各种各样的问题，而且它们是全面的因为他们不需要编写太多代码就可以让你达到 90% 的目标。例如，deal.II 的并行拉普拉斯求解器 step-40 只有大约 135 行代码（分号）。如果您想从头开始执行，这可能比您必须实现的数量少 2 个数量级——节省您自己编写 20,000 行代码（大约一年的工作量）。此外，切换到更高阶元素是单行更改。FEniCS 甚至可以让您减少到 20 行代码，尽管与最初节省的代码相比，节省的 115 行代码加起来当然不算多。

重点是，性能和运行时间只是一个指标。如果您打算消耗数十万或更多 CPU 小时，它们很重要。对于我们其他人来说，开发时间更有价值。

不幸的是，没有工具可以做到这一点。您可以在各种输入大小上运行每个，以确定它们似乎具有的计算复杂性，即表征每个代码的这可以指出每个人使用的底层算法，并验证是否实际实现了应该是的东西来实现这一点。您可以运行固定并改变处理器的数量，以便尝试确定其并行实现的效率。然后你在各种 CPU 频率和内存频率上运行一个固定的问题，试图确定它们对硬件特性的敏感程度。$f$$O(f(n))$$O(n)$$n$$p$

这些研究可以帮助您在设计空间中布置一些大部分正交的轴。这个空间实际上要大得多，而且非常广阔，它甚至没有开始将各种输入参数输入到求解器（最大迭代、停止标准、算法选择等）。

据我所知，基本上没有人这样做。您通常会很快弄清楚您是否在本意为 ) 。通过实践，您可以查看大多数核心算法的代码，并确保您得到正确的复杂度，因此最后，当比较两个应该具有相同计算复杂度的实现时，您会尝试计算它们是否具有通过实现理论预测的乘法和加法常数来实现。这可能非常乏味。$O(n^2)$$O(n)$

一旦你完成了所有这些，那么你就必须花时间比较实现、机器代码的编译以及硬件本身，以了解为什么你没有获得接近峰值性能的任何地方。人们花费数年时间这样做。