cpu和gcc編譯速度

① Clang 比 GCC 編譯器好在哪裡

編譯速度更快、編譯產出更小、出錯提示更友好。尤其是在比較極端的情況下。

兩年多前曾經寫過一個Scheme解釋器，詞法分析和語法解析部分大約2000行，用的是Boost.Spirit——一個重度依賴C++模版元編程的框架。當時攔姿孝用g++ 4.2編譯的情況是：

1.編譯速度極慢：完整編譯一次需要20分鍾

2.編譯過程中內存消耗極大：單個g++實例內存峰值消耗超過1G
3.中間產出物極大：編譯出的所有.o文件加在一起大約1~2G，debug鏈接產物超過200M
4.編譯錯誤極其難以理解：編譯錯誤經常長達幾十K，基本不可讀，最要命的是編譯錯誤經常會長到被g++截斷，看不到真正出錯的位置，基本上只能靠裸看代碼來調試
這里先不論我使用Spirit的方式是不是有問題，或者Spirit框架自身的問題。我當時因為實在忍受不了g++，轉而嘗試clang。當時用的是clang 2.8，剛剛可以完整編譯Boost，效果讓我很滿意：
1.編譯速度有顯著提升，記得大約是g++的1/3或1/4
2.編譯過程中的內存消耗差別好像不大
3.中間產出物及最終鏈接產物，記得也是g++的1/3或1/4
4.相較於g++，編譯錯誤可讀性有所飛躍，至少不會出現編譯錯誤過長被截斷的問題了
當時最大的缺點是clang編譯出的可執行文件無法用gdb調試，需要用調試器的時候還得用g++再編譯一遍。不過這個問題後來解決了，我不知道是clang支持了gdb還是gdb支持了clang。至少我當前在Ubuntu下用clang 3.0編譯出的二進制文件已經可以順利用gdb調試了冊羨。

最後一點，其他同學也有講到，就是Clang採用的簡稿是BSD協議。這是蘋果資助LLVM、FreeBSD淘汰GCC換用Clang的一個重要原因。

② GCC/G++，ICC，Clang，MSVC，BCC等C/C++編譯器有什麼特長和不足

clang編譯速度快，但是貌似編譯結果運行相對會慢。功能更新一般也比較快。
g++編譯速度比clang慢，編譯結果運行貌似比clang快。功能更新稍慢。
vc這幾年沒編譯過大工程，感覺上編譯速度在clang和g++之間。以過去的經驗g++和vc編譯結果運行速度差不多。功能更新上就是一坨屎。但是在Windows上寫點正經東西你可能不得不用它，相對的你也只能在Windows上用它。
icc很久沒用過，過去印象編譯速度很慢，運行速度最快但是感覺有點得不償失。最大的問題是這東西要錢，前三個都是免費的。
bcc直接無視就好了。

③ 請問windows中mingw做出的程序速度會比VC++和BCB慢很多嗎

不會。mingw/gcc的新版特別是4.7來編譯的win程序，比如使用了winapi的程序，
執行速度絲毫不比vc++或bcb或intel
cc慢。
gcc4.7的優化已經非常強勁了。
mingw慢的是編譯速度，比vc慢一個數量級。
mingw編譯的程序的執行速度，絲毫不慢。
實踐中像ffmpeg，ffdshow，mpc高清播放器這種視頻編碼和cpu媒體加速技術結合緊密程序，都用mingw編譯。測試效果和vc++、icc的或優或或劣比較不超過2%，可以忽略。
vc6/98編譯出的執行檔肯定比gcc4.7要差些，但vc6的編譯速度比gcc快

④ CPU性能大亂斗！國產CPU實力揭露

一直一來，缺芯少魂一直是中國信息產業的心病，中國的CPU市場也一直被Intel、ARM等國外廠商壟斷，龍芯、申威、飛騰等國產CPU在社會上也往往遭到別有用心之徒諸如「打磨晶元」、「騙經費」、「政績工程」等輿論抨擊。不久前，採用申威26010的神威太湖之光在TOP500刷榜，飛騰也公布了採用ARM指令集的飛騰1500A和飛騰2000，龍芯的3A3000也順利完成流片，那麼這些國產CPU的性能到底如何呢？

如何評價CPU

如何評價CPU的性能呢？從體系結構的角度來看，有個指標叫MIPS，即每分鍾執行多少條指令，執行指令數量越多，性能就越好，但這存在一個問題，當CPU指令集不同的時候，比較MIPS就意義不大了——比如A一條指令只算一個加法，B一條指令能做一個1024點的FFT。特別是在不同指令集的情況下，如何評價CPU的性能呢？

