在技术不断更迭的软件开发世界中,市场上 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】