琐碎的数学问题作为语言基准

Question

为什么人们坚持使用琐碎的数学问题，比如在Fibonacci序列中找到语言基准的数字？这些通常不会优化到相对论速度吗？通常在I / O，系统API调用，字符串和结构上的操作，处理大量数据，抽象的面向对象的东西等方面，瓶颈不是首当其冲吗？

Answer 1

这是旧时代的回归，当时我们称之为基本数学的编译器技术仍在快速发展。

现在，编译器进化更侧重于利用小生境操作，64位数学等新指令。

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

您建议I / O和系统调用可能是瓶颈是正确的，至少在某些问题上是这样。但我注意到你提出了字符串操作。一个人不相关的微观基准是另一个人的关键绩效指标。

编辑：ps，我还记得使用linpack和其他微基准来比较JVM的版本，并比较JVM的供应商。从v4到v5，perf有一个大的跳跃，我猜JIT编译器变得更有效。此外，IBM的JVM在Windows-x86上领先Sun公司。

Answer 2

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

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

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

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

• 系统调用和IO性能不依赖于语言，而是依赖于OS＆amp;硬件

Answer 3

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

Answer 4

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