4

为什么人们坚持使用微不足道的数学问题，例如在斐波那契数列中寻找数字作为语言基准？这些通常不会针对相对论速度进行优化吗？首当其冲的瓶颈不是通常在 I/O、系统 API 调用、对字符串和结构的操作、处理大量数据、抽象的面向对象的东西等方面吗？

4

4 回答 4

5

这是对过去的回归，当时我们现在称之为基础数学的编译器技术仍在迅速发展。

现在，编译器的演变更侧重于为小众操作、64 位数学等开发新指令。

但是，在评估首次启动 Java 时热点编译器的效率以及评估 .NET 与 C/C++ 的效率时，您提到的微基准测试非常有用。

您关于 I/O 和系统调用可能是瓶颈的建议是正确的，至少对于某些问题来说是正确的。但我注意到您建议使用字符串操作。一个人无关紧要的微观基准是另一个人的关键绩效指标。

编辑：ps，我还记得使用 linpack 和其他微基准来比较 JVM 的版本，并比较 JVM 的供应商。从 v4 到 v5，性能有了很大的飞跃，我猜 JIT 编译器变得更有效了。此外，IBM 的 JVM 在 Windows-x86 上当时领先于 Sun。

于 2009-04-04T23:15:52.193 回答
3

因为如果你想对语言/编译器进行基准测试，这些“数学问题”是生成代码“裸速”的良好指标。他们要么使用迭代解决方案，这是一个紧密的循环，表明编译器将指令推送到处理器的能力如何，要么他们使用递归解决方案，它表明它如何处理短函数的递归调用（内联、尾递归等）（尽管通常也使用 Ackermann 函数）。

通常，该语言的基准测试套件还包含对其他部分进行基准测试的测试 - 例如。gzip 压缩、文本搜索、对象创建、虚函数调用、异常抛出/捕获基准。

您注意到的其他事情，系统调用和 IO 通常不包括在内，因为

  • 系统调用实际上并没有那么慢 - 应用程序不会在内核中花费大量时间，除非专门针对它们进行测试或程序出现严重问题

  • 系统调用和 IO 性能不取决于语言，而是取决于操作系统和硬件

于 2009-04-04T23:34:35.923 回答
2

我认为一个简单的、完善的算法将消除基准有偏见（无论是通过无知还是恶意）偏向一种语言的可能性。用两种完全一样的语言编写复杂的程序是非常困难的。例如，在 c# 与 java 中测试多线程应用程序的效率之类的东西，需要熟练掌握多线程开发这两种语言的开发人员，并且仍然存在关于基准应用程序是否正确代表一般情况的问题，或者它是否歪曲只有一种语言可以很好地处理的特殊情况。

于 2009-04-04T23:25:09.940 回答
1

回到当 eratosthanes 的筛子是 C 编译器的流行基准时，我认为如果编译器作者之一能够识别筛子代码并用预先计算的查找替换它会很有趣。

于 2009-04-05T03:54:49.980 回答