評價CPU性能必須考慮應用的多樣性，比如科學運算重視雙精浮點性能，但是如果數據供不上，運算能力再強也沒用；比如PC日常使用更偏重於定點性能；再比如計算中心多任務環境關注的是吞吐率......因此單純用某一個指標來衡量CPU性能是不科學的，必須綜合考量。

業界也推出了很多基準測試程序，比如針對CPU的SPEC，針對嵌入式應用的EEMBC等。SPEC測試是比較權威的測試程序。和一些黑箱測試程序調整計分方式和計分權重後測試結果就發旦搜生變化不同，SPEC測試到底跑了什麼程序，以及各項程序跑分和計分方式全部公開透明，而御兆且覆蓋范圍廣——SPEC2000有12個定點程序，14個浮點程序，而且有比較強的代表性，比如gzip、vpr、gcc、mef、eon等。而SPEC2006則把定點程序擴展到14個定點程序和16個浮點程序。

在計分方法上，SPEC在計分上採用歸一化的幾何平均方法來進行綜合性能評估——將不同CPU的執行時間與參照對象相比較後得到一個相對值。SEPC2000的參照對象是Ultra SPARC 2工作站的主頻為300Mhz的CPU。如果運行測試程序1的時間是參照對象的十分之一的話，測試就是1000分，測試程序2的耗時是參照對象的八分之一的話，則為800分.....最後再算幾何平均——比如SEPC2000有12個定點測試，就將12個測試成績相乘再開12次方，SPEC2006相對於SPEC2000而言僅僅是擴展了幾項測試程序，使測試更加科學合理。這里，我們以三星獵戶座7420和華為麒麟950為例計算SPEC測試成績。

「科普中國」是中國科協攜同社會各方利用信息化手段開展科學傳播的科學權威品牌。

本文由科普中國融合創作出品，轉載請註明出處。

⑤ Intel C++ Compiler與gcc對比有什麼優缺點

icc 是Intel公司專門為Wintel平台設計，有針對性的做了優化，缺陷也很顯然，既然有針對性，也就不具備通用性。使用icc編譯，可能會使編譯出來的程序有更好的執行效率，但也可能使其在非Intel CPU上運行異常。並且，在某些情況下，即使在Wintel平台上也會崩潰。
gcc的優勢在於其通用性，目前主流的所有平台，它基本上都支持。使用-O3優化編譯後的執行效率，也不錯。
在Win平台上，編譯後執行效率最好的，依然是微軟的vs，這可能與win系統是他們家出的有關。
使用icc帶來的優勢，並不突出，還是建議不要用了。
如果限定在win平台上開發，使用vc或gcc更合適一些。我個人推薦gcc，vc的ide環境過於龐大，不太喜歡，但win平台上主流的c開發工具還是vc，有不少開源的工程都使用它，如果你用到了這些開源代碼，就不得不用了。

⑥ 如何加快linux android 的編譯速度

項目越來越大，每次需要重新編譯整個項目都是一件很浪費時間的事情。Research了一下，找到以下可以幫助提高速度的方法，總結一下。
1. 使用tmpfs來代替部分IO讀寫
2.ccache，可以將ccache的緩存文件設置在tmpfs上，但是這樣的話，每次開機後，ccache的緩存文件會丟失
3.distcc,多機器編譯
4.將屏幕輸出列印到內存文件或者/dev/null中，避免終端設備（慢速設備）拖慢速度。

