我在某处读到，libc使用-march=native和-mtune=native标志重新编译将为程序提供最大的好处，其中使用共享库而不是静态库。这是真的吗？重新编译其他程序是否会有任何额外的好处？
答案1
和-march=native选项-mtune=native将确保生成的二进制文件最好地利用可用的处理器功能集和调度。任何性能提升都与通过使用附加处理器功能集可以优化多少应用程序代码有关。 （YMMV）。与通用二进制文件相比，优化的库和二进制文件应该运行得更快，但如果不进行测试就很难量化具体速度。因此，简单的回答是，通过 CPU 优化重新编译应用程序可能会提高性能，但是，维护自己的优化构建并跟上安全更新等可能会是一场噩梦。
答案2
没有简短而容易的答案。
1.
有很多参数，例如代码缓存/管道大小、缓存速度和主内存速度之间的差异、“-Os”与“-O2”、“-O3”的代码大小、使用某些通用“march=X/mtune”的代码大小=Y”设置与“=本机”。
当更多代码放入缓存时，这种性能提升可能会优于其他一些优化。一些优化增加了代码大小......
如果更多的代码适合缓存，更多并行运行的不同任务的代码适合缓存，这可能也是一个期望的方面......
需要进行大量研究才能提供详尽的答案。
2.
使用不同的编译器标志和选项可能会触发不同的错误和不当行为。
因此，重新编译像 libc 这样的核心部分甚至整个发行版将使您的错误报告对其他人无法使用，他们根本无法轻松地重现您的问题。你的设置变成了一座孤岛......
3.
社交方面：如果您不优化发行版的某些部分，则维护人员可以重播您安装的错误报告，并且发送错误报告将有助于改进该发行版。
4.
也许速度的提高并不值得花费数周的时间重新编译（如果不仅优化 libc）并让自己脱离主流。
...
如果您需要解决速度问题，更快的系统可能是有效的解决方案。
答案3
虽然有性能优势，但它们足够小，除非您将它们相互进行基准测试，否则您不会注意到它们。正如 Yeti 所写，影响速度的变量还有很多。一般来说，如果您使用二进制发行版，则不值得构建单个库的自定义版本，因为保持该库最新的责任将落在您身上，并且很容易忘记更新它。
有些计划可能比其他计划受益更多。尤其是数学密集型程序，例如folding@home或类似程序、加密货币挖掘、加密、媒体编码。它也将有助于媒体解码，但最重要的内容（如 MMX、AVX 和类似内容）将被编译，无论您使用什么格式，-march因此您可能不会注意到观看电影时的差异。另一方面，实时音频（如 JACK）可能会受益，因为最小的延迟会影响音质。与 libc 等基础库相比，如果检测到漏洞，这些库对于立即升级也不太重要，因为在升级之前您不能使用它们。
如果你有兴趣，可以尝试一下基于源代码的分发所有内容都将使用您选择的标志进行编译。代码在现代处理器上编译得非常快，因此不像以前那么痛苦。 Gentoo 是其中使用最多的。
除此之外，您还可以-march通过 /sys 文件系统使用许多可能比源代码更影响性能的参数。例如，/sys/block/sd?/queue/内部调度程序设置可能会极大地影响整体性能。我从 CFQ 切换到截止日期，它显着提高了我的特定工作负载的交互性能。应该说，CFQ 有一大堆设置，我也可以根据自己的喜好进行调整。
另一个“宝库”是/proc/sys/。例如，/proc/sys/vm/swappiness通过将旧内容移至交换区来调整以更改内存释放速度。红帽有一个很好的参数入门手册。
编辑：添加了几个更有可能从中受益的程序示例-march