關於使用__builtin_expect的指導原則

我應該怎樣使用gcc的__builtin_expected宏對if進行多重和嵌套測試？我有這樣的代碼：關於使用__builtin_expect的指導原則

if((x<RADIUS && (forward?v<0:v>0)) || (x+RADIUS>dimensions[d] && (forward?v>0:v<0)))

我已經（可笑）裹盡我所能：

#define likely(x)  __builtin_expect((x),1) 
#define unlikely(x)  __builtin_expect((x),0) 
if(unlikely(unlikely(unlikely(x<RADIUS) && likely(likely(forward)?likely(v<0):likely(v>0))) || unlikely(unlikely(x+RADIUS>dimensions[d]) && likely(likely(forward)?likely(v>0):likely(v<0)))))

我希望它只是一個矯枉過正，因爲這幾乎是不可讀。

來源

2012-05-25 Lorenzo Pistone

你打算在哪裏運行這段代碼？在現代x86 CPU上的實踐中，分支預測器無論如何都比靜態提示要好得多，也就是說，如果你足夠頻繁地運行代碼並且有一個簡單的模式，他們就會輕鬆地將其提取出來。如果你不*經常運行代碼，爲什麼你認爲幾個週期會很重要？現在，如果你的目標平臺之一是ARM，那麼這可能不是一個壞主意。 – Voo

我不認爲這裏有錯誤的答案。編譯器將使用你的提示來決定哪種情況下每次比較都會產生「其他」情況;這不僅僅是其他的C代碼，而且在邏輯的和和或之內，並且越多的信息越好。

爲了可讀代碼的緣故，我建議把它保留在一個大的東西上：每個if語句一次，但這不是基於任何確鑿的證據。

您是否考慮過使用-fprofile-generate，使用典型數據運行代碼，然後使用-fprofile-use重建？這樣編譯器就可以爲所有這些情況構建自己的圖片。這是更便攜的（沒有特定於編譯器的註釋），更具可讀性，以及更多的未來證明。

來源

2012-05-25 13:57:13 ams

關於使用__builtin_expect的指導原則

回答

相關問題