OSCON 上，Intel 宣布，Threading Building Blocks，Intel 眾多軟體開發工具中的一個，open source 了。協定是 GPLv2。
TBB 可以在 Windows，Linux 和 OSX 上運行，支持 Intel, Microsoft 和 GNU 工具，這就覆蓋了絕大多數需求範圍。
Intel 內部大概在 2004 年有了 TBB 的概念，2005 年 team 成立，2006 年 8 月發布 1.0，今年 4 月 1.1，這個程式看上去勢頭不錯。
和業界目前層出不窮的並行解決方法/方案比較，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 實現），而且不一定適合某些特定問題域，所以 Google Sawzall（適合大規模數據並行處理的腳本語言） 和 Yahoo Pig 都是很好的對比參考（當然，他們是更不 generic 的實現，更針對自己的問題），至於硬體對 parallel progarmming 的支持比如 transactional memory… 扯更遠了哈。
出於照顧客群的原因，不少介紹和推廣 multicore 處理器優勢的資料都會說你可以一邊運行防毒軟體，一邊處理照片等等，我得說，這個比方真的很蠢，它模糊了實質，也讓人覺得職業程式設計師們沒幹什麼正事兒，可是，如果你沒法跟他聊算法，數據流以及指令序列，那也就這么著了吧。
Jakob Nielsen 和 Steve Jobs 的看法有很多類似之處，大多數用戶要么根本不知道自己要什麼，要么說出來需要什麼後，鏇即轉身要求其他更好的繼而讓他剛剛告訴你的東西成為廢話。你得敏銳地觀察他們的行為，分析趨勢，這是個預測未來的活兒，你得做好準備去迎合至今尚不存在，將來卻會鐵板釘釘的那個“需求”。用戶可能會覺得你現在提出的 idea 非其所需，或者不過是忽悠人，甚至蠢得可以，這樣的過程在 iPod 身上發生過，在 Parallelism 身上正在發生。
黑體亮溫
TBB(Black Body Temperature) 相當黑體亮溫
運用FY-2C衛星雲圖及其相關定量資料TBB,對熱帶風暴"范斯高"的強度、路徑及降水進行了綜合分析,歸納出"范斯高"發生髮展中雲系的一些特徵,從而判斷其強度變化和移動方向;在降水方面,黑體亮溫(TBB)場和降水量有很好的對應關係,TBB場清晰地揭示了"范斯高"的降水分布特徵。
