NPTL 成為 glibc "正選" 線程庫後，它的性能如何受到很多人的關注。本文就針對 NPTL 與 LinuxThreads 的性能比較，以及超線程、內核可搶占等特性對線程性能的影響進行了全面評測。
一、 前言
在 Linux 2.6.x 內核中，調度性能的改進是其中最引人注目的一部分 [1]。NPTL（Native Posix Thread Library）[2] 使用內核的新特性重寫了 Linux 的線程庫，取代歷史悠久而備受爭議的 LinuxThreads [3] 成為 glibc 的首選線程庫。
NPTL 的性能究竟如何？相對 LinuxThreads 又有哪些明顯的改進？在對 NPTL 進行全面分析之前，本文針對這兩種線程庫，以及內核中 "內核可搶占"（Preemptible）和超線程（HyperThreading）[4] 等特性進行了全面的性能評測，結果表明 NPTL 絕對值得廣大服務器系統期待和使用。
二、 Benchmark
1. 測試平台
進行本測試的硬件平台為浪潮 NF420R 服務器 [7]，4 個 Hyperthreading-enabled Intel Xeon 2.2G 處理器，4G 內存。Linux 選擇了 Slackware 9.0 發行版 [8]，所使用的內核源碼來自www.kernel.org。
2. 針對測試：LMBench
lmbench 是一個用於評價系統綜合性能的多平台開源 benchmark [5]，但其中沒有對線程的支持。其中有兩個測試進程性能的 benchmark：lat_proc 用於評測進程創建和終止的性能，lat_ctx 用於評測進程切換的開銷。lmbench 擁有良好的 benchmark 結構，只需要修改具體的 Target 程序（如 lat_proc.c 和 lat_ctx.c），就可以借用 lmbench 的計時、統計系統得到我們關心的線程庫性能的數據。
基於 lat_proc和lat_ctx 的算法，本文實現了 lat_thread和lat_thread_ctx 兩個 benchmark。在 lat_thread 中，lat_proc 被改造成使用線程，用 pthread_create() 替代了 fork()，用 pthread_join() 替代 wait()；在 lat_thread_ctx 中，沿用 lat_ctx 的評測算法（見 lat_ctx 手冊頁），將創建進程的過程改寫為創建線程，仍然使用管道進行通信和同步。
lat_thread null
null 參數表示線程不進行任何實際操作，創建後即刻返回。
lat_thread_ctx -s #threads
size 參數與 lat_ctx 定義相同，可表示線程的大小（實際編程時為分配 K 數據；#threads 參數為線程數，即參與令牌傳遞的線程總數，相當於程序負載情況。
3. 綜合測試：Volanomark
volanomark是一個純java的benchmark，專門用於測試系統調度器和線程環境的綜合性能[6]，它建立一個模擬Client/Server方式的Java聊天室，通過獲取每秒平均發送的消息數來評測宿主機綜合性能（數值越大性能越好）。Volanomark測試與Java虛擬機平台相關，本文使用Sun Java SDK 1.4.2作為測試用Java平台，Volanomark版本2.5.0.9。
三、 測試結果
測試計劃中將內核分為 2.4.26、2.6.6/ 支持內核搶占和 2.6.6/ 不支持內核搶占三類；通過配置內核以及 NF420R 的 BIOS 實現三類 SMP 規模：單處理機 (UP)、4CPU 的 SMP（SMP4）和打開超線程支持的虛擬 8CPU SMP（SMP8*）。內核配置和 SMP 規模的每一種組合都針對 LinuxThreads 和 NPTL 使用 lat_thread、lat_thread_ctx 和 volanomark 獲取一組數據。由於 NPTL 無法在 2.4.x 內核上使用，該項數據空缺。
四、 結果分析
1. LinuxThreads vs NPTL：線程創建/銷毀開銷
使用 2.6.6/preemptible 內核配置下 UP 和 SMP4 的測試數據獲得下圖：
圖 1
在線程創建/銷毀開銷方面，NPTL 的改進相當明顯（降低約 600%）。實際上，NPTL 不再像 LinuxThreads 那樣需要使用用戶級的管理線程來維護線程的創建和銷毀 [9]，因此，很容易理解它在這方面的開銷能夠大幅度降低。
同時，由圖可見，單 CPU 下創建線程總是比多 CPU 下迅速。
2. LinuxThreads vs NPTL：線程切換開銷
同樣使用 2.6.6/preemptible 內核配置下 UP 和 SMP4 的數據：
圖 2
隨著 lat_thread_ctx 的參與線程增多，不管是哪個線程庫，單處理機條件下的線程切換開銷都陡峭上升，而 SMP 條件下則上升比較平緩。在這方面，LinuxThreads 和 NPTL 表現基本相同。
3. 內核影響
圖 3
圖 4
圖 5
圖 6
從上面四張圖中我們可以得出兩點結論：
1、"內核可搶占" 是 Linux 對實時應用提供更好支持的有力保障，但對線程性能影響很小，甚至有一點損失，畢竟搶占鎖的開銷不可忽略；
2、升級內核並不會對 LinuxThreads 線程庫性能帶來多少變化，因此，對於服務器系統而言，不能指望僅僅編譯使用新內核就能提高性能。
圖 7
圖 8
從圖 3、圖 4 我們已經知道，打開超線程支持對線程創建/銷毀性能幾乎沒有影響，而這兩張圖表也進一步說明，超線程技術對於線程切換開銷也沒有明顯的影響。超線程技術是 CPU 內部的優化技術，和真正的雙 CPU 完全不同。大量研究表明，如果沒有內核與用戶應用相結合的專門優化措施，超線程並不會帶來很大的性能變化。除非是高負載綜合服務器系統（例如繁忙的數據庫系統），購買超線支持的 CPU 並不能帶來多少好處。
4. 綜合性能
圖 9
前面幾節分析讓我們了解了線程庫性能改進的細節，通過 volanomark 測試，我們可以近似得到在綜合應用環境下，特別是網絡服務需求中線程庫以及內核對系統整體性能的影響程度。
圖 9 綜合了不同內核、不同處理機數條件下，兩種線程庫的 volanomark 結果。從圖中可以觀察到以下三點：
- NPTL 能極大提高 SMP 環境下服務器系統的整體性能（超過 65%），相對而言，對單處理機系統影響較小（10% 左右）；
- 2.6 內核的搶占特性對系統性能影響很小（不超過 ±1%），某些情況下甚至有所下降；
- 超線程技術在 LinuxThreads 中的影響是負面的，在 NPTL 中是正面的，但影響幅度都很小（5% - 6%）。
以上結論中前兩點與 LMBench 針對性測試結果完全吻合，第三點的偏差實際上反映了超線程技術對於綜合服務器環境還是有一定加速的。
五、 總結
我們的評測為廣大 Linux 用戶，特別是服務器用戶提供了一點有價值的參考：
- 如果你的是多處理機系統，那麼毫不猶豫地升級你的內核，並記住，一定要同時升級你的線程庫，它通常與 glibc 緊密耦合；
- 如果你的系統並沒有實時應用，不要打開 "內核可搶占" 開關，它只會讓你的系統更慢；
- 慎重考慮是否使用超線程技術，即使你已經購買了支持超線程的 CPU，有時關閉它可能更適合你的需求。