琐碎的数学问题作为语言基准 [英] Trivial mathematical problems as language benchmarks

问题描述

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

Why do people insist on using trivial mathematical problems like finding numbers in the Fibonacci sequence for language benchmarks? Don't these usually get optimized to relativistic speeds? Isn't the brunt of the bottlenecks usually in I/O, system API calls, operations on strings and structures, processing large quantities of data, abstract object-oriented stuff, etc?

推荐答案

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

It is a throwback to the old days, when compiler technology for what we would now call basic math was still evolving rapidly.

现在，编译器的发展更加集中于开发利基运算，64位数学等新指令.

Now, compiler evolution is more focused on exploiting new instructions for niche operations, 64-bit math, and so on.

例如，当您首次评估Java时评估热点编译器的效率以及评估.NET与C/C ++的效率时，诸如您提到的微基准很有用.

Micro-benchmarks such as the ones you mention were useful, though, when evaluating the efficiency of the hotspot compiler when Java was first launched, and in evaluating the efficiency of .NET versus C/C++.

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

Your suggestion that I/O and system calls are the likely bottlenecks is correct, at least for some space of problems. But I notice you suggested string operations. One person's irrelevant micro-benchmark is another person's critical performance metric.

ps，我还记得使用linpack和其他微型基准来比较JVM的版本，以及比较JVM的供应商.从v4到v5，perf有了很大的提高，我猜想JIT编译器会更有效.而且，在Windows-x86上，IBM的JVM当时领先于Sun的.

ps, I also remember using linpack and other micro-benchmarks to compare versions of the JVM, and to compare vendors of the JVM. From v4 to v5 there was a big jump in perf, I guess the JIT compiler got more effective. Also, IBM's JVM was ahead of Sun's at that time, on Windows-x86.

这篇关于琐碎的数学问题作为语言基准的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！