Haswell處理器上的TSX問題對intel有多大影響？

01-22

Errata prompts Intel to disable TSX in Haswell, early Broadwell CPUs
不過按現在用Intel官方Demo不用TSX都比用TSX快，實際應用的就更少了吧。

看過Power8關於Transactional Memory(TM)的文檔後覺得應再更新這篇, 個人知識有限, 權作探討.

結論: 基於Hardware的TM是一種趨勢, Intel在TSX上的開發會因為bug而延緩, 而不會停止.

原因有二, 其一: 硬體設計更多的是為上層軟體服務的, HTM的出現可以很大程度上減少程序員設計TM代碼的工作量, 提升軟體效率, 這是開發者的需求. 其二: 使用原子操作/spin-lock這樣的方式編程是一種硬體資源浪費, 它會限制處理器上同時只有一個核心在工作. 而實際上, 如HTM這樣多核處理器並行訪問同一段內存空間並不意味著一定會發生"conflict". 宏觀來看, HTM是提升多核處理器硬體效率的方法.

關於題干中的bug, 題干鏈接中給的解釋基本很全面了. 複述下就是這次的Design Bug僅靠微碼升級還不夠, 會在以後的架構中修復. 由於問題爆發時, 僅發售了含有TSX功能的I7, 基於Haswell架構的Xeon伺服器還沒有大量量產, 其實Bug並不會影響到Intel的真正客戶. 這個事件最大的影響是, TSX指令集的推廣要晚上幾年. 雖然今年有C lib增加了TSX的支持, 但是具體的大規模應用可能要等到Intel Skylake架構了.

關於Bug本身並沒有詳細的描述, 應該是非公開資料, Intel也不希望用戶去復現這個Bug.

TSX實現的HTM功能其實是通過硬體達到原來只能由軟體實現的STM, 它的效率是高出使用Atomic Operation或者Lock-spin等方法的. 參見Intel論文: Performance Evaluation of Intel R Transactional ... 在結語中Intel提到TSX對於TM類Benchmark的性能提升在1.41x左右, 帶寬提升在1.31x左右. 因此這個功能是正向提升的. (關於題干中的性能下降引用我未能找到鏈接, 誰有的話請分享下)

Intel肯定會持續開發這個功能, AMD曾經有開發類似功能的計劃, 應該是被砍了. 而IBM Power8上的HTM功能甚至更強過Intel. 說到影響, 最多是針對Intel HTM, 對業界是不會有很大影響的.

-----------------------以下為技術分析, 非戰鬥人員可以點贊後離開-----------------------------------

下面是為了講清楚TSX好用在哪裡:

參考:David Kanter的文章

http://www.realworldtech.com/haswell-tm/

http://www.realworldtech.com/haswell-tm-alt/

TSX指令集的目的是為了簡化加鎖的工作量, 並且通過硬體細分鎖的粒度, 來提高多核協作的效率.

什麼是TSX(Transactional Synchronization Extensions)?

其實是從資料庫訪問借用而來的概念.

傳統的數據加鎖是一種pessimistic execution模型. 打比方說, 如果A和B都想去圖書館借書, 圖書館為了保證每本書只能借給一個人, 一次僅允許圖書館進入一個人. 這種模型下A進圖書館後, B需要等待. 直到A離開.

TSX里使用的HTM是一種optimistic execution模型. 打比方說, 如果A和B都去圖書館借書, 圖書館讓A和B都進來, 如果A和B借閱的書不同, 他們就可以都正常離開. 如果A和B不巧要借同一本書, 圖書管理員會仲裁, 並讓其中一人先暫時離開圖書館, 等另一人借書完畢後再重新進來借書.

這裡把"A"和"B"換成一個CPU中的Core0和Core1, "圖書館"換成Memory, "書"換成某一個數據塊, "圖書管理員"換成Intel TSX功能硬體, 就可以理解TSX了.

因此, TSX這種模型更加激進, 也更加效率. 當然, 前提是"conflict"(即衝突)發生率不高. 而實際上, 這個衝突的發生概率是可以容忍的, 這也是為什麼論文里說TSX對性能有正向提升.

為什麼使用TSX可以簡化程序員的加鎖的工作量?

加鎖本身並不複雜, 找Lib里拿一個庫函數就可以了.

麻煩的是程序員為了提升伺服器效率, 需要不斷的優化代碼, 減小鎖的範圍, 削弱鎖的影響. 但是這樣的優化往往伴隨著風險的提升. 因為優化的對象是多核交互的內存段, 很多程序員寫順序的代碼都出錯, 何況是去優化TM代碼?

但是使用了TSX就不一樣了, 程序員只用指定加鎖的範圍, 硬體自動幫程序員實現效率最大化. 程序員不用再考慮優化加鎖的事, 節省了大量的工作! 下面有個例子.(引自是論文代碼 Performance Evaluation of Intel R Transactional ... 另請注意Intel的TSX有兩種模式, RTM和HLE. 下文為RTM代碼):

acquire_lock (mutex); // execute critical section


Retry:

xbegin Abort

cmp mutex, 0

jz Success
xabort $0xff
Abort:

sub retryCnt, 1

cmp retryCnt, 0

jz acquire_lock

jmp Retry

release_lock (mutex); cmp mutex, 0 jnz release_lock xend

翻譯下:

代碼中xbegin啟動HTM, xend結束HTM. 二者中間的代碼是加鎖的. 但是這個鎖不影響"其他訪問相同數據段的Core"的工作, 即加鎖後, 處理器仍是多核並行!

但是萬一併行時出錯怎麼辦? 這時TSX會把當前這個Core的狀態複位到執行xbegin之前, 並進入錯誤修復代碼(即Abort段代碼).

可以看到, 程序員僅需要指定從xbegin到xend這樣一個範圍就可以使其中的所有代碼都加鎖, 達到細粒度加鎖的效果.

上文加粗的兩句話都是需要硬體支持的, 所幸現代處理器支持這些功能並不需要改動太多. 目前Intel僅是稍微改動了Cache的結構, 使得處理器可以像Symantec的Ghost備份軟體一樣, 備份某一個時刻的Core狀態/數據, 進而實現TSX管理.

因此, TSX的發展不會受到這次事故的影響, 畢竟它很好用. Intel在Haswell上也僅是進行了很基礎的基於Cache的HTM, 隨著Intel在流水線里加入更多TSX專用硬體, 這個功能會更加完善.

對支持Transaction的那一派人算是一個挫折吧。

已經直接/間接聽到至少兩位大佬表示對Transaction memory不看好了。