為什么我的記憶基准會給出奇怪的結果？

Question

我最近運行了一些用C＃編寫的基本基准測試，試圖確定一些看似相同的HyperV遠程工作站運行速度遠遠低於其他工作站的原因。 他們在我運行的大多數基本測試中的結果完全相同，但基本內存訪問基准測試的結果（具體地說，將二維1000x1000雙精度數組初始化為0的時間）相差40倍。

為了進一步研究這個問題，我已經進行了其他幾個實驗來進一步縮小問題的范圍。 以指數級增加的數組大小運行相同的測試（直到發生OutOfMemoryException）顯示各種遙控器之間沒有差異，直到數組大小超過1米，然后立即差異大約為40。實際上，測試增量數組大小，初始化時間與數組大小成比例增加，直到陣列大小正好為999999，然后在低速遙控器上，所用時間增加了900％，而在“快速”遙控器上，隨着陣列大小的增加，它減少了70％ 1000×1000。 從那里，它繼續按比例擴大。 陣列尺寸為1m x 1和1 x 1m時也會出現同樣的現象，但程度要小得多（相反，變化為+ 50％和-30％）。

有趣的是，將用於實驗的數據類型更改為浮點似乎可以完全消除這種現象。 在任何測試中，遙控器之間沒有差異，並且即使在1000 * 1000和2000 * 2000斷點上，所花費的時間似乎完全成比例。 另一個有趣的因素是我使用的本地工作站的行為似乎反映了較慢的遙控器。

是否有人知道系統配置中的哪些設置可能導致此影響以及如何更改，或者可以采取哪些措施來進一步調試問題？

Answer 1

你必須記住你真正在測試的是什么 。 這當然不是.NET程序分配數組元素的能力。 這是非常快的，通常進行的是一個大陣列的內存總線頻段，通常約為37千兆字節/秒，具體取決於機器的RAM類型，5 GB /秒是您今天可能遇到的最強類型（慢速時鍾DDR2開啟）一台舊機器）。

new關鍵字僅在需求分頁的虛擬內存操作系統（如Windows）上分配地址空間 。 只是處理器的數字，每4096字節一個。

一旦您第一次開始分配元素，需求分頁功能就會啟動，您的代碼會強制操作系統為陣列分配RAM。 數組元素分配觸發頁面錯誤，數組中每個4096字節一個錯誤。 或者你的陣列有512個雙打。 處理頁面錯誤的成本包含在您的測量中。

只有當OS具有准備好使用的零初始化RAM頁面時，才能順利進行。 通常需要脂肪半微秒，給予或采取。 處理器仍有很多時間，當操作系統更新頁面映射時，它將停滯不前。 請記住，這只發生在第一個元素訪問，后續的快速，因為RAM頁面仍然可用。 通常。

當這樣的RAM頁面不可用時，這並不是一帆風順的。 然后操作系統必須掠奪一個。 在您的案例中，我可以想到多達4個不同的場景：

• 頁面可用但尚未由低優先級零頁面線程零初始化。 應該快，不需要太多努力。
• 需要從另一個進程中竊取頁面，並且不需要保留該頁面的內容。 發生以前包含代碼的頁面。 很快也很快。
• 頁面需要被盜，其內容需要保存在頁面文件中。 例如，發生以前包含數據的頁面。 一個硬頁錯誤，一個人傷害。 磁盤寫入發生時，處理器將停止運行。
• 特定於您的方案，HyperV管理器決定是時候從主機操作系統借用更多RAM。 所有以前的項目符號都適用於該操作系統，以及操作系統交互的開銷。 不知道需要多少開銷，也應該是痛苦的。

你打算擊中哪一顆子彈是非常非常難以預測的。 最重要的是因為它不僅僅涉及您的程序，而且機器上運行的任何其他程序也會影響它。 並且存在記憶效應，比如在開始測試之前編寫大文件會產生極大的副作用，這是由等待磁盤的文件系統緩存使用的RAM頁面引起的。 或者另一個具有分配突發並耗盡零頁面隊列的進程。 或者內存總線變得飽和，很容易做到，也可能受到主機操作系統的影響。 等等。

它的長短是對這段代碼進行分析並不是很有意義。 任何可以而且將要發生的事情，你沒有一個體面的方式來預測它。 或者對它做任何事情的好方法，除了給VM提供RAM並且不運行任何其他東西:) 第二次通過數組的分析結果將更加穩定和有意義，操作系統現在不再涉及了。