Linux 社区中的许多人经常表示，他们相信 Linux “似乎比 Windows 95 和 98 环境更快”。然而，很难找到关于 Linux 速度的可靠证据，而且很少有现成的比较性能数据。因此，许多考虑采用 Linux 的人可能无法在其决策中充分考虑其性能。当然，性能只是评估环境适用性时应考虑的众多因素之一。例如，成本、可靠性、可用性和可扩展性也是重要的考虑因素。

在本文中，我们将比较应用程序在 Linux 和 Windows 95 和 98 下运行时的计算性能。我们还将研究应用程序在 Linux 下的性能是否可以与 Windows NT 下的性能相媲美。最后，我们将考虑在领先的 x86 CPU 上 Linux 的性能是否使其成为 Intel 上 Linux 的可行替代方案。

我们希望这些测试结果能为 Linux 环境中卓越计算性能的潜力提供一些急需的证据。

许多指标已被用于比较 CPU 和系统性能。SPECint 和 SPECfp 是用于测量原始 CPU 计算能力的两个著名基准。系统整体性能已使用多种技术进行测量，例如 POVray 渲染（帧）速率、Quake 帧速率、Business Winstone 评级等。系统性能指标对于确定特定系统对于罐装应用程序的最终用户来说有多快尤其有用。然而，系统指标对于预测用户开发的应用程序的性能不太有用。大多数流行的基准测试倾向于忽略操作系统和编译工具对执行时间的共同影响。其他因素，例如特定的计算组合、系统硬件和编译设置也会影响最终性能，并且未被大多数流行的指标隔离。

因此，我们的目标是研究操作系统（和编译工具）对计算性能的影响。通过隔离这些因素，我们可以考虑 Linux 是否“达到”商业 Windows 环境的性能水平。

我们测试了一个我们内部开发和使用的计算密集型 C 程序的性能。（该程序可以从 ftp://ftp.linuxjournal.com/pub/lj/listings/issue67/3425.tgz 下载。）该程序在医学数据集上实现了一种体积可视化技术。此应用程序具有适度的计算和内存要求——我们测试中使用的数据集大小约为 4.5MB，在 C 语言中需要超过 300,000,000 次算术运算（其中大部分是浮点计算）来计算可视化。（见图 1。）这种类型的应用程序是对操作系统和编译工具实现的计算性能的合理测试。

图 1. 数据切片示例

可视化是静态的（不涉及动画），因此我们只考虑计算可视化的时间。显示最终图像的时间（见图 2）在不同机器之间变化不大，并且总是有些取决于图形硬件的差异，这不是我们想要考虑的因素之一。我们也不考虑数据输入和输出时间；我们的目标是了解操作系统和编译器在计算方面的效率。

图 2. 程序渲染的数据

我们尽可能地希望集中隔离那些可以让我们确定哪种操作系统和编译工具组合产生最佳性能的因素。幸运的是，我们的实验室有一些双启动机器（即，这些机器上安装了多个操作系统，并且可以在启动时选择所需的操作系统）。这些机器对于性能测试特别有用，因为 Windows 和 Linux 都使用相同的硬件。然而，为了提供更大的数据集，我们还查看了几台单启动 PC 上的性能。

在我们的测试期间，我们确保计算机上没有运行其他非操作系统任务。虽然有一些证据表明，与 Windows 95/98 相比，通常 UNIX 在系统负载增加的情况下可能会表现出更优雅的性能下降，但在不同的机器上复制可比较的负载具有挑战性，因此我们将主要关注未加载的性能。测试是在系统重启后立即进行的，并报告了重启后立即进行的前三次运行的平均值。计算时间是使用标准 C clock 函数确定的，该函数返回进程 CPU 时间（至少在 Linux 下是这样——稍后，我们将讨论许多 Windows 环境中 clock 的一个错误）。为了确保时间的最乐观度量，我们使用了多种机制启动了应用程序，并且只报告了最佳时间。有时，Windows 下的应用程序在编译开发环境中运行最快，但在其他情况下，应用程序将直接从命令行提示符运行最快。我们报告了产生最快执行时间的那个。

以下计算机用于测试

