编译和二进制Linux发行版/软件包之间的性能差异

性能差异几乎在所有情况下都是微不足道的。 使用源代码发行版的很好的理由（在gentoo的绑定系统允许的情况下，滚动你自己的二进制包）包括：

• 部署您自己的自定义修补程序
• 轻松定制您的内核
• 打包自己的更新

如果你没有做这些事情，你不需要源代码分发。 对于个人使用他们非常方便，因为他们允许您随意升级，而不必担心二进制兼容性问题，这在企业环境中经常遇到。

值得注意的是，你可以用二进制分布来做这些事情，通过制作你自己的RPM软件包或其他东西。 pipe理开销类似。

从源代码编译基本上看不到速度提高了15％。 在任何合理的情况下，我估计它甚至会高达5％。 从源代码编译得到你几件事情：

• 你可以使用你喜欢的编译器版本
• 您可以指示编译器生成来自ISA扩展的指令，而不是在二进制发行包的包中使用，如AESNI和AVX

但是编译器实际上很less生成这些文件，使用它们的整体节省通常在整个应用程序的性能时是非常小的。 像RAM访问（和延迟）以及磁盘和设备延迟等因素是更大的因素，你应该从那里开始。

应用程序可能受益于自定义编译，只能运行在相对较新的英特尔酷睿i7或i5包括那些做vectormath和做大量的AESencryption和解密，或需要大量的随机数。 如果你想使用Intel DRBG，你现在也需要这样做。

如果这些都不适用于你，那么对于任何基于debian或red hat的发行版，你都会非常高兴，而且维护费用会less很多。

简短的回答…许多大规模和速度/延迟敏感的应用程序运行在标准的Linux发行版上。 红帽，CentOS，Debian，Ubuntu …在大多数情况下，它们都运行良好。 大部分收益来自应用程序调优，标准内核和操作系统优化和基础架构。

Gentoo可能会提供一些优化，但为更多的pipe理难题，减less的分享，减less的供应商和驱动程序支持，稳定性问题， 嘲笑和潜在的安全问题敞开大门。

我在高频金融交易环境中pipe理基于Gentoo的服务器。 尽pipe在Gentoo下有一些轻微的性能优势，但我仍然select了Red Hat和CentOS。 Gentoo在纸面上的优势可以通过更智能的硬件select，更好的服务器制造商/硬件集成支持，红帽工程师更智能的修补以及更多神秘技术（如内核旁路）轻松解决。

如果您正处于stream行应用程序堆栈（LAMP）的效率问题，请务必优化您的服务器硬件（CPUtypes，RAM布局），networking基础架构，监控系统，并能够识别系统瓶颈沿着这条路走下去

你现在是否遇到性能限制？

这取决于你的系统需要什么，在这里真的有三个学派（硬件和软件都是如此）

首先，就SF而言，大多数人都是主stream – 你想要知道的东西将会起作用，你需要支持 ，现在就需要它。 在这种情况下，使用基于redhat的系统（RHEL为您提供了极好的支持，而centos是经过良好testing的RHEL发行版的社区重build）。 但是，你不会得到最新，最好的。 在很多情况下，硬件也是如此。

其次是“中间路线”的观点，这是中间地带 – 像Ubuntu的东西。 你需要新的软件包（只需花费很less的代价就可以实现稳定的稳定性），你需要一个安装程序和好东西 。

在某些情况下，人们会遇到麻烦，但是你有新的软件包，而且testing是合理的 。 虽然这里对Ubuntu有很多的仇恨，但是它在设置的简易性和合理的新软件包之间做了很好的妥协。 Debian可能是一个稍微保守的select。 现在，甚至可以使用低延迟的内核来设置Ubuntu。 我倾向于感觉Ubuntu和Debian为我工作，但是ymmv。 很多地方部署了大量的服务器，如Facebook和谷歌去这个选项。

最后是基于源代码的发行版。 在大多数情况下，初始设置是后方彻底的痛苦。 你在设置内核时犯了一个错误？ 糟糕，花几个小时重新编译。 你也不会得到一个安装程序 – 这就是n00bs。 您经常会遇到一些尖端的应用程序，并且可以根据需要编译它们（例如，可以select优化以获得速度或内存使用）以及滚动版本。 如果你有非常具体的，深奥的需求，gentoo是伟大的。 如果你需要推出几十个系统，并想自动化…祝你好运。 基于源代码的分布根本不能缩放。 您获得了很多的灵活性，*一些**额外的速度，但没有可维护性与基于包的分布IMO相同的水平。 你不可能得到15％的额外速度，而且你最终可能会浪费时间来试图调整你的硬件的编译标志，如果你搞砸了，花时间去研究什么是失败的。

BSD是一个独立的操作系统。 有些人发誓（至less有一个comms room regular是freebsd用户），不同的BSD有不同的重点 – 比如openbsd是安全的，而freebsd是主stream的。 在某些情况下，它们可能不具备与Linux相同的硬件支持，但这取决于很多因素。

所有的观点当然是正确的。 我只想提出一个问题，即5％-15％的性能提升是无法实现的，特别是对于现代版本的GCC，它实际上取决于CPU架构，以及与作为目标的基线有多接近为二进制分布。 GCC -march =本地意志，除了使用ISA扩展也优化L1和L2caching/线路的大小。 正确alignment的代码（对于你的CPU）可以更快，特别是当使用-flto时，编译器可以知道需要考虑的一切。 [不幸的是，有些软件包目前与LTO分离]

此外，使用-Ofast编译select软件包，除了march = native和LTO之外，还可以产生显着的差异。

未来，如果GCC的石墨基础设施稳定下来，将有更大的收益。