論NVIDIA下一代GPU中的ECC記憶體應用情況
論NVIDIA下一代GPU中的ECC記憶體應用情況
作者: David Kanter 關鍵字: NVIDIA GPU ECC 記憶體
GPU計算的潮流
圖形顯示之外的用於圖形計算的GPU市場正在不斷增長著,而Nvidia公司的企業戰略已經緊緊依賴於這個新興市場。具體來說,Nvidia正努力把CUDA推向高效能運算(HPC)市場——也就是把圖形處理器的強大計算能力和記憶體頻寬,直接轉化為計算效能。Nvidia的Tesla產品(為計算而不是顯示設計的GPU)已經做了一些宣傳推廣,但目前其用途還極為有限。至少部分是因為錯誤檢測和糾正(error detection and correction)機制的缺少,GPU叢集基本上還不存在。但是我們相信Nvidia的下一個產品版本將會改變這一情況。
HPC對ECC的糾錯機制的需要
特別對於HPC世界中典型的重計算負荷的機器——叢集伺服器來說,ECC已經是基本配置了。所有伺服器已經在ECC記憶體和可靠性、可用性、可維護性(RAS)方面建立了標準(例如ECC快取功能)。通常,這些RAS特性只是Itanium、PowerPC、SPARC、zArch等專用微處理器家族所特有的,而對作為產業標準的x86伺服器在這方面往往落後了一點。沒有ECC,建立可靠的叢集機簡直是不可能事情,因為在DRAM記憶體裡的軟錯誤率太高了——而這一點客戶都很清楚。
此外,工藝的改進和半導體裝置的按比例縮小趨勢導致SRAM、DRAM錯誤的出現更為普遍。增加密度,提高訊號傳輸率,降低電壓,並減少出現單個bit突然成倍增加軟錯誤(SER)風險的情況(這種情況會導致記憶體資料異常)。不幸的是,半導體的發展都是一些相同的變化——隨著時間的推移,價格越來越便宜、速度越來越快。因此他們需要像Nvidia一樣,工藝逐步發展至40奈米、28奈米甚至更高。
從歷史上看,圖形顯示世界已不被SER(soft error)所關注——即使由1bit甚至更多bit描述顏色的一個畫素不顯示了,其實也並不重要。圖形應用程式只是不需要和其他系統一樣具有相同的容錯級別,因為人的眼睛能校正許多錯誤。隨著GPU發展得更為通用,要想跟隨CPU的腳步進而提供更強大的功能,錯誤檢測和糾正機制就是實現這一願景亟待完善的一個方面。例如,GDDR5是包括所有錯誤檢測的第一代圖形記憶體介面(請注意,我們討論的是GDDR5匯流排本身,而不是DRAM)。幾乎PC機上的每一個高速信令介面都有完整的錯誤檢測和重試機制,例如 PCI-Express、QuickPath(原名CSI)、HyperTransport(HT匯流排), Fully Buffered DIMM(全快取模組技術)等。而執行速度達到3.2GT/s的GDDR4仍然沒有錯誤檢測機制。
沒有ECC和其它形式的錯誤保護機制,想要做到錯誤檢測唯一的辦法是對重要的數值重複計算兩次並比對其結果。然而這樣處理的話,效能也會減半(雖然有些演算法在處理錯誤的方面很強大)。GPU的主要賣點就是高效能,因此這是個很頭疼的問題。雙精度運算方面,GT200、GT200b只分別比Nehalem快65%和88%——而採取兩次運算方法的話(效率減半)就會比標準CPU的計算速度慢了。
ECC的成本和利潤
從工程角度來看,新增對ECC的支援是很自然的事情。ECC要求9組而不是8組DRAM,更多的針腳用來連線額外的DRAM以及記憶體控制的邏輯電路。這會顯著增加生產一個GPU的材料清單,這對價格昂貴利潤豐厚的專業級產品Tesla、Quadro來說,根本不是問題。但是它也意味著為Nvidia的GPU增加ECC支援不能提高消費級產品的成本。因為ATI在圖形顯示產品和Intel早期產品重點控制其售價和利潤。
最終把ECC加入到Tesla產品(也很可能是Quadro)會是相當有利的。因為正如以上所說的,它會使得Nvidia在HPC市場上的GPU銷售更加成功,同時也會打消部分買家的猶豫。然而把都能執行CUDA的消費級和專業級GPU市場區分開來也會使Nvidia受益。畢竟價格差異足夠讓消費者考慮放棄Tesla而選擇一塊Geforce。更重要的是,這會讓Tesla和Quadro同ATI、Intel的競爭產品區分開來,進而佔據市場優勢。
Nvidia的人可不傻,他們在HPC方面有著很強的技術實力和對市場需求的深刻認識(實際上他們甚至已經出版了GPU可靠性探討的論文)。但是進入一個新的市場不是一步就能達成的——這是個循序漸進的過程,每一代產品都基於前一個產品的成功和反饋。現在,Nvidia已經在HPC領域初步站穩了腳跟,下一步增加ECC記憶體支援將是很符合邏輯的決策,這將讓更多使用者考慮使用GPU來滿足計算的需要。可能這時候他們正在研究如何對付我們之前提到的GDDR5介面寫資料不確定性的問題呢。
ECC記憶體之外,還可以採取一些更長遠的舉措。ECC最簡單的形式就是SECDED(Single bit Error Correct and Double bit Error Detect),這很可能會在Nvidia的下一代GPU中實現。同樣,也有更先進的檢測和糾正多bit錯誤,甚至是整個DRAM壞掉情況的技術。後者可能對Nvidia公司來說更為重要,因為一個DRAM壞掉就意味著需要更換整個產品(不像伺服器那樣壞掉的記憶體很容易換掉)。記憶體系統以外,Nvidia也許正在考慮在晶片內部暫存器和SRAM中使用ECC或者同等的技術,目前這一代GPU中這些空間總共大約有3MB的大小(如果Nvidia放棄使用真正的快取,其容量將會大幅增長)。但是晶片儲存器問題比起目前亟待解決的記憶體系統可靠性問題來說,都已經算是後話了。
GPU和ECC:時間的問題
我們已經從需求、成本和效益方面列出了Nvidia對GPU增加ECC記憶體支援的必要性。很明顯這是發展的必然,Nvidia的GPU正不不斷地朝更像CPU的方向演變著,並且緊緊追隨著HPC市場的發展。現在實際上唯一的問題是,Nvidia什麼時候增加對ECC的支援——我們最好打賭這將出現在其下一代GPU產品中。
作者: David Kanter 關鍵字: NVIDIA GPU ECC 記憶體
GPU計算的潮流
圖形顯示之外的用於圖形計算的GPU市場正在不斷增長著,而Nvidia公司的企業戰略已經緊緊依賴於這個新興市場。具體來說,Nvidia正努力把CUDA推向高效能運算(HPC)市場——也就是把圖形處理器的強大計算能力和記憶體頻寬,直接轉化為計算效能。Nvidia的Tesla產品(為計算而不是顯示設計的GPU)已經做了一些宣傳推廣,但目前其用途還極為有限。至少部分是因為錯誤檢測和糾正(error detection and correction)機制的缺少,GPU叢集基本上還不存在。但是我們相信Nvidia的下一個產品版本將會改變這一情況。
HPC對ECC的糾錯機制的需要
特別對於HPC世界中典型的重計算負荷的機器——叢集伺服器來說,ECC已經是基本配置了。所有伺服器已經在ECC記憶體和可靠性、可用性、可維護性(RAS)方面建立了標準(例如ECC快取功能)。通常,這些RAS特性只是Itanium、PowerPC、SPARC、zArch等專用微處理器家族所特有的,而對作為產業標準的x86伺服器在這方面往往落後了一點。沒有ECC,建立可靠的叢集機簡直是不可能事情,因為在DRAM記憶體裡的軟錯誤率太高了——而這一點客戶都很清楚。
此外,工藝的改進和半導體裝置的按比例縮小趨勢導致SRAM、DRAM錯誤的出現更為普遍。增加密度,提高訊號傳輸率,降低電壓,並減少出現單個bit突然成倍增加軟錯誤(SER)風險的情況(這種情況會導致記憶體資料異常)。不幸的是,半導體的發展都是一些相同的變化——隨著時間的推移,價格越來越便宜、速度越來越快。因此他們需要像Nvidia一樣,工藝逐步發展至40奈米、28奈米甚至更高。
從歷史上看,圖形顯示世界已不被SER(soft error)所關注——即使由1bit甚至更多bit描述顏色的一個畫素不顯示了,其實也並不重要。圖形應用程式只是不需要和其他系統一樣具有相同的容錯級別,因為人的眼睛能校正許多錯誤。隨著GPU發展得更為通用,要想跟隨CPU的腳步進而提供更強大的功能,錯誤檢測和糾正機制就是實現這一願景亟待完善的一個方面。例如,GDDR5是包括所有錯誤檢測的第一代圖形記憶體介面(請注意,我們討論的是GDDR5匯流排本身,而不是DRAM)。幾乎PC機上的每一個高速信令介面都有完整的錯誤檢測和重試機制,例如 PCI-Express、QuickPath(原名CSI)、HyperTransport(HT匯流排), Fully Buffered DIMM(全快取模組技術)等。而執行速度達到3.2GT/s的GDDR4仍然沒有錯誤檢測機制。
沒有ECC和其它形式的錯誤保護機制,想要做到錯誤檢測唯一的辦法是對重要的數值重複計算兩次並比對其結果。然而這樣處理的話,效能也會減半(雖然有些演算法在處理錯誤的方面很強大)。GPU的主要賣點就是高效能,因此這是個很頭疼的問題。雙精度運算方面,GT200、GT200b只分別比Nehalem快65%和88%——而採取兩次運算方法的話(效率減半)就會比標準CPU的計算速度慢了。
ECC的成本和利潤
從工程角度來看,新增對ECC的支援是很自然的事情。ECC要求9組而不是8組DRAM,更多的針腳用來連線額外的DRAM以及記憶體控制的邏輯電路。這會顯著增加生產一個GPU的材料清單,這對價格昂貴利潤豐厚的專業級產品Tesla、Quadro來說,根本不是問題。但是它也意味著為Nvidia的GPU增加ECC支援不能提高消費級產品的成本。因為ATI在圖形顯示產品和Intel早期產品重點控制其售價和利潤。
最終把ECC加入到Tesla產品(也很可能是Quadro)會是相當有利的。因為正如以上所說的,它會使得Nvidia在HPC市場上的GPU銷售更加成功,同時也會打消部分買家的猶豫。然而把都能執行CUDA的消費級和專業級GPU市場區分開來也會使Nvidia受益。畢竟價格差異足夠讓消費者考慮放棄Tesla而選擇一塊Geforce。更重要的是,這會讓Tesla和Quadro同ATI、Intel的競爭產品區分開來,進而佔據市場優勢。
Nvidia的人可不傻,他們在HPC方面有著很強的技術實力和對市場需求的深刻認識(實際上他們甚至已經出版了GPU可靠性探討的論文)。但是進入一個新的市場不是一步就能達成的——這是個循序漸進的過程,每一代產品都基於前一個產品的成功和反饋。現在,Nvidia已經在HPC領域初步站穩了腳跟,下一步增加ECC記憶體支援將是很符合邏輯的決策,這將讓更多使用者考慮使用GPU來滿足計算的需要。可能這時候他們正在研究如何對付我們之前提到的GDDR5介面寫資料不確定性的問題呢。
ECC記憶體之外,還可以採取一些更長遠的舉措。ECC最簡單的形式就是SECDED(Single bit Error Correct and Double bit Error Detect),這很可能會在Nvidia的下一代GPU中實現。同樣,也有更先進的檢測和糾正多bit錯誤,甚至是整個DRAM壞掉情況的技術。後者可能對Nvidia公司來說更為重要,因為一個DRAM壞掉就意味著需要更換整個產品(不像伺服器那樣壞掉的記憶體很容易換掉)。記憶體系統以外,Nvidia也許正在考慮在晶片內部暫存器和SRAM中使用ECC或者同等的技術,目前這一代GPU中這些空間總共大約有3MB的大小(如果Nvidia放棄使用真正的快取,其容量將會大幅增長)。但是晶片儲存器問題比起目前亟待解決的記憶體系統可靠性問題來說,都已經算是後話了。
GPU和ECC:時間的問題
我們已經從需求、成本和效益方面列出了Nvidia對GPU增加ECC記憶體支援的必要性。很明顯這是發展的必然,Nvidia的GPU正不不斷地朝更像CPU的方向演變著,並且緊緊追隨著HPC市場的發展。現在實際上唯一的問題是,Nvidia什麼時候增加對ECC的支援——我們最好打賭這將出現在其下一代GPU產品中。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/22785983/viewspace-664367/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 如何觀察程式的記憶體佔用情況記憶體
- 如何檢查 Android 應用的記憶體使用情況Android記憶體
- SOLARISE檢視記憶體使用情況記憶體
- 檢查 Linux 中記憶體使用情況的 8 條命令Linux記憶體
- Mongodb記憶體管理和使用情況情況查詢MongoDB記憶體
- 透過CPU記憶體佔用情況,找出Oracle的session對應的program記憶體OracleSession
- 檢視LINUX程式記憶體佔用情況Linux記憶體
- 使用 vmstat 命令確定記憶體使用情況記憶體
- linux下檢視記憶體使用情況Linux記憶體
- 使用 top 命令瞭解 Fedora 的記憶體使用情況記憶體
- Redis 記憶體突增時,如何定量分析其記憶體使用情況Redis記憶體
- Linux效能優化:記憶體使用情況分析Linux優化記憶體
- Linux檢視CPU和記憶體使用情況Linux記憶體
- Linux 檢視記憶體使用情況的幾種方法Linux記憶體
- 在Linux中,如何檢查系統的CPU和記憶體使用情況?Linux記憶體
- 使用show engine innodb status 檢視記憶體使用情況記憶體
- obukhov/redis-inventory: 分析redis記憶體使用情況的CLI工具Redis記憶體
- Linux檢視伺服器記憶體使用情況的命令Linux伺服器記憶體
- Android最佳效能實踐(2):分析記憶體的使用情況Android記憶體
- 用 Bash 指令碼監控 Linux 上的記憶體使用情況指令碼Linux記憶體
- 檢測Linux記憶體使用情況的free命令的10個例子Linux記憶體
- java程式碼實現檢視Tomcat記憶體使用情況JavaTomcat記憶體
- Linux檢視磁碟目錄記憶體空間使用情況Linux記憶體
- PowerShell 指令碼來監控 CPU、記憶體和磁碟使用情況:指令碼記憶體
- 總結Linux下檢視記憶體使用情況的多種方法Linux記憶體
- Linux系統下分析記憶體使用情況的管理工具Linux記憶體
- 如何使用 Bash 指令碼從 SAR 報告中獲取 CPU 和記憶體使用情況指令碼記憶體
- JRockit jstat 檢視系統記憶體資源使用情況JS記憶體
- linux 檢視某個程序和服務記憶體佔用情況命令Linux記憶體
- Linux技術——linux下檢視記憶體和CPU的使用情況Linux記憶體
- 轉:Linux檢視GPU資訊和使用情況LinuxGPU
- 監控 Python 記憶體使用情況和程式碼執行時間!Python記憶體
- 檢視 Linux 系統中程式和使用者的記憶體使用情況Linux記憶體
- Linux如何通過命令檢視伺服器的記憶體條使用情況Linux伺服器記憶體
- 監控 cpu 記憶體 網路卡的使用情況的一個命令 比較實用記憶體
- 檢視主機的記憶體使用情 (轉)記憶體
- 05記憶體情況記憶體
- Java應用程式中的記憶體洩漏及記憶體管理Java記憶體