是什么讓Apple的PowerPC memcpy如此之快？

Question

為了在PowerPC上尋找一個好的內存策略，我寫了幾個復制函數。 使用具有高速緩存提示（dcb *）的Altivec或fp寄存器可以在大數據的簡單字節復制循環中使性能提高一倍。 最初很滿意的是，我定期記憶，看看它的比較...比我最好的速度快10倍！ 我無意重寫memcpy，但我希望從中學習並加速幾個簡單的圖像過濾器，這些過濾器花費大部分時間將像素移入和移出內存。

Shark分析顯示它們的內部循環使用dcbt預取，有4個向量讀取，然后是4個向量寫入。 在調整了我的最佳函數以便每次迭代運行64個字節之后，memcpy的性能優勢仍然令人尷尬。 我正在使用dcbz釋放帶寬，Apple沒有使用任何東西，但這兩個代碼都傾向於對商店猶豫不決。

prefetch
  dcbt future
  dcbt distant future
load stuff
  lvx image
  lvx image + 16
  lvx image + 32
  lvx image + 48
  image += 64
prepare to store
  dcbz filtered
  dcbz filtered + 32
store stuff
  stvxl filtered
  stvxl filtered + 16
  stvxl filtered + 32
  stvxl filtered + 48
  filtered += 64
repeat

有沒有人對為什么非常相似的代碼有如此戲劇性的性能差距有一些想法？ 我喜歡用真正的圖像過濾器來腌制真正的圖像過濾器！

附加信息：所有數據都是矢量對齊的。 我正在制作圖像的過濾副本，而不是替換原始圖像。 該代碼在PowerPC G4，G5和Cell PPU上運行。 Cell SPU版本已經非常快。

Answer 1

Shark分析顯示它們的內部循環使用dcbt預取，有4個向量讀取，然后是4個向量寫入。 調整我的最佳函數后，每次迭代也會運行64個字節

我可能會說明顯而已，但由於你在問題中根本沒有提到以下內容，因此可能值得指出：

我敢打賭，Apple選擇的4個向量讀取后跟4個向量寫入與G5的流水線和它在“調度組”中的無序指令執行的管理有很大關系，因為它具有神奇的64字節完美線條大小。 您是否注意到Nick Bastin的鏈接bcopy.s中的線路跳過？ 這意味着開發人員考慮了G5如何使用指令流。 如果你想重現相同的性能，一次讀取64字節數據是不夠的，你必須確保你的指令組已經充分填充（基本上，我記得指令最多可以分為五個獨立的指令組，前四個是非跳轉指令，第五個只允許跳轉。細節更復雜）。

編輯：您可能也會對同一頁面上的以下段落感興趣：

根據G4和G3，dcbz指令仍然對齊32位字節的存儲器段。 但是，由於這不是G5上的完整緩存行，因此它不具備您可能希望的性能優勢。 有一個為G5新引入的dcbzl指令，它將一個完整的128字節高速緩存行歸零。

Answer 2

我不確切知道你在做什么，因為我看不到你的代碼，但Apple的秘訣就在這里 。

Answer 3

也許是因為CPU緩存。 嘗試運行CacheGrind ：

Cachegrind是一個緩存分析器。 它可以對CPU中的I1，D1和L2緩存進行詳細模擬，因此可以准確地找出代碼中緩存未命中的來源。 它通過每個功能，每個模塊和整個程序摘要識別緩存未命中數，內存引用和為每行源代碼執行的指令。 它適用於使用任何語言編寫的程序。 Cachegrind運行程序比正常情況慢大約20-100倍。

Answer 4

仍然沒有答案，但你確認memcpy實際上是在移動數據嗎？ 也許它只是重新映射寫入。 你仍然可以看到Shark中的內部memcpy循環作為第一頁和最后一頁的一部分被真正復制。

Answer 5

正如另一個答案中所提到的，Apple在G5上定義的“dcbz”僅在32字節上運行，因此在具有128字節高速緩存行的G5上使用該指令會失去性能。 您需要使用“dcbzl”來防止從內存中獲取目標高速緩存行（並有效地將有用的讀取內存帶寬減少一半）。