使用了多种编译器来构建用于测试的可执行文件。在 Windows 环境中，我们使用了 Microsoft Visual C/C++ Professional 版本 4.0、5.0 和 6.0。此外，还使用了 Metrowerks CodeWarrior Professional 版本 3.0 和 4.0。在 Linux 环境中，使用了 GNU C 编译器（gcc 版本 2.7.2.3）和 Pentium GNU C 编译器（pgcc 版本 2.91.57，基于实验性 GNU 编译系统 egcs 版本 1.1）。

为了确保应用程序的最佳性能，我们详尽地测试了使用大量编译器优化选项组合的执行时间。在本文中，报告的执行时间反映了每个编译器的最佳优化选项组合。此外，每次测试都多次运行，以减少后台网络或计算机活动产生次优结果的风险。

对于 Windows 系统，我们通常在重启后立即获得最佳性能；因此，我们在重启后进行了测试。Windows 95 和 Windows 98 机器通常在重启前执行速度慢 2% 到 5%。在 NT 机器上，时间差异较小；重启前性能下降 0% 到 2%。在 Linux 系统上，我们在新启动的系统和最近未重启的系统之间没有发现执行时间的任何明显差异。

第一个测试比较了在 Linux 环境中构建和运行的应用程序的性能与在 NT 环境中构建的应用程序的性能。

表 1。

表 1 比较了来自 gcc 和 pgcc 在 Linux 下编译的双启动机器上的应用程序执行时间，以及使用 Microsoft Visual C 和 Metrowerks CodeWarrior 在 NT 下编译的性能。当使用 Code Warrior 4.0 或 pgcc 编译时，应用程序执行效率很高。对于 Pentium II/400 系统，当使用 pgcc 在 Linux 下编译时，应用程序运行最快。虽然使用 Code Warrior 4.0 编译的程序运行速度次之，但 GNU C 编译器产生的可执行文件比 Code Warrior 3.0 更快。Visual C 生成的代码比免费的 Linux GNU 工具或商业 Metrowerks 产品生成的代码执行速度慢得多。基于 PII/400，使用 pgcc 的 Linux 比使用 Code Warrior 4.0 的 NT 快约 2% 的执行速度。然而，在 PII/233 上，使用 Code Warrior 4.0 的 NT 在新启动的系统上仅略快（0.5%）。有趣的是，在 Linux 下使用 gcc 编译后，应用程序的运行速度比在 NT 下使用 Visual C 运行时快 27% 到 35%。使用 pgcc 编译的应用程序在 Linux 下的运行速度比在 NT 上使用 Visual C 编译的同一应用程序快 30% 到 50%。我们还发现有趣的是，对于 PII/233，使用 Visual C 版本 4.0 比使用 Visual C 版本 6.0 获得了更好的性能。

在 PII/233 上，Visual C 编译的二进制文件在重启前比重启后慢约 1%。例如，Visual C 6.0 二进制文件在已运行数小时的系统上执行时间为 36.03 秒，而在新启动的系统上执行时间为 35.62 秒。

因此，看来 Linux 上的免费软件编译工具可以生成在一般条件下运行的代码，其速度至少与使用非常高效的 NT 商业编译器生成的代码一样快，甚至可能快 4%。显然，Linux 与 gcc 和 pgcc 可以生成代码，其运行速度明显快于使用 NT 或 95 下的 Visual C 工具编译的代码。

我们将报告我们可以实现的最优执行时间。对于 Visual C 编译器，在 Release 模式下使用最大化速度 (/O2)、多线程和 Pentium 代码选项可获得最快的执行时间。最大化速度选项包括内联扩展、全局优化、固有函数生成、帧指针省略和其他一些优化。Visual C 的三个版本在执行时间上总体差异不大，尽管 Visual C 4.0 代码在我们的测试中的大多数机器上往往比 Visual C 5.0 或 6.0 执行速度略快。

对于 Metrowerks Code Warrior C 编译器，使用 Pentium II 目标的“最大化速度”优化可获得最快的可执行文件。CodeWarrior 允许开发人员选择是否应在可能的情况下生成 MMX 指令，但 MMX 指令生成在我们的应用程序执行时间中产生的差异远小于 1%。我们报告了我们可以在给定计算机上实现的最快时间；如果最快时间是使用 MMX 指令生成，则报告的就是这个时间。

