首先來檢視記憶體存取速度如何受高低頻記憶體、單雙通道走法的影響
測試組別
- 單通道／4800
- 單通道／5600
- 雙通道／4800
- 雙通道／5600
測試環境
- 電腦硬體硬體，如下圖所示，其中記憶體為支援XMP的兩支8G的DDR 5，且主機板支援雙通道，所以可配置成是否要走雙通道，也可決定頻率高低
- 在BIOS已經把Hyper-Threading關閉
- 作業系統為Windows 11專業版（版本21H2）
- 記憶體測速軟體為『MaxxMem2』
記憶體測速結果
（如下圖所示）
垂直軸為頻率差異，水平軸為通道差異，很明顯可以觀察到以下幾點
- 雙通道記憶體的整體存取速度相較於單通道有很顯著的提升（由30幾G提高到40幾G）
- 雙通道記憶體存取速度的提升主要是在寫入的部分（由30幾G提高到50幾G）；但讀出的部分卻沒有顯著變化（都是30幾G）
- 若走雙通道，當記憶體的頻率提高時，整體存取速度無顯著變化
- 若走單通道，當記憶體的頻率提高時，寫入與讀出的速度都獲得一定程度的提升（寫入由30G提高到34G；讀出由35G提高到38G）
結論是，走雙通道可大幅提升記憶體的寫入速度；而走單通道時，若頻率提高，記憶體的寫入與讀出的速度都可得到相對的助益
接著我們來檢視MC執行最佳化（或WFO）所需的時間在這四組的差異
MC測試條件
- 軟硬體環境延續前面的條件
- MultiCharts64 Version 14.0 Release (Build 21978)
- 測試方式採用Exhaustive（暴力法）最佳化，不能使用Genetic（基因演算法）來測試，因為基因演算法的過程是隨機的，所以每次執行過程中的交易次數都不會一樣，所以每次執行的計算量也都不相同，無法取得一致性的量測數據，不過此實驗結果也適用於基因演算法最佳化、WFO
- 每一測試組都同時批次跑5個Exhaustive最佳化
- Windows 11的額外設定採此篇的模式『Windows 11下執行批次MC最佳化或WFO必須額外設定』
- 至於批次Exhaustive最佳化結束的時間點的判斷依據，則是觀察工作管理員這5個MultiCharts64處理程序的CPU降到幾乎為零的時候（肉眼誤差範圍兩秒內）
- 歷史資料為標普期貨（ES）12年的1分K棒資料，2007年到2018年，只取日盤（美中時間08:30~15:00）
- 純12年歷史資料的記憶體約為216 MB（誤差值3天資料），測量方式使用工作管理員查看MultiCharts64處理程序的記憶體狀況，計算方式如下
- 重開MC，記錄（空MC記憶體）
- 重開MC，記錄（載入12年資料的Workspace的記憶體）
- 重開MC，記錄（載入3天資料的Workspace的記憶體）
- （12年資料含Workspace與其他資訊的記憶體）＝（載入12年資料的Workspace的記憶體）－（空MC記憶體）
- （3天資料含Workspace與其他資訊的記憶體）＝（載入3天資料的Workspace的記憶體）－（空MC記憶體）
- （純12年歷史資料的記憶體）＝（12年資料含Workspace與其他資訊的記憶體）－（3天資料含Workspace與其他資訊的記憶體）
- CPU快取記憶體：L2 = 14 MB、L3 = 30 MB
MC測試結果
- 單通道／4800：總共花費12分15秒（肉眼觀察誤差0.2%）
- 單通道／5600：總共花費12分15秒（肉眼觀察誤差0.2%）
- 雙通道／4800：總共花費12分15秒（肉眼觀察誤差0.2%）
- 雙通道／5600：總共花費12分15秒（肉眼觀察誤差0.2%）
以這四組執行MC最佳化，絲毫不受記憶體頻率、通道走法的影響，至於為什麼，估計是以下原因
- 最佳化最主要的資料是歷史資料，雖然本實驗12年歷史資料的記憶體高達216 MB，但最佳化過程存取歷史資料都是以循序存取，而非隨機存取，這點可以讓CPU的快取更容易發揮功效
- 雖然批次最佳化的總執行緒為16 x 5 = 80條（因為已在BIOS關閉Hyper-Threading，所以邏輯處理核心總數為16，而非24），而實體處理器核心數只有16個，雖然僧多粥少，但本實驗使用的是高階處理器，快取容量高達44 MB（L2 + L3），尚能容納這些負載，不至於因為負載過高而太頻繁的讀取記憶體
結論是，如果滿足以下條件，其實不用太在意記憶體的速度（頻率、通道）
- 使用高階的CPU（本實驗為i9-12900），其快取充足（本實驗快取44 MB (L2 + L3)）
- 執行的最佳化的批次數量不至於太多（本實驗批次執行5個）
- 歷史資料不會太多年（本實驗為12年的1分K棒）
沒有留言:
張貼留言
（僅顯示與本文切題的留言）
注意：只有此網誌的成員可以留言。