在閱讀了我們什么時候應該使用預取？和預取示例中的示例？，我在理解何時實際使用預取方面仍有很多問題。雖然這些答案提供了預取有用的示例，但它們沒有解釋如何在實際程式中發現它。它看起來像隨機猜測。
特別是，我對可通過 GCC 的__builtin_prefetch內在函式訪問的 intel x86（prefetchnta、prefetcht2、prefetcht1、prefetcht0、prefetchw）的 C 實作感興趣。我想知道：
- 我如何才能看到軟體預取對我的特定程式有幫助？我想我可以使用 Intel Vtune 或 Linux 實用程式收集 CPU 分析指標（例如快取未命中數）
perf。在這種情況下，哪些指標（或它們之間的關系）表明有機會通過軟體預取來提高性能？ - 如何定位受快取缺失影響最大的負載？
- 如何查看發生未命中的快取級別以決定使用哪個預取（0,1,2）？
- 假設我發現一個特定的負載在特定的快取級別中未命中，我應該在哪里放置預取？例如，假設下一個回圈遭受快取未命中
for (int i = 0; i < n; i ) {
// some code
double x = a[i];
// some code
}
我應該在加載之前還是之后放置預取a[i]？它應該指向多遠a[i m]？我是否需要擔心展開回圈以確保我只在快取行邊界上預取，或者它幾乎是免費的，就像nop資料已經在快取中一樣？是否值得連續使用多個__builtin_prefetch呼叫來一次預取多個快取行？
uj5u.com熱心網友回復：
我如何才能看到軟體預取對我的特定程式有幫助？
您可以檢查快取未命中的比例。perf或 VTune 可用于獲取此資訊，這要歸功于硬體性能計數器。例如，您可以獲取串列perf list。該串列取決于目標處理器架構，但有一些通用事件。例如L1-dcache-load-misses，LLC-load-misses和LLC-store-misses。除非您還獲得了加載/存盤的數量，否則擁有快取未命中的數量并不是很有用。有通用計數器，如L1-dcache-loads,LLC-loads或LLC-stores。AFAIK，對于 L2，沒有通用計數器（至少在 Intel 處理器上），您需要使用特定的硬體計數器（例如l2_rqsts.miss在 Intel Skylake-like 處理器上）。要獲取總體統計資訊，您可以使用perf stat -e an_hardware_counter,another_one your_program. 可以找到一個很好的檔案在這里。
當未命中的比例很大時，您應該嘗試優化代碼，但這只是一個提示。事實上，對于您的應用程式，您可能會遇到很多快取命中，但在您的應用程式的關鍵部分/時間會有很多快取未命中。結果，快取未命中可能會丟失。與 SIMD 相比，標量代碼中大量的 L1 快取參考尤其如此。一種解決方案是僅對應用程式的特定部分進行概要分析，并使用它的知識來朝著好的方向進行調查。性能計數器實際上并不是自動搜索程式中問題的工具，而是幫助您驗證/反駁某些假設或提供一些提示的工具關于正在發生的事情。它為你提供了解決神秘案件的證據，但所有作業都取決于你，偵探。
如何定位受快取缺失影響最大的負載？
一些硬體性能計數器是“精確的”，意味著可以定位產生事件的指令。這非常有用，因為您可以分辨出哪些指令導致了大多數快取未命中（盡管在實踐中并不總是準確的）。您可以使用perf record perf reportso 來獲取資訊（有關更多資訊，請參閱前面的教程）。
請注意，導致快取未命中的原因有很多，只有少數情況可以通過使用軟體預取來解決。
如何查看發生未命中的快取級別以決定使用哪個預取（0,1,2）？
這在實踐中通常很難選擇，并且非常依賴于您的應用程式。從理論上講，該數字是告訴處理器是否目標快取行的區域性級別（例如，提取到 L1、L2 或 L3 快取中）的提示。例如，如果您知道資料應該很快被讀取和重用，那么將其放在 L1 中是一個好主意。但是，如果使用 L1 并且您不希望只使用一次（或很少使用）的資料污染它，則最好將資料提取到較低的快取中。在實踐中，它有點復雜，因為從一種架構到另一種架構的行為可能不同......請參閱什么是_mm_prefetch()位置提示？了解更多資訊。
這個問題的一個用法示例。軟體預取用于避免某些特定步幅的快取垃圾問題。這是硬體預取器不是很有用的病態案例。
假設我發現一個特定的負載在特定的快取級別中未命中，我應該在哪里放置預取？
這顯然是最棘手的部分。您應該足夠早地預取快取行，以便顯著減少延遲，否則指令是無用的，實際上可能是有害的。實際上，該指令在程式中占用了一些空間，需要進行解碼，并使用可用于執行其他（更關鍵的）加載指令的加載埠。但是，如果為時已晚，則快取行可能會被逐出并需要重新加載...
通常的解決方案是撰寫如下代碼：
for (int i = 0; i < n; i ) {
// some code
const size_t magic_distance_guess = 200;
__builtin_prefetch(&data[i magic_distance_guess]);
double x = a[i];
// some code
}
magic_distance_guess通常基于基準設定的值在哪里（或對目標平臺的非常深入的了解，盡管實踐通常表明即使是高技能的開發人員也無法找到最佳值）。
問題是延遲很大程度上取決于資料的來源和目標平臺。在大多數情況下，除非開發人員在唯一的給定目標平臺上作業，否則他們無法真正知道何時進行預取。這使得軟體預取使用起來很棘手，并且在目標平臺發生變化時通常是有害的（必須考慮代碼的可維護性和指令的開銷）。更不用說內置函式依賴于編譯器，預取內在函式依賴于體系結構，并且沒有標準的可移植方式來使用軟體預取。
我是否需要擔心展開回圈以確保我僅在快取行邊界上進行預取，或者如果資料已經在快取中，它將像 nop 一樣幾乎是免費的？
是的，預取指令不是免費的，因此每個高速快取行最好只使用 1 條指令（因為同一高速快取行上的其他預取指令將無用）。
是否值得連續使用多個 __builtin_prefetch 呼叫來一次預取多個快取行？
這非常依賴于目標平臺。現代主流 x86-64 處理器以無序方式并行執行指令，并且它們具有相當大的指令分析視窗。他們傾向于盡快執行加載以避免錯過，他們通常非常適合這樣的作業。
在您的示例回圈中，我希望硬體預取器應該做得很好，并且在（相對較新的）主流處理器上使用軟體預取器應該會更慢。
當硬體預取器在十年前不是很聰明時，軟體預取很有用，但現在它們往往非常好。此外，引導硬體預取器通常比使用軟體預取指令更好，因為前者的開銷較低。這就是不鼓勵軟體預取的原因（例如，英特爾和大多數開發人員），除非您真的知道自己在做什么。
uj5u.com熱心網友回復：
如何系統地使用軟體預取？
快速的回答是：不要。
正如您正確分析的那樣，預取是一種棘手且高級的優化技術，不可移植且很少有用。
您可以使用分析來確定代碼的哪些部分構成瓶頸，并使用專門的工具（例如valgrind）來嘗試識別可能使用編譯器內置函式避免的快取未命中。
不要對此抱有太多期望，但要對代碼進行概要分析，以便將優化作業集中在有用的地方。
還要記住，對于大型資料集，更好的演算法可以擊敗效率較低的演算法的優化實作。
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/476417.html