tmpfs
有人說在Windows下用了RAMDisk把一個項目編譯時間從4.5小時減少到了5分鍾，也許這個數字是有點誇張了，不過粗想想，把文件放到內存上做編譯應該是比在磁碟上快多了吧，尤其如果編譯器需要生成很多臨時文件的話。
這個做法的實現成本最低，在Linux中，直接mount一個tmpfs就可以了。而且對所編譯的工程沒有任何要求，也不用改動編譯環境。
mount -t tmpfs tmpfs ~/build -o size=1G
用2.6.32.2的Linux Kernel來測試一下編譯速度：
用物理磁碟：40分16秒
用tmpfs：39分56秒
呃……沒什麼變化。看來編譯慢很大程度上瓶頸並不在IO上面。但對於一個實際項目來說，編譯過程中可能還會有打包等IO密集的操作，所以只要可能，用tmpfs是有益無害的。當然對於大項目來說，你需要有足夠的內存才能負擔得起這個tmpfs的開銷。
make -j
既然IO不是瓶頸，那CPU就應該是一個影響編譯速度的重要因素了。
用make -j帶一個參數，可以把項目在進行並行編譯，比如在一台雙核的機器上，完全可以用make -j4，讓make最多允許4個編譯命令同時執行，這樣可以更有效的利用CPU資源。
還是用Kernel來測試：
用make： 40分16秒
用make -j4：23分16秒
用make -j8：22分59秒
由此看來，在多核CPU上，適當的進行並行編譯還是可以明顯提高編譯速度的。但並行的任務不宜太多，一般是以CPU的核心數目的兩倍為宜。
不過這個方案不是完全沒有cost的，如果項目的Makefile不規范，沒有正確的設置好依賴關系，並行編譯的結果就是編譯不能正常進行。如果依賴關系設置過於保守，則可能本身編譯的可並行度就下降了，也不能取得最佳的效果。
ccache
ccache工作原理：
ccache也是一個編譯器驅動器。第一趟編譯時ccache緩存了GCC的「-E」輸出、編譯選項以及.o文件到$HOME/.ccache。第二次編譯時盡量利用緩存，必要時更新緩存。所以即使"make clean; make"也能從中獲得好處。ccache是經過仔細編寫的，確保了與直接使用GCC獲得完全相同的輸出。

ccache用於把編譯的中間結果進行緩存，以便在再次編譯的時候可以節省時間。這對於玩Kernel來說實在是再好不過了，因為經常需要修改一些Kernel的代碼，然後再重新編譯，而這兩次編譯大部分東西可能都沒有發生變化。對於平時開發項目來說，也是一樣。為什麼不是直接用make所支持的增量編譯呢？還是因為現實中，因為Makefile的不規范，很可能這種「聰明」的方案根本不能正常工作，只有每次make clean再make才行。
安裝完ccache後，可以在/usr/local/bin下建立gcc，g++，c++，cc的symbolic link，鏈到/usr/bin/ccache上。總之確認系統在調用gcc等命令時會調用到ccache就可以了（通常情況下/usr/local /bin會在PATH中排在/usr/bin前面）。
安裝的另外一種方法：
vi ~/.bash_profile
把/usr/lib/ccache/bin路徑加到PATH下
PATH=/usr/lib/ccache/bin:$PATH:$HOME/bin
這樣每次啟動g++的時候都會啟動/usr/lib/ccache/bin/g++，而不會啟動/usr/bin/g++
效果跟使用命令行ccache g++效果一樣
這樣每次用戶登錄時，使用g++編譯器時會自動啟動ccache
繼續測試：
用ccache的第一次編譯(make -j4)：23分38秒
用ccache的第二次編譯(make -j4)：8分48秒
用ccache的第三次編譯(修改若干配置，make -j4)：23分48秒

