1线程构建模块编辑
TBB,Thread Building Blocks,线程构建模块，是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，今年 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 实现），而且不一定适合某些特定问题域，所以GoogleSawzall（适合大规模数据并行处理的脚本语言） 和YahooPig 都是很好的对比参考（当然，他们是更不 generic 的实现，更针对自己的问题），至于硬件对 parallel progarmming 的支持比如 transactional memory… 扯更远了哈。
出于照顾受众的原因，不少介绍和推广 multicore 处理器优势的资料都会说你可以一边运行杀毒软件，一边处理照片等等，我得说，这个比方真的很蠢，它模糊了实质，也让人觉得职业程序员们没干什么正事儿，可是，如果你没法跟他聊算法，数据流以及指令序列，那也就这么着了吧。
Jakob Nielsen 和 Steve Jobs 的看法有很多类似之处，大多数用户要么根本不知道自己要什么，要么说出来需要什么后，旋即转身要求其他更好的继而让他刚刚告诉你的东西成为废话。你得敏锐地观察他们的行为，分析趋势，这是个预测未来的活儿，你得做好准备去迎合至今尚不存在，将来却会铁板钉钉的那个“需求”。用户可能会觉得你现在提出的 idea 非其所需，或者不过是忽悠人，甚至蠢得可以，这样的过程在iPod身上发生过，在 Parallelism 身上正在发生。
