準備寫一個系列，駁斥一下這些年我整理/設計的高性能編碼規范里，哪些是沒有意義的。為什么會沒有意義呢？有的原因可能是規則本身是有問題的，有的原因可能是編譯器會幫我們優化，有的可能存在局限性，還有可能有些其他原因。

第一個規則：

如果循環體內存在邏輯判斷，宜將邏輯判斷移到循環體的外面。

這是部門社招主觀題的一個考點，也是一本老書《大話處理器》里關于代碼優化的章節開頭的例子。形如下述代碼：

for(i = 0; i < N; i++) {if(A)DoSomething();elseDoOthers(); }

一般認為是低效的，因為循環內做了條件判斷，推薦代碼形如：

if(A) {for(i = 0; i < N; i++)DoSomething(); } else {for(i = 0; i < N; i++)DoOthers(); }

理論分析下：

1.如果A是常量/宏，編譯器應能優化掉另一個分支；

2.如果A是變量，處理器應有分支預測功能，特別是現在一些強大的芯片，用于預測的空間應該是很大的。也就是說，對于變化較少的變量，依賴芯片的分支預測功能，這個規則是沒有意義的。

3.如果A是經常變化的變量，處理器應不會進行預測，在這個場景下，這個規則應該是有意義的。

4.再從設計上分析下，方式二有循環語句重復，應該是要盡量避免的。

針對1，設計代碼如下:

低效代碼low.c：

#include <stdio.h> #include <time.h> int a = 1; int sum = 0; #define N 1000000 int main() {clock_t start, end;start = clock();for(int i = 0; i < N; i++){if(a)sum += i;elsesum = sum + 2 * i ;}end = clock();printf("%ld", end - start); }

高效代碼high.c：

#include <stdio.h> #include <time.h> int a = 1; int sum = 0; #define N 1000000 int main() {clock_t start, end;start = clock();if(a)for(int i = 0; i < N; i++)sum += i;elsefor(int i = 0; i < N; i++)sum = sum + 2 * i ;end = clock();printf("%ld", end - start); }

結果如下：

從這個實驗結果里能得出的結論如下：

低效寫法在大部分情況下效率確實低；

在這個典型寫法下，10億次與100萬次循環，low和high的差距比例變化不大，均在30%左右；

a=0，即分支預測失敗時，low變化不大，high性能惡化24%，low high差距縮小為5%。

（O2與O1差不多）O1優化下，差距比例擴大為50%；

用const聲明變量a，O0下二者幾乎一樣。存疑。

O3優化二者幾乎一樣；存疑。

根據3，應有如下編碼建議：

執行概率高的分支應放在概率低的分支前面。

對于疑問5，取gcc -O0 -fverbose-asm -S low.c，查看匯編發現，相比于非const，const僅僅是把a替換成了1，能把low代碼性能提升30%！從匯編上似乎解釋不了，推測應該是流水帶來的收益。應有如下編碼建議：

對于版本確定無疑的開關，應使用const或者宏，不應使用普通變量。

對于疑問6，查看匯編發現，low代碼結構已優化成與high的基本相同，即在循環外層進行條件判斷。還是存疑，有沒有可能O3通過分析代碼，明確按照a=1的分支編譯。進一步，將a改為0，發現匯編代碼順序沒有發生變化，開銷均變為a=1的2倍。所以應有如下結論：

文章開頭提到的編碼規范在O3下沒有意義。

如果條件a與循環下標i有關系，沒法優化，不在本文討論的范圍內。

本文通過幾組實驗，說明了下面幾個有意義的結論：

文章開頭提到的編碼規范在O3下沒有意義，考慮到循環語句重復，我認為不應再堅持這個編碼規范；

執行概率高的分支應放在概率低的分支前面；

對于版本確定無疑的開關，應使用const或者宏，不應使用普通變量。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的查看分支编码_高性能编码规范驳斥（一）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。