作者 | Nibble Stew       

责编 | 弯月

出品 | CSDN（ID：CSDNnews）

自从编程语言诞生以来，人们常常就哪种语言速度最快的问题争论不休。无论是严肃的科学研究，还是深夜酒吧的喧嚣，都不乏关于这个话题的争执。文本不打算就这个问题展开讨论，我们不妨从一个更高的层面来看一看这个问题：如何比较两种截然不同的编程语言的性能。为了进行有意义的比较，我们必须使用两种编程语言实现一系列测试程序，运行基准测试，然后再比较最后的结果。

实际上，这种比较的难度很大，有时甚至非常费时费力。尽管问题本身看起来很简单，但大量可能出现错误的地方会导致一无所知的性能测试员遭遇坎坷，有时即使非常了解也无济于事。

等效的实现？

为了公平地比较两种语言的实现，编写出来的程序的质量应该达到同等水平。也就是说，必须由某位对两种编程语言以及领域知识的掌握程度大致相同的人来编写程序。这本身就很难。如果由不同的人来编写实现，那么他们可能会选择不同的算法来解决问题，这样的性能比较就不再是编程语言本身的问题，而是每位程序员选择的编程方法的问题。

即使两个实现都是由同一个人使用相同的算法编写的，仍然存在其他问题。通常，每个人都有自己擅长的语言。因此，他们会选择自己喜欢的语言提供更快的实现。这就会引发偏差，因为这样的性能比较衡量的不是编程语言本身，而更多的是程序员。这类的测试适合寻找易用性与生产力的差异，但对比较性能而言则不合适。

因此，你可能需要评估许多专业程序员已经编写好的程序。这是一个很好的方法，但有时即使是经验丰富的研究也会出错。有一篇论文试图通过这种方法比较不同的编程语言的性能和效率。他们的测试结果表明，某个程序用C实现比C++实现快30%。这个测试结果影响了整个论文的基调。按照这个论断，假设将所有 C 源代码的文件扩展名 .c 改为.cpp并重新编译，应该能得到大致相同的结果（可能会有几个百分点的误差）。所以我们只能得出以下结论（按照可能性从高到低排列）：

1. C++版本的代码比较差；

2. 测试方法有明显的瑕疵；

3. 与C相比，该编译器对C++的性能有重大的负面影响。

换句话说，上述呈现的差异并非来自编程语言本身。

测量的难度

还有一个很大的问题是，如何测量某个程序的性能。一种常见的方法是连续运行多次测试，然后执行如下操作：

1. 处理异常值：去掉两个极值（即最慢和最快的测量值）；

2. 计算剩余数据点的平均值和/或中位数；

3. 比较不同程序之间的结果，速度最快的程序获胜。

上过统计课程的人可能还记得如何计算标准差。这种方法看似合理且严谨，但其实包含多个系统误差。其中最大的问题涉及测量中的噪声。

大多数基本的统计工具都会假设误差呈正态分布，平均值为零。如果测量的是温度或速度之类，则这个假设是合理的。然而，对于编程语言的性能测量来说，这个假设并不合理。程序的运行时间包括实际上花费在解决问题上的时间，以及来自操作系统中断、磁盘访问等方面的开销。如果我们假设噪声为平均值为零的高斯噪声，那么这意味着计算机有一些未知的过程，可以让程序的运行速度超过完全无噪声时的情况。这当然是不可能的。这里的噪声肯定不是高斯噪声，因为它永远不会出现负值。

事实上，最接近柏拉图式理想答案的测量结果就是最快的，因为这种情况下来自系统噪声的干扰最少。这样的测量结果会被上述第一步操作“处理异常值”删除。有时，采用合理的、现成的措施只会让事情变得更糟。

统计的难度更大

暂时撇开这一点不谈，我们假设我们获得了两个程序的性能测试结果，且这个结果看似确实“很高斯”。数值分析表明，1号语言的运行花费了10秒，而2号语言花费了9秒。二者的差异为10%，因此我们就可以得出结论：2号语言的速度更快。这个结果正确吗？

很遗憾，不正确。假设实际测量数据如下：

右边的那个更快，对不对？也许？大概？可能？为了正确回答这个问题，我们需要回顾一下大学学习的统计知识。首先，提出零假设，即假设两个程序没有性能差异。接着，计算这两次测量结果来自同一个概率分布的概率。如果概率非常小（通常为5%），则可以推翻零假设，从而证明其中一个程序比另一个快。这种方法叫做学生t检验，常用于大量数据的统计。请注意，测试的某些实现会假设数据符合高斯分布，如果你的数据呈现其他形状，则结果可能并不可靠。

这种方式适用于一个程序，但严格的测试需要包含多个程序。这些评估也有一些统计方法，但会非常复杂。具体的做法留给读者自行查阅。

所有计算机的对齐都是双刃剑

虽然统计非常难，但幸运的是计算机很简单，因为它们具有确定性、可靠，而且合乎逻辑。例如，如果在一个程序中添加一条NOP指令，则结果可能只是多了一个指令周期，对性能的影响小到无法测量。但是，如果你非要测量，那么结果可能会让你陷入不解和困惑。这个小小的改动有时会让程序的运行时间增加10%（甚至更长），但也有可能缩短10%。你没看错，这类看似无意义的工作可以加快程序的运行速度。如果是第一次遇到这样的问题，你可能压根不会相信。 

那么，问题在于，是否有可能让CPU加倍努力，让程序更快地运行呢？答案为否。实际的指令根本无关紧要。重点在于代码的对齐。代码在内存中的不同位置会影响其性能特征。如果一段经常被执行的循环跨越了缓存边界，它就会变慢。将其移动到不跨越边界的地方就能加快其速度。NOP指令并不一定要放在循环内，只要它能将整个代码块向上或向下移动，就可能导致这种差异。假设你以非常严谨的统计方式测量了两个程序。如果二者之间的性能差异低于10%，则我们就无法断言哪个程序更快，除非你使用的测量方式能够消除对齐效应。

这是关于机器的性能测量，而不是语言

随着程序的运行速度越来越快，优化经历了一个有趣的阶段转变。一旦性能达到一定水平，系统就不再关心编译器和CPU如何才能加快程序的运行速度。相反，变成了程序员如何尽可能有效地利用CPU，例如将数据排列成方便处理器处理的布局等。这意味着用基于硬件的原语替换基于语言的原语。某些圈子采用的优化方式非常奇怪，程序员甚至知道他们的循环应该被优化成哪些SIMD指令，然后他们会不停地修改代码，直到实现这种优化。其实，这种优化已经与编程语言本身的功能没有丝毫关系了。

这就是为什么C和Fortran之类的语言仍在许多性能基准测试中名列前茅的主要原因，但这些技巧并不限于这些语言。几年前，我开发了一款规模非常大的Java应用程序，该应用程序经过了非常彻底的优化。其内部由整数数组组成。最常执行的路径中没有类，甚至没有Integer对象，基本上就形同于在Java语言内部重塑了C语言。其实，几乎任何编程语言都可以有类似的实现。它们之间的性能差异主要取决于每个编译器的优化器。即便使用相同的编程语言，也会产生截然不同的性能结果，更不用说不同的编程语言了。因此，声称某一种编程语言在性能上有明显的优势都是不合理的，因为说到底都是内联汇编程序。

原文链接：

https://nibblestew.blogspot.com/2021/02/why-most-programming-language.html?m=1