看來修改配置（我改了CPU類型...）對ccache的影響是很大的，因為基本頭文件發生變化後，就導致所有緩存數據都無效了，必須重頭來做。但如果只是修改一些.c文件的代碼，ccache的效果還是相當明顯的。而且使用ccache對項目沒有特別的依賴，布署成本很低，這在日常工作中很實用。
可以用ccache -s來查看cache的使用和命中情況：
cache directory /home/lifanxi/.ccachecache hit 7165cache miss 14283called for link 71not a C/C++ file 120no input file 3045files in cache 28566cache size 81.7 Mbytesmax cache size 976.6 Mbytes
可以看到，顯然只有第二編次譯時cache命中了，cache miss是第一次和第三次編譯帶來的。兩次cache佔用了81.7M的磁碟，還是完全可以接受的。
distcc
一台機器的能力有限，可以聯合多台電腦一起來編譯。這在公司的日常開發中也是可行的，因為可能每個開發人員都有自己的開發編譯環境，它們的編譯器版本一般是一致的，公司的網路也通常具有較好的性能。這時就是distcc大顯身手的時候了。
使用distcc，並不像想像中那樣要求每台電腦都具有完全一致的環境，它只要求源代碼可以用make -j並行編譯，並且參與分布式編譯的電腦系統中具有相同的編譯器。因為它的原理只是把預處理好的源文件分發到多台計算機上，預處理、編譯後的目標文件的鏈接和其它除編譯以外的工作仍然是在發起編譯的主控電腦上完成，所以只要求發起編譯的那台機器具備一套完整的編譯環境就可以了。
distcc安裝後，可以啟動一下它的服務：
/usr/bin/distccd --daemon --allow 10.64.0.0/16
默認的3632埠允許來自同一個網路的distcc連接。
然後設置一下DISTCC_HOSTS環境變數，設置可以參與編譯的機器列表。通常localhost也參與編譯，但如果可以參與編譯的機器很多，則可以把localhost從這個列表中去掉，這樣本機就完全只是進行預處理、分發和鏈接了，編譯都在別的機器上完成。因為機器很多時，localhost的處理負擔很重，所以它就不再「兼職」編譯了。
export DISTCC_HOSTS="localhost 10.64.25.1 10.64.25.2 10.64.25.3"
然後與ccache類似把g++，gcc等常用的命令鏈接到/usr/bin/distcc上就可以了。
在make的時候，也必須用-j參數，一般是參數可以用所有參用編譯的計算機CPU內核總數的兩倍做為並行的任務數。
同樣測試一下：
一台雙核計算機，make -j4：23分16秒
兩台雙核計算機，make -j4：16分40秒
兩台雙核計算機，make -j8：15分49秒
跟最開始用一台雙核時的23分鍾相比，還是快了不少的。如果有更多的計算機加入，也可以得到更好的效果。
在編譯過程中可以用distccmon-text來查看編譯任務的分配情況。distcc也可以與ccache同時使用，通過設置一個環境變數就可以做到，非常方便。
總結一下：
tmpfs： 解決IO瓶頸，充分利用本機內存資源
make -j： 充分利用本機計算資源
distcc： 利用多台計算機資源
ccache： 減少重復編譯相同代碼的時間
這些工具的好處都在於布署的成本相對較低，綜合利用這些工具，就可以輕輕鬆鬆的節省相當可觀的時間。上面介紹的都是這些工具最基本的用法，更多的用法可以參考它們各自的man page。
5.還有提速方法是把屏幕輸出重定向到內存文件或/dev/null,因對終端設備(慢速設備)的阻塞寫操作也會拖慢速度。推薦內存文件，這樣發生錯誤時，能夠查看。

⑦ Linux下gcc編譯介紹

Linux系統下的Gcc（GNU C Compiler）是GNU推出的功能強大、性能優越的多平台編譯器，是GNU的代表作品之一。gcc是可以在多種硬體平台上編譯出可執行程序的超級編譯器，其執行效率與一般的編譯器相比平均效率要高20%~30%。
Gcc編譯器能將C、C++語言源程序、匯程式化序和目標程序編譯、連接成可執行文件，如果沒有給出可執行文件的名字，gcc將生成一個名為a.out的文件。在Linux系統中，可執行文件沒有統一的後綴，系統從文件的屬性來區分可執行文件和不可執行文件。而gcc則通過後綴來區別輸入文件的類別，下面我們來介紹gcc所遵循的部分約定規則。
.c為後綴的文件，C語言源代碼文件；
.a為後綴的文件，是由目標文件構成的檔案庫文件；
.C，.cc或.cxx 為後綴的文件，是C++源代碼文件；
.h為後綴的文件，是程序所包含的頭文件；
.i 為後綴的文件，是已經預處理過的C源代碼文件；
.ii為後綴的文件，是已經預處理過的C++源代碼文件；
.m為後綴的文件，是Objective-C源代碼文件；
.o為後綴的文件，是編譯後的目標文件；
.s為後綴的文件，是匯編語言源代碼文件；
.S為後綴的文件，是經過預編譯的匯編語言源代碼文件。
Gcc的執行過程
雖然我們稱Gcc是C語言的編譯器，但使用gcc由C語言源代碼文件生成可執行文件的過程不僅僅是編譯的過程，而是要經歷四個相互關聯的步驟∶預處理(也稱預編譯，Preprocessing)、編譯(Compilation)、匯編(Assembly)和連接(Linking)。
命令gcc首先調用cpp進行預處理，在預處理過程中，對源代碼文件中的文件包含(include)、預編譯語句(如宏定義define等)進行分析。接著調用cc1進行編譯，這個階段根據輸入文件生成以.o為後綴的目標文件。匯編過程是針對匯編語言的步驟，調用as進行工作，一般來講，.S為後綴的匯編語言源代碼文件和匯編、.s為後綴的匯編語言文件經過預編譯和匯編之後都生成以.o為後綴的目標文件。當所有的目標文件都生成之後，gcc就調用ld來完成最後的關鍵性工作，這個階段就是連接。在連接階段，所有的目標文件被安排在可執行程序中的恰當的位置，同時，該程序所調用到的庫函數也從各自所在的檔案庫中連到合適的地方。

