英特爾(R) 調優助手主題64K 重疊

因為快取中已經存在數據，並且該數據的線性地址的位 0-15 的值與要放入一級快取的數據的相同，所以無法放入數據。對於啟用“超執行緒技術”（HT 技術）的系統，比較“關閉超執行緒技術”的單處理器系統與“打開超執行緒技術”的單處理器系統時，可能會發現 64K 重疊事件數明顯增加。到目前為止的研究表明，如果增量在 2-4 倍範圍內，糾正這些情況並不能取得有意義的速度提升效果。不過，對於 64K 重疊事件的增量在 5 倍以上的那些情況，糾正它們則能夠取得有意義的速度提升。打開“超執行緒技術”時，有兩種情況可能會導致 64K 重疊顯著增加：

  • 情況 1：操作系統建立對齊 1 或 2 MB 邊界（可模除 64K）的執行緒堆疊空間。因此，一個執行緒的堆疊數據位於一級快取，且第二個執行緒訪問其堆疊數據時，如果處理器試圖將第二個執行緒的數據放入一級快取，則它將遇到 64K 重疊事件。建議：採用以下建議消除或減少 64K 重疊的影響。
  • 情況 2：有時也可能是每個執行緒訪問的數據結構恰好相距 64K。每當兩個執行緒訪問相距 64K 的數據結構時，處理器都將招致 64K 重疊懲罰。建議：採用以下建議消除或減少 64K 重疊的影響。

    對於未打開“超執行緒技術”的系統，以下兩種情況產生的效能影響可能會有非常大的差別：

  • 情況 1：64K 重疊主要由載入組成的程式碼所導致。載入可能會同其它載入爭用載入請求緩衝區。如果大多數 64K 重疊事件都是由幾乎全是載入（相對於載入與儲存交叉的情況）的程式碼所導致，則這種情況的效能影響微乎其微。建議：繼續研究其它效能問題。
  • 情況 2：64K 重疊由載入與儲存混合成的程式碼所導致。需要請求緩衝區的載入可能會在儲存之後停止不前。儲存必須失效並釋放快取，載入才能繼續。如果大多數 64K 重疊事件都是由載入與儲存交叉的程式碼所導致的，則這種情況下的效能影響非常顯著。建議：採用以下建議消除或減少 64K 重疊的影響。請注意，使用 Microsoft* 或英特爾(R) 的最新編譯器可能有助於降低或消除這些型別的事件。
    對於採用“超執行緒技術”的系統或多處理器系統，估計的影響代表總計處理器時間影響（系統上所有邏輯/物理處理器之和），而不是“實際執行”時間影響。因此，在採用“超執行緒技術”的系統或多處理器系統上，很可能會看到細節的時間影響大於對負載實際執行時間的影響。請注意，在單處理器系統上，處理器時間與實際執行時間相同。
    英特爾(R) 奔騰(R) 4 處理器能夠取得高效能的方法之一是，樂觀地假設有一種能實現更佳效能的條件。它實現這點的方法之一是預測分支的結果，並且在分支得到解析之前，憑推測沿一條路徑執行。另一種方法是無序執行某些記憶體操作。有些記憶體相關的效能監視事件同時統計推測性操作以及非推測性操作，因此產生的計數比不統計推測性操作時的更大。無序執行記憶體操作會導致更多的推測性操作（計為事件），這可能會導致計數比未發生此推測時獲得的計數值更大。例如，處理器可能會嘗試憑推測無序執行載入。假設一級快取中已經存在使用相同線性地址位 0-15 的數據。此外，假設由於程式碼正在進行指針跟蹤，且處理器還沒有獲得正確的地址，因此處理器的載入地址還是錯誤的。如果載入導致 64K 重疊事件，則 64K 重疊事件會遞增。由於推測的緣故，如果沒有推測，則不會發生 64K 重疊事件。從體系結構的角度看，這是統計過量情況：即使在沒有推測時指令不會遇到 64KB 重疊，但由於推測活動，指令也會報告說遇到 64KB 重疊衝突。事實上，它是微體系結構級發生的事件的精確表示：此指令確實導致了 64K 重疊衝突。
     
    計數器相關性：

    此細節與以下效能計數器函式相關：

    Aliasing64K 效能影響 = ((64k 重疊衝突*12)/時鐘訊號)*100
    較低值：    0.2
    較高值：    2

    在“Aliasing64K 效能影響”較高時，此細節具有實質性意義。

    建議：