Code Warrior 和 Visual C 的 clock 函数都不符合 C 标准。这些编译器的 clock 函数返回所有活动进程的总 CPU 时间，而不是返回进程的 CPU 时间。Visual C 在 NT 中提供了一个 GetProcessTimes 函数；但是，该函数可用于查找实际的进程 CPU 时间。我们在 NT 上从 Visual C 报告的时间是基于 GetProcessTimes 函数的输出。但是，由于我们确保在测试期间没有非操作系统进程争用 CPU，因此 GetProcessTimes 报告的 CPU 时间通常仅比 clock 报告的时间少 0.1 秒。gcc 和 pgcc 中的 clock 函数符合 C 标准。我们还使用 C 的 time 函数检查了挂钟时间，并注意到 clock 报告的时间都在 time 输出的一秒钟之内。time 的分辨率以秒为单位，因此这是可能的最佳结果。另一组使用 WinTop、top 和 NT 任务监视器工具进行的单独测试进一步增强了我们对应用程序在执行时消耗 99% 或更多 CPU 资源的信心，这些工具都一致报告我们的应用程序正在消耗 99% 的 CPU 资源。

对于 GNU C (gcc) 编译器，优化级别 2 (-O2) 产生最快的可执行文件。

对于 Pentium gcc (pgcc) 编译器，优化级别 3 (-O3) 与快速数学和函数内联 (-ffast-math -finline-functions) 提供了最快的执行时间。

为了比较，我们还在运行 Red Hat Linux 5.1 的单启动 Pentium II/400 (PC 7) 上运行了该应用程序。在此机器上使用 gcc 的执行时间略好（14.67 秒），比在 PC 2 上更好。使用 pgcc 编译的应用程序的执行时间与 PC 2 的时间相似（13.79 秒）。

我们还在 Windows 98 操作系统下测试了应用程序的性能。PC 4 和 PC 5 具有相同的硬件组件（例如，主板、内存、显卡等都相同），只是 PC 4 运行 Windows NT，PC 5 运行 Windows 98。我们的应用程序在 Windows 98 下的运行速度往往比在 NT 下慢约 15%。表 2 总结了这些结果。因此，虽然应用程序在 NT 机器上可以像在 Linux 下一样快地运行（前提是程序是使用 NT 的 CodeWarrior 4.0 编译的，并且 NT 机器最近已重启），但 Linux 似乎比 Windows 98 效率更高。

表 2。

我们还在 PC 6（一台配备 Windows 98 的 Pentium II/450）上运行了该应用程序。然后，我们将线性回归应用于所有操作系统下各种编译器的所有执行时间，以推断和内插预测 Pentium 系列新启动系统上的可能性能。表 3 总结了这些结果。

表 3。

长期以来，我们一直感兴趣的一个问题是，克隆 CPU 上的 Linux 是否是一个可行的替代方案。我们有一台具有 AMD K6-2 CPU 的双启动机器，并决定测试其在 Linux 和 Windows 95 下运行应用程序的性能。K6-2 微处理器支持 3DNow! 指令，可以提高某些浮点计算的性能。然而，大多数编译器都无法生成 3DNow! 指令，因此 3DNow! 功能通常未得到充分利用。事实上，据我们所知，Code Warrior C 编译器是唯一尝试生成 3DNow! 指令的编译器。（gcc 和 pgcc 不会利用 K6-2 的 3DNow! 功能。）

我们的机器 (PC 3) 配备了 300MHz K6-2 CPU。该机器同时运行 Red Hat 5.2 Linux 和 Windows 95。表 4 总结了在此机器上在不同环境中编译和运行应用程序时的执行时间。我们测试了使用和不使用 3DNow!-优化生成的 Code Warrior 二进制文件的执行时间，发现 3DNow!-优化程序比非 3DNow!-优化程序快约 7%。否则，我们发现使用与我们用于 Intel 机器的编译器优化设置几乎相同的设置可以产生最佳的 K6-2 性能。最快的执行时间是使用优化级别为 4 的 pgcc 实现的。由于 pgcc 不生成 3DNow! 指令，因此它生成的 x86 指令在 Linux 下的运行速度可以比在 Windows 95 下执行的最佳优化版本更快。

表 4。