Gcc的基本用法和選項
在使用Gcc編譯器的時候，我們必須給出一系列必要的調用參數和文件名稱。Gcc編譯器的調用參數大約有100多個，其中多數參數我們可能根本就用不到，這里只介紹其中最基本、最常用的參數。
Gcc最基本的用法是∶gcc [options] [filenames]
其中options就是編譯器所需要的參數，filenames給出相關的文件名稱。
-c，只編譯，不連接成為可執行文件，編譯器只是由輸入的.c等源代碼文件生成.o為後綴的目標文件，通常用於編譯不包含主程序的子程序文件。
-o output_filename，確定輸出文件的名稱為output_filename，同時這個名稱不能和源文件同名。如果不給出這個選項，gcc就給出預設的可執行文件a.out。
-g，產生符號調試工具(GNU的gdb)所必要的符號資訊，要想對源代碼進行調試，我們就必須加入這個選項。
-O，對程序進行優化編譯、連接，採用這個選項，整個源代碼會在編譯、連接過程中進行優化處理，這樣產生的可執行文件的執行效率可以提高，但是，編譯、連接的速度就相應地要慢一些。
-O2，比-O更好的優化編譯、連接，當然整個編譯、連接過程會更慢。
-Idirname，將dirname所指出的目錄加入到程序頭文件目錄列表中，是在預編譯過程中使用的參數。C程序中的頭文件包含兩種情況∶
A)#include
B)#include 「myinc.h」
其中，A類使用尖括弧(< >)，B類使用雙引號(「 」)。對於A類，預處理程序cpp在系統預設包含文件目錄(如/usr/include)中搜尋相應的文件，而對於B類，cpp在當前目錄中搜尋頭文件，這個選項的作用是告訴cpp，如果在當前目錄中沒有找到需要的文件，就到指定的dirname目錄中去尋找。在程序設計中，如果我們需要的這種包含文件分別分布在不同的目錄中，就需要逐個使用-I選項給出搜索路徑。
-Ldirname，將dirname所指出的目錄加入到程序函數檔案庫文件的目錄列表中，是在連接過程中使用的參數。在預設狀態下，連接程序ld在系統的預設路徑中(如/usr/lib)尋找所需要的檔案庫文件，這個選項告訴連接程序，首先到-L指定的目錄中去尋找，然後到系統預設路徑中尋找，如果函數庫存放在多個目錄下，就需要依次使用這個選項，給出相應的存放目錄。
-lname，在連接時，裝載名字為「libname.a」的函數庫，該函數庫位於系統預設的目錄或者由-L選項確定的目錄下。例如，-lm表示連接名為「libm.a」的數學函數庫。
上面我們簡要介紹了gcc編譯器最常用的功能和主要參數選項，更為詳盡的資料可以參看Linux系統的聯機幫助。
假定我們有一個程序名為test.c的C語言源代碼文件，要生成一個可執行文件，最簡單的辦法就是∶
gcc test.c
這時，預編譯、編譯連接一次完成，生成一個系統預設的名為a.out的可執行文件，對於稍為復雜的情況，比如有多個源代碼文件、需要連接檔案庫或者有其他比較特別的要求，就要給定適當的調用選項參數。再看一個簡單的例子。
整個源代碼程序由兩個文件testmain.c 和testsub.c組成，程序中使用了系統提供的數學庫，同時希望給出的可執行文件為test，這時的編譯命令可以是∶
gcc testmain.c testsub.c □lm □o test
其中，-lm表示連接系統的數學庫libm.a。

Gcc的錯誤類型及對策
Gcc編譯器如果發現源程序中有錯誤，就無法繼續進行，也無法生成最終的可執行文件。為了便於修改，gcc給出錯誤資訊，我們必須對這些錯誤資訊逐個進行分析、處理，並修改相應的語言，才能保證源代碼的正確編譯連接。gcc給出的錯誤資訊一般可以分為四大類，下面我們分別討論其產生的原因和對策。

