我對屋頂線模型有一些關于如何處理記憶體系結點的問題。
問題：
1）如果從I0.BW=Peak得到的I0是1.21，而實際的I1是0.71，是否意味著實際的I1在記憶體中？
2）如果 I1 受記憶體限制，我們如何優化代碼以獲得更好的性能值？
3）資料移動較少或快取中加載的資料較多？
4）如果I1=0.72的紅點的性能值低于記憶體界限或遠離記憶體界限，我們如何優化代碼以獲得更好的性能？
5）如果紅色的點位于記憶體系結區域，是否意味著記憶體沒有被充分利用？但是如何優化代碼以獲得更好的性能呢？
uj5u.com熱心網友回復：
如果從 I0.BW=Peak 得到的 I0 是 1.21，而實際的 I1 是 0.71，是否意味著實際的 I1 位于記憶體系結中？
I0 是計算既使記憶體飽和又使 CPU 飽和的點。這在實踐中是非常不尋常的，因為飽和兩者中的一個通常會減慢另一個速度。對于記憶體來說尤其如此：讀取往往會導致停頓，阻止 CPU 執行算術運算，因此與峰值 FLOPS 相比會降低 FLOPS。
I1 是計算確實受記憶體限制的點。
總的來說，黃線之前的左邊部分是記憶體系結的。
如果 I1 受記憶體限制，我們如何優化代碼以獲得更好的性能值？
在這種情況下，您應該執行與記憶體相關的優化。首先要檢查/優化的是記憶體訪問模式：您應該盡可能連續地讀取資料。然后，您應該避免讀取/寫入許多龐大的資料集并即時和就地計算資料。在實踐中，這意味著合并不同演算法的回圈，這樣就不會讀取之前寫入的資料。當多個演算法之間的訪問模式不同時，平鋪可以提供幫助。
更少的資料移動或更多的資料加載到快取中？
是的，減少資料移動肯定會有所幫助。在這種情況下，訪問模式無疑是最大的問題。如果可能的話，在快取中保存資料也會有所幫助（尤其是當記憶體不是連續讀取/寫入并且不能用于目標演算法時）。有時，值得使用計算量更大的演算法，該演算法在記憶體中的性能明顯更好（例如，更好的訪問模式），因為記憶體很慢，并且 CPU 速度和記憶體速度之間的差距不會很快縮小（相當恰恰相反，這就是所謂的“記憶墻”）。
如果 I1=0.72 的紅點的性能值低于 memory bound 或遠離 memory bound ，我們如何優化代碼以獲得更好的性能？
有不同級別的記憶體系結代碼。例如，一個代碼可以受一個 NUMA 節點的 RAM 速度限制。它可以受所有 NUMA 節點的 RAM 速度的限制。它可以由 L3 快取（通常比主 RAM 快得多）系結。它也可以被L2快取系結。很難說它在實踐中是哪一個。屋頂線模型的一個問題是，一個點僅來自兩個指標，這些指標是從給定代碼中獲得的平均值。在實踐中，代碼可以拆分為計算部分進行 RAM 系結操作和算術系結操作。結果將被平均，結果將難以解釋。需要更多資訊才能了解正在發生的事情。性能計數器可以為此提供幫助。
總的來說，我建議您更深入地分析正在發生的事情并主要應用與記憶體相關的優化（見上文），以便移動圖表右側的紅點。然后，稍后，您可以優化計算以便將點向上移動。
如果紅色的點位于記憶體邊界區域，是否意味著記憶體沒有被充分利用？
基本上，是的，但“記憶”的含義在這里定義得不夠好（見上文）。這就是為什么需要進行更深入的分析的原因。我建議您測量 L3 吞吐量和 RAM 之一。如果您在 NUMA 平臺上運行代碼，那么我建議您首先僅在 1 個 NUMA 節點上運行代碼，以便了解在更簡單的情況下發生了什么。如果代碼僅在多個 NUMA 節點上表現不佳，那么您可以知道您需要執行與 NUMA 相關的優化（例如，注意分配策略和首次接觸）。
總體而言，~1 的 FLOPS/位元組很小。即使在大多數平臺上 FLOPS/byte ~10，代碼通常仍受記憶體限制（15-30 通常是代碼成為計算受限的限制）。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/513599.html
標籤：表现模型车顶线