編譯器性能提升

㈠ 如何加快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,因對終端設備(慢速設備)的阻塞寫操作也會拖慢速度。推薦內存文件，這樣發生錯誤時，能夠查看。

㈡ c++builder編譯速度太慢，能不能通過設置來加快

C＋＋builder是最快的C＋＋編譯器之一，從編譯速度來說也可以說是最快的win32C＋＋編譯器了。除了速度之外，C++builder的性能也在其它C＋＋編譯器的之上，但許多delphi程序員仍受不了c++builder工程的編譯速度。的確，delphi的速度要比任和c++的編譯器都要快好多。Delphi在編譯一個小工程的時候可能不到一秒，大的工程一般也在5秒鍾這內編譯完成了。

為什麼delphi會比c++builder快這么多？是否有方法來c++builder的編譯速度？本文就講解了為什麼C＋＋的編譯器速度會慢，並且介紹了一個簡單的方法來減少c++builder的編譯時間。

為什麼c++編譯器的速度會慢？
c++builder 使用者怎麼通過預編譯頭文件來減少編譯時間？
講解基於VCL可視化工程的預編譯頭文件方法
優化c++builder對預編譯頭文件的使用
結論
注意事項

為什麼c++編譯器速度慢？

在C＋＋中，你只能使用預定義或是預先聲明了的函數，這意味什麼？來看一個簡單的例子，函數A()調用函數B（），函數A（）只能在函數B（）的原型或是函數體在A（）之前才能調用它

㈢ 應用編譯優化有什麼用

應用編譯優化的作用是：提高運行能力因為程序優化前，有3個變數需要3個寄存器，一次乘法運算。程序優化後，只有1個變數需要一個寄存器，沒有乘法運算。

並且這個優化看起來很微不足道，但實際上用途很廣。為了程序的可讀性和可維護性，大多數程序員應該還是會選用第一種方式。

寫3行程序而不是直接甩下一行int ticks = 491520讓後來讀程序的人摸不到頭腦。有了編譯器的優化，程序員既可以寫出易讀的程序又不必擔心性能受影響。

尤其是在嵌入式領域，很多低端晶元根本就沒有硬體乘法器，如果程序不做上述優化可能這3行代碼需要幾十個cycle，優化過後一個cycle就搞定。

應用編譯優化的級別：

第一級：代碼調整。

代碼調整是一種局部的思維方式；基本上不觸及演算法層級；它面向的是代碼，而不是問題； 所以：語句調整，用匯編重寫、指令調整、換一種語言實現、換一個編譯器、循環展開、參數傳遞優化等都屬於這一級。

第二級：新的視角。

新的視角強調的重點是針對問題的演算法；即選擇和構造適合於問題的演算法。

第三級：表驅動狀態機。

將問題抽象為另一種等價的數學模型或假想機器模型，比如構造出某種表驅動狀態機；這一級其實是第二級的延伸，只是產生的效果更加明顯，但它有其本身的特點。

㈣ 不同編譯器的x265性能是否有差距

不同編譯器的x265性能是有差距的：
MSVC系列的編譯器都是渣優化，icc是針對跑分優化的，做不得數。目前來看gcc -O3的優化是最好的。
x265默認使用gcc編譯就開了-O3選項。

㈤ 通過編譯器對程序優化來改進cache性能的方法有哪幾種

你的程序可能太短，看不出區別來，你比對一下她們生成的匯編碼就知道了

CPU 緩存是為了提高程序運行的性能，CPU 在很多處理上內部架構做了很多調整，比如 CPU 高速緩存，大家都知道因為硬碟很慢，可以通過緩存把數據載入到內存裡面，提高訪問速度，而 CPU 處理也有這個機制，盡可能把處理器訪問主內存時間開銷放在 CPU 高速緩存上面，CPU 訪問速度相比內存訪問速度又要快好多倍，這就是目前大多數處理器都會去利用的機制，利用處理器的緩存以提高性能。

