基本介紹
- 中文名：執行緒構建模組
- 外文名：Thread Building Blocks
- 縮寫：TBB
- 開發商：Intel公司
OSCON 上，Intel 宣布，Threading Building Blocks，Intel 眾多軟體開發工具中的一個，open source了。協定是 GPLv2。
TBB 獲得過 17 屆 Jolt Productivity Awards，是一套C++模板庫，和直接利用 OSAPI寫程式的 raw thread 比，在並行編程方面提供了適當的抽象，當然還包括更多其他內容，比如 task 概念，常用算法的成熟實現，自動負載均衡特性還有不綁定 CPU 數量的靈活的可擴展性等等。STL之父，Alexander Stepanov對此評價不錯，他說“Threading Building Blocks… could become a basis for the concurrency dimension of the C++ standard library”。其他 TBB 的早期用戶，包括Autodesk，Sun，Red Hat, Turbo Linux 等亦然。現在 O’Reilly 已經出版了一本 Intel Threading Building Blocks: Outfitting C++ for Multi-core Processor Parallelism。
Intel 內部大概在 2004 年有了 TBB 的概念，2005 年 team 成立，2006 年 8 月發布 1.0，這個程式看上去勢頭不錯。
和業界目前層出不窮的並行解決方法/方案比較，TBB 有自己的優勢，例如：和 OpenMP 比…喔，他們幾乎是兩回事…關於 OpenMP 有個笑話：OpenMP is great if you have Fortran code, or C code that looks like Fortran, or C++ that looks like Fortran，或者說，一句話，flat do-loop centric parallelism。另外，如果你的項目不適合甚至不允許 pragma 來 prgma 去的，那就麻煩了。
目前 TBB 也仍然作為售價 $299 商業產品（包括了 Intel C++ Compiler Professional Editions 10.0）銷售，因為有些用戶更喜歡 Intel 的支持服務。一個不知道是好訊息還是壞訊息的信息是，如果我用 TBB 和 Intel Compiler 配合編寫的程式，在 AMD 的 multicore 處理器上會有更好的 performance 嗎？答案是，很多情況下，確實會提高的
對 TBB 或者說並行編程趨勢的完整理解和支持只可能最先發生在工業界，這不是你在論壇上看到的某個蹩腳程式設計師或者業餘愛好者願意花精力或者有機會實踐的東西，Autodesk，Sun 和 好萊塢 是典型的最渴望和最歡迎任何這方面的有益舉動的廠商。DDJ 對 James Reinders 的訪問，其中有一段，或許，有一天會擴展 TBB 到支持Java和.Net吧。
Raw thread 幾乎鐵定不是最方便和具備可移植性的選擇，某種程度的 wrapper 只能改良而無實質變化，TBB 引入 generic parallel programming 的支持是個大進步，當然這也不能說完美，TBB 有不方便的地方（有些來自 C++ 有些來自 TBB 實現），而且不一定適合某些特定問題域，所以GoogleSawzall（適合大規模數據並行處理的腳本語言） 和YahooPig 都是很好的對比參考（當然，他們是更不 generic 的實現，更針對自己的問題），至於硬體對 parallel progarmming 的支持比如 transactional memory… 扯更遠了哈。
出於照顧客群的原因，不少介紹和推廣 multicore 處理器優勢的資料都會說你可以一邊運行防毒軟體，一邊處理照片等等，我得說，這個比方真的很蠢，它模糊了實質，也讓人覺得職業程式設計師們沒幹什麼正事兒，可是，如果你沒法跟他聊算法，數據流以及指令序列，那也就這么著了吧。
Jakob Nielsen 和 Steve Jobs 的看法有很多類似之處，大多數用戶要么根本不知道自己要什麼，要么說出來需要什麼後，旋即轉身要求其他更好的繼而讓他剛剛告訴你的東西成為廢話。你得敏銳地觀察他們的行為，分析趨勢，這是個預測未來的活兒，你得做好準備去迎合至今尚不存在，將來卻會鐵板釘釘的那個“需求”。用戶可能會覺得你現在提出的 idea 非其所需，或者不過是忽悠人，甚至蠢得可以，這樣的過程在iPod身上發生過，在 Parallelism 身上正在發生。
