在技术不断更迭的软件开发世界中，市场上 C++ 编译器的数量开始持续呈现下降趋势。而随着新的高级 C++ 标准（C++ 17、C++ 20）、新的指令集扩展、以及代码优化的更高标准的出现，究竟什么样的编译器才算优秀？

作者 | Agner

译者 | 苏本如，责编 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下为译文：

近年来，市场上C++编译器的数量有所下降。一些不太知名的编译器已经退出市场，甚至一度非常流行的Borland（Embarcadero）C++编译器现在也不再被维护。随着新的高级C++标准（C++ 17、C++ 20）、新的指令集扩展（如带有数百条新指令的AVX512），以及代码优化的更高标准的出现，编译器的构建变得更加复杂。

微软Visual Studio非常流行，因为它具有用户友好的集成开发环境（IDE）和优秀的调试和交叉引用功能。但是Visual Studio在支持最新的指令集方面已经落后，在代码优化方面它也不是最好的编译器。

英特尔编译器在代码优化方面曾经处于领先地位，但是它现在已经被Gcc和Clang超越。而且，英特尔编译器因为其隐藏的“让AMD变残”的功能被曝光后，也不再受欢迎了。

开源编译器Gcc和Clang现在已经占据领先地位。这两个编译器非常相似。两者都支持所有平台和最新的指令集扩展。

我已经测试了不同的C++编译器，并把测试结果列在了我的C++手册中。在代码优化方面，Gcc和Clang编译器显然是最好的。Clang在某些方面优于Gcc，但它有过度循环展开的倾向，这是对代码缓存的浪费。我必须承认，当LLVM/CLAN项目启动时，我对它非常怀疑，但是当人们投入了大量的工作后，现在的Clang编译器在多个量度上已经胜过所有其它编译器。

在Linux和Mac上工作的程序员找到Clang编译器时不会有任何问题。但是在Windows上有点复杂。Windows至少有两个现成的Clang编译器版本。Cygwin版本和Visual Studio插件版本。

Clang编译器的Cygwin版本已经存在好几年了，但是它还不是最新的，并且它有一些性能问题。默认情况下，Clang的Cygwin64版本使用的是中等内存模型。这是相当浪费的，因为它为静态变量和常量使用64位绝对地址，而不是32位相对地址。你可以通过指定mcmodel=small来提高性能。中等内存模型只有在直接链接到外部DLL中的变量时才需要（这无论如何都是不好的编程实践）。Cygwin版本的另一个缺点是，在分发可执行文件时必须包含Cygwin DLL。

最近，微软将Cygwin版本作为Visual Studio的插件提供。我的测试表明，它生成了非常优化的代码。Cygwin插件尚未集成到MSBuild框架中。它现在只支持CMake框架，使用起来相当复杂，因为你必须手动指定一个奇怪的微软命令行选项和Clang选项的组合。事实上，我发现在没有Visual Studio CMake框架的情况下，将Clang编译器作为命令行工具使用更加方便。

微软已经宣布，Clang与MSBuild框架的全面集成即将到来。希望微软能够兑现这个承诺。我们期待可能是最好的优化编译器和用户最友好的IDE框架的这一集成能够尽快发生。

从长远来看，我猜测Clang编译器最终会取代微软自己的编译器。没有理由微软件会花费大量的资源来开发一个自己的编译器，而它的性能无论如何都无法超越一个免费的开源编译器。Visual Studio IDE仍然可以被维护，因为它非常有用，并且很多当前的项目都依赖于它，即使它的后端将有一个不同的编译器。

我更加不确定英特尔编译器的未来命运。当越来越少的程序员实际使用它时，英特尔会继续维护它吗？英特尔编译器附带了一些非常有用的函数库，可用于许多特殊用途，但这些函数库与其他编译器的工作原理是一样的。

原文：https://www.agner.org/optimize/blog/read.php?i=1015

本文为 CSDN 翻译，转载请注明来源出处。

【END】