在技術不斷更迭的軟件開發世界中，市場上 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】
閱讀更多 CSDN 的文章