第一類∶C語法錯誤
錯誤資訊∶文件source.c中第n行有語法錯誤(syntex errror)。這種類型的錯誤，一般都是C語言的語法錯誤，應該仔細檢查源代碼文件中第n行及該行之前的程序，有時也需要對該文件所包含的頭文件進行檢查。有些情況下，一個很簡單的語法錯誤，gcc會給出一大堆錯誤，我們最主要的是要保持清醒的頭腦，不要被其嚇倒，必要的時候再參考一下C語言的基本教材。
第二類∶頭文件錯誤
錯誤資訊∶找不到頭文件head.h(Can not find include file head.h)。這類錯誤是源代碼文件中的包含頭文件有問題，可能的原因有頭文件名錯誤、指定的頭文件所在目錄名錯誤等，也可能是錯誤地使用了雙引號和尖括弧。

第三類∶檔案庫錯誤
錯誤資訊∶連接程序找不到所需的函數庫，例如∶
ld: -lm: No such file or directory
這類錯誤是與目標文件相連接的函數庫有錯誤，可能的原因是函數庫名錯誤、指定的函數庫所在目錄名稱錯誤等，檢查的方法是使用find命令在可能的目錄中尋找相應的函數庫名，確定檔案庫及目錄的名稱並修改程序中及編譯選項中的名稱。
第四類∶未定義符號
錯誤資訊∶有未定義的符號(Undefined symbol)。這類錯誤是在連接過程中出現的，可能有兩種原因∶一是使用者自己定義的函數或者全局變數所在源代碼文件，沒有被編譯、連接，或者乾脆還沒有定義，這需要使用者根據實際情況修改源程序，給出全局變數或者函數的定義體；二是未定義的符號是一個標準的庫函數，在源程序中使用了該庫函數，而連接過程中還沒有給定相應的函數庫的名稱，或者是該檔案庫的目錄名稱有問題，這時需要使用檔案庫維護命令ar檢查我們需要的庫函數到底位於哪一個函數庫中，確定之後，修改gcc連接選項中的-l和-L項。
排除編譯、連接過程中的錯誤，應該說這只是程序設計中最簡單、最基本的一個步驟，可以說只是開了個頭。這個過程中的錯誤，只是我們在使用C語言描述一個演算法中所產生的錯誤，是比較容易排除的。我們寫一個程序，到編譯、連接通過為止，應該說剛剛開始，程序在運行過程中所出現的問題，是演算法設計有問題，說得更玄點是對問題的認識和理解不夠，還需要更加深入地測試、調試和修改。一個程序，稍為復雜的程序，往往要經過多次的編譯、連接和測試、修改。下面我們學習的程序維護、調試工具和版本維護就是在程序調試、測試過程中使用的，用來解決調測階段所出現的問題。窗體頂端
窗體底端

⑧ Intel C++ Compiler與gcc對比有什麼優缺點

icc 是Intel公司專門為Wintel平台設計，有針對性的做了優化，缺陷也很顯然，既然有針對性，也就不具備通用性。使用icc編譯，可能會使編譯出來的程序有更漏漏好的執行效率，但也可能使其在非Intel CPU上運行異常。並且，在某些情況下，即使在Wintel平台上也返巧爛會崩潰。
gcc的優勢在於其通用性，目前主流的所有平台，寬讓它基本上都支持。使用-O3優化編譯後的執行效率，也不錯。
在Win平台上，編譯後執行效率最好的，依然是微軟的vs，這可能與win系統是他們家出的有關。
使用icc帶來的優勢，並不突出，還是建議不要用了。
如果限定在win平台上開發，使用vc或gcc更合適一些。我個人推薦gcc，vc的ide環境過於龐大，不太喜歡，但win平台上主流的c開發工具還是vc，有不少開源的工程都使用它，如果你用到了這些開源代碼，就不得不用了。

⑨ 綜合來說，幾大主流C++編譯器(icc,gcc,clang,vc++等)究竟孰優孰劣

我曾編出各種C++ 11編譯器的支持，並有C++ 14編譯器支持一批。

實際使用

對VC編譯的速度不斷提高，內存佔用已經從VC12開始明顯提高，而最明顯的是可變參數模板。還有內置的代碼靜態分析，在實際中很有用。32位保護模式下，ss寄存器存的是一個段選擇子，選擇子是一個數字，通過IDT(局部描述符表)或者GDT(全局描述符表)選擇一個段描述符，描述符裡面的信息包含該段的取值范圍和大小。

vc14的靜態分析不在每次載入一個ie（對，以前每分析一個.cpp，就載入一次ie！），速度快了相當多。

⑩ 求助，gcc的編譯過程太慢

RH，SUSE系列可以用rpm包安裝
Debian系列可以apt安裝
沒用過多個版本gcc並存，不過gcc4重寫了前端，應該加快速度的！