查看我们结果的另一种方法是将 K6-2 在 Windows 和 Linux 下的性能与 Pentium II 机器的性能进行比较。通过应用我们上面使用的相同线性回归方法，我们发现 Linux 下的 pgcc 在利用 K6-2 方面效率最高。使用 Linux，我们的 300MHz K6-2 的性能与 pgcc 二进制文件在时钟频率为 270MHz 的 Pentium II 上的预测性能相似。也就是说，我们的 K6-2/300 运行应用程序的速度比 Pentium II/266 在 Linux 下运行的速度预期要快。表 5 显示了 Pentium II 的预测时钟速度，该速度将使用各种编译器在可比较的时间内执行我们的应用程序。基于 Windows 的环境无法像 pgcc 和 Linux 那样释放 K6-2 的潜力。

表 5。

那么，K6-2 是否是 Pentium II 的可行替代方案，尤其是对于 Linux 用户而言？答案似乎是肯定的。在 Linux 中使用 pgcc 似乎允许 K6-2 的性能类似于以比 K6-2 慢约 10% 的时钟速度运行的 Pentium II。考虑到 K6-2 CPU 和主板组合之间的价格差异，K6-2 上的 Linux 在价格和性能方面都可能很有吸引力。

我们进行的最后一个实验是查看同时执行多个应用程序副本的总挂钟（经过）时间。此测试是对 Linux 和 NT 的扩展能力的度量，并隐含地测试了基本操作系统在上下文切换和内存管理（包括缓存管理）方面的效率。我们发现 Linux 和 NT 在测试范围内（最多同时运行 12 个相同的计算副本）都表现出良好的扩展性。在 Linux 和 NT 下，所有任务都以基本相同的模式开始和结束计算，并且平均计算时间保持相当稳定。

在 NT 方面，我们使用使用 Visual C 5 编译的应用程序进行了一组试验，并使用使用 Code Warrior 4 编译的应用程序进行了另外两组试验。还进行了两组使用 pgcc 的试验。表 6 总结了最艰苦的测试，即同时运行 12 个作业。表中 pgcc 和 Code Warrior 的结果反映了平均结果，尽管试验的测量时间基本没有差异。有趣的是，在 Linux 下，12 个同时执行的平均每次运行时间仅比运行一个作业的 CPU 时间高 1.2%。在 NT 下，Visual C 二进制文件的平均每次作业时间增加了 2.9%，Code Warrior 4.0 二进制文件的平均每次作业时间增加了 7.5%。特别有趣的是，在测试机器（Pentium II/233）上——根据我们的线性回归模型，这台机器是唯一一台预测 NT 执行应用程序速度比 Linux 快的机器——在 Linux 下一次执行 12 个作业的总时间比在 NT 下执行作业的总时间少 5.5%。

Linux 的扩展性好吗？这些结果表明，Linux 的扩展性确实非常好，并且在性能上优于 NT。

表 6。

就计算性能而言，Linux 是否是 Windows 的可行替代方案？我们的结果表明，使用 Linux 下的免费软件编译器编译的大型应用程序的执行速度可能不会比使用最有效的 Windows NT 商业编译系统之一编译和执行时慢 1% 以上。在一般使用情况下（即，在最近未重启的机器上），应用程序在 Linux 下的运行速度可能比在 NT 下快 4% 之多。Linux 的扩展性似乎非常好，并且在重负载下，它似乎总是优于 NT。

我们的测试还表明，Linux 的性能似乎比 Windows 98 好大约 15%。当将使用 pgcc 和 gcc 编译的应用程序的性能与在 Windows 95/98/NT 下使用 Visual C 编译的性能进行比较时，Linux 的优势更加明显。

非 Intel CPU（例如 AMD K6-2）上的 Linux 似乎也是 Intel Pentium II 上 Linux 的非常可行的替代方案。虽然相当大的应用程序在 Pentium II 上的执行速度显然比在时钟频率相当的 K6-2 系统上快，但此类应用程序在配备 Linux 的 K6-2 上的运行速度仍然比配备 Linux 的下一级时钟频率较低的 Pentium II 快，即，配备 Linux 的 K6-2/400 可能会提供略优于配备 Linux 的 PII/350 的性能。看待 K6-2 性能的另一种方式是，在 K6-2/300 上使用 pgcc 和 Linux 将产生一个程序，该程序仅比在 PII/400 上使用 Visual C 和 NT 构建的程序慢 2%。Linux 似乎是 AMD 上非常可行的选择。

对于开发自己代码的用户，尤其是当代码涉及大量计算时，Linux 可提供出色的性能。