就算優化帶來的效果非常有限，但是經過長年累月的持續優化，效果也是非常明顯的，比如當年的Chrome瀏覽器就是靠打開網頁非常快從而打敗微軟系統自帶的IE瀏覽器。電腦手機等硬體的性能是有限的，不同的演算法會產生不同的效率，今天我們就簡單說一個選擇問題，開發程序時是節省內存還是節省計算量。

㈥ 英偉達CPU問世：ARM架構，對比x86實現十倍性能提升

機器之心報道

機器之心編輯部

「只需一張 GeForce 顯卡，每個學生都可以擁有一台超級計算機，這正是 Alex Krizhevsky、Ilya 和 Hinton 當年訓練 AI 模型 AlexNet 的方式。通過搭載在超級計算機中的 GPU，我們現在能讓科學家們在 youxian 的一生之中追逐無盡的科學事業，」英偉達創始人兼首席執行官黃仁勛說道。

4 月 12 日晚，英偉達 GTC 2021 大會在線上開始了。或許是因為長期遠程辦公不用出門，人們驚訝地看到在自家廚房講 Keynote 的黃老闆居然留了一頭搖滾范的長發：

如果你只是對他的黑色皮衣印象深刻，先對比一下 2019、2020 和 2021 的 GTC，老黃氣質越來越搖滾。如此氣質，黃仁勛今天推出的新產品肯定將會與眾不同。

「這是世界第一款為 terabyte 級別計算設計的 CPU，」在 GTC 大會上，黃仁勛祭出了英偉達的首款中央處理器 Grace，其面向超大型 AI 模型的和高性能計算。

英偉達也要做 CPU 了

Grace 使用相對能耗較低的 Arm 核心，但它又可以為訓練超大 AI 模型的系統提供 10 倍左右的性能提升。英偉達表示，它是超過一萬名工程人員歷經幾年的研發成果，旨在滿足當前世界最先進應用程序的計算需求，其具備的計算性能和吞吐速率是以往任何架構所無法比擬的。

「結合 GPU 和 DPU，Grace 為我們提供了第三種基礎計算能力，並具備重新定義數據中心架構，推進 AI 前進的能力，」黃仁勛說道。

Grace 的名字來自於計算機科學家、世界最早一批的程序員，也是最早的女性程序員之一的格蕾絲 · 赫柏（Grace Hopper）。她創造了現代第一個編譯器 A-0 系統，以及第一個高級商用計算機程序語言「COBOL」。計算機術語「Debug」（調試）便是她在受到從電腦中驅除蛾子的啟發而開始使用的，於是她也被冠以「Debug 之母」的稱號。

英偉達的 Grace 晶元利用 Arm 架構的靈活性，是專為加速計算而設計的 CPU 和伺服器架構，可用於訓練具有超過 1 萬億參數的下一代深度學習預訓練模型。在與英偉達的 GPU 結合使用時，整套系統可以提供相比當今基於 x86 CPU 的最新 NVIDIA DGX 快 10 倍的性能。

目前英偉達自家的 DGX，使用的是 AMD 7 納米製程的 Rome 架構 CPU。

據介紹，Grace 採用了更為先進的 5nm 製程，在內部通信能力上，它使用了英偉達第四代 NVIDIA NVLink，在 CPU 和 GPU 之間提供高達 900 GB/s 的雙向帶寬，相比之前的產品提升了八倍。Grace 還是第一個通過錯誤校正代碼（ECC）等機制利用 LPDDR5x 內存系統提供伺服器級可靠性的 CPU，同時提供 2 倍的內存帶寬和高達 10 倍的能源效率。在架構上，它使用下一代 Arm Neoverse 內核，以高能效的設計提供高性能。

基於這款 CPU 和仍未發布的下一代 GPU，瑞士國家超級計算中心、蘇黎世聯邦理工大學將構建一台名為「阿爾卑斯」的超級計算機，算力 20Exaflops（目前全球第一超算「富岳」的算力約為 0.537Exaflops），將實現兩天訓練一次 GPT-3 模型的能力，比目前基於英偉達 GPU 打造的 Selene 超級計算機快 7 倍。

美國能源部下屬的洛斯阿拉莫斯國家實驗室也將在 2023 年推出一台基於 Grace 的超級計算機。

GPU+CPU+DPU，三管齊下

「簡單說來，目前市場上每年交付的 3000 萬台數據中心伺服器中，有 1/3 用於運行軟體定義的數據中心堆棧，其負載的增長速度遠遠快於摩爾定律。除非我們找到加速的辦法，否則用於運行應用的算力將會越來越少，」黃仁勛說道。「新時代的計算機需要新的晶元、新的系統架構、新的網路、新的軟體和工具。」

除了造 CPU 的大新聞以外，英偉達還在一個半小時的 Keynote 里陸續發布了大量重要軟硬體產品，覆蓋了 AI、 汽車 、機器人、5G、實時圖形、雲端協作和數據中心等領域的最新進展。英偉達的技術，為我們描繪出了一幅令人神往的未來願景。

黃仁勛表示，英偉達全新的數據中心路線圖已包括 CPU、GPU 和 DPU 三類晶元，而 Grace 和 BlueField 是其中必不可少的關鍵組成部分。投身 Arm 架構的 CPU，並不意味著英偉達會放棄原有的 x86、Power 等架構，黃仁勛將英偉達重新定義為「三晶元」公司，覆蓋 CPU、GPU 和 DPU。

對於未來的發展節奏，黃仁勛表示：「我們的發展將覆蓋三個產品線——CPU、GPU 和 DPU，以每兩年一次更新的節奏進行，第一年更新 x86，第二年就更新 Arm。」

最後是自動駕駛。「對於 汽車 而言，更高的算力意味著更加智能化，開發者們也能讓產品更快迭代。TOPS 就是新的馬力，」黃仁勛說道。

英偉達將於 2022 年投產的 NVIDIA 自動駕駛 汽車 計算系統級晶元——NVIDIA DRIVE Orin，旨在成為覆蓋自動駕駛和智能車機的 汽車 中央電腦。搭載 Orin 的量產車現在還沒法買到，但英偉達已經在為下一代，超過 L5 駕駛能力的計算系統作出計劃了。

Atlan 是這家公司為 汽車 行業設計的下一代 SoC，其將採用 Grace 下一代 CPU 和下一代安培架構 GPU，同時也集成數據處理單元 (DPU)。如此一來，Atlan 可以達到每秒超過 1000 萬億次（TOPS）運算次數。如果一切順利的話，2025 年新生產的車型將會搭載 Atlan 晶元。

與此同時，英偉達還展示了 Hyperion 8 自動駕駛 汽車 平台，業內算力最強的自動駕駛 汽車 模板——搭載了 3 套 Orin 中心計算機。

不知這些更強的晶元和系統，能否應付未來幾年裡人們對於算力無窮無盡的需求。在 GTC 2021 上，英偉達對於深度學習模型的指數增長圖又更新了。「三年間，大規模預訓練模型的參數量增加了 3000 倍。我們估計在 2023 年會出現 100 萬億參數的模型。」黃仁勛說道。

英偉達今天發布的一系列產品，讓這家公司在幾乎所有行業和領域都能為你提供最強大的機器學習算力。在黃仁勛的 Keynote 發表時，這家公司的股票一度突破了 600 美元大關。

「20 年前，這一切都只是科幻小說的情節；10 年前，它們只是夢想；今天，我們正在實現這些願景。

英偉達每年在 GTC 大會上發布的新產品，已經成為了行業發展的風向。不知在 Grace 推出之後，未來我們的伺服器和電腦是否會快速進入 Arm 時代。

㈦ 在不考慮編譯器優化等因素下，下面那個運算比較快

下面是在編譯器不優化的情況下的代碼反匯編後的結果
14: if (a > b)//我們看到，只有3條指令，
0040104D mov edx,dword ptr [ebp-4] //將a放入寄存器EDX
00401050 cmp edx,dword ptr [ebp-8] //比較EDX和b的大小
00401053 jle main+3Ch (0040105c) //如果a<b跳轉到0040105c
15: {
16: return 1;
00401055 mov eax,1
0040105A jmp main+4Fh (0040106f)
17: }
18: if (a - b > 0)//我們看到有4條指令
0040105C mov eax,dword ptr [ebp-4]//將a放入EAX
0040105F sub eax,dword ptr [ebp-8]//a-b的差放入EAX
00401062 test eax,eax//比較EAX是否為0
00401064 jle main+4Dh (0040106d)//條件跳轉
19: {
20: return 2;
00401066 mov eax,2
0040106B jmp main+4Fh (0040106f)
21: }
所以我認為if (a > b) {....}
效率更高

㈧ 誰有c語言的好的編譯器，要性能夠多夠好，中文版的，有的請發到郵箱[email protected]謝謝了！！

1. GCC
大名鼎鼎的GNU的C/C++/Obj-C編譯器, 當前版本是2.8.1, 但據說與2.7.*有兼容性
問題. 而使用較廣的是gcc 2.7.2系列, 如RedHat5中帶的就是gcc 2.7.2.3
有時候在Cyrix上用gcc會有些問題, 因此有一套針對Cyrix特點的gcc 2.7.2.3
我這里有RedHat5的rpms ftp://166.111.68.98/pub/Warez-CD/Huricane-contrib
(Cyrix 2.7.2.3 & 2.8.1)

其基本結構就是一個front end和back end,
/usr/bin/gcc 就是個front end, 其kernel東西都放在 /usr/lib/gcc-lib下面,
cpp是C預處理器, cc1*的1M多的就是編譯器的核心模塊了
cc1 C compiler
cc1plus C++ compiler
cc1obj Object-C compiler
但gcc並沒有集成Fortran的compiler, 一般要用f2c轉成C後才用gcc編譯
好象也還有個g77 Fortran compiler吧?

gcc的不斷發展完善使許多commercial compiler都相形見絀, 那當然, gcc/emacs
都由GNU創始人Richard Stallman手創, 是GNU的旗艦產品, 質量當然沒得說了:-)
由於 Unix平台的高度可移植性, gcc幾乎在各種常見的Unix平台上都有, 即使是
Win32/DOS也有gcc的port. 比如說該死的Solaris普通版本連compiler都沒有, 也
就只好用gcc了...

2. EGCS(Experimental/Enhanced GNU Compiler System)
這是gcc的發展方向, 把fortran等編譯器集成進來, 也許還會有Pascal?
它的構造很清晰, 把對gcc的各種改進/port都集成回去. 如gcc 2.7系列據說是
沒有對Pentium進行優化的, 而egcs則把pgcc對Pentium的一些優化集成進去了
現在gcc的開發工作主要就是egcs, 由Cygnus公司領導(?), 這Cygnus公司還是很
不錯的, 還出了GNU-Win32, SourceNavigator等, 是GNU的堅實擁護者:-))

包括了C/C++/Obj-C/Fortran 編譯器, 當前最新版本1.0.2, 還在不斷開發中
昨天download發現KDE Beta4都用egcs編譯了 :-)

Fortran集成進來後在/usr/lib/gcc-lib下又多了個f771的back end, 當然
還是g77/f77 編譯
我這里有egcs 1.0.2 的rpm 在RH5-CD/collect下面

3. PGCC(Pentium GCC)

針對Pentium CPU進行了編譯器優化的compiler
pgcc據說用JPEG壓縮解壓縮測試最快可比gcc快 30%!
新版的pgcc都是基於egcs的, 以一個patch的形式release