六 142010
《关于并行貌似正确的废话》系列文章：
封装这一永恒的主题，在多核的时代还会永恒下去吗？答案是肯定的!
既然四个核的存储一致性都很难通过高效的机制保证，众核时代，更是如此。这众核肯定是若干个小的，结构简单的，功能不同的核的集合体。未来的程序，单单的串行，这么多核，很难充分的利用。功耗已经很高了，多少个核，就至少是多少倍的功耗提升，仅仅依靠投机也是不行的。
未来的编程是什么样子的？我想至少每个高级程序员都要是优秀的管理者，像一个经理一样，他很清除这个任务需要一步步到怎么怎么完成，很清楚任务要怎么划分为很多个子任务。子任务之间相对独立，子任务间接口清晰。子任务有各自的特点，计算密集、还是IO密集，浮点运算还是整点运算。这些子任务最好能和已有的一些程序或者算法匹配，这样省去很多不必要的串行开发。
子任务之间不能再靠简单的if else来解决问题，应该是一种单纯的依赖关系约束。A需要B，B需要D和E，E可以直接执行。类似于Makefile中的规定。编译器或者某种程序会根据这个任务划分迅速做拓扑排序，得到想要的并行执行序列。
一个优秀的管理者，知道如何将任务细分，将合适划分的任务给合适的人去做，让任务和任务之间在协调时尽量的简单，清晰。这也是程序员未来的工作之一吧。
还是一个永恒的主题：封装！
单个任务内部的工作，串行的部分，还是必不可少的。而且依然是最主要的，因为它是根基。它是人思考问题最基本的方式。任何时候，人只会想要计算机适应人类。所以未来的并行编程要像串行一样简单，或者能提供令人兴奋的性能加速，若二者不占其一，那死路一条。
感觉又绕回来了。电脑的不行，还得靠人的干活。
问题在于，人他娘的就是不善于干这事。
正如你所说，串行是人思考问题最基本的方式。我相信，手写并行程序是少数人的一种天赋，绝大多数程序员永远学不会。
@ayaya, 加州大学伯克利分校做并行的，有个人总结了并行编程的未来。你可以先看考一下。作者提出未来的并行编程应该以数据为中心。围绕数据流展开。http://www.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-144.html
@erlv, 看过了啊，对这种类型的并行不怎么感兴趣。感觉这种并行，比你电脑上的 Word 和我电脑上的 Firefox 同时运行的的并行，强不了多少。
我感兴趣的是科学计算中的那种并行。
我也知道，要编译器去发现代码中的粗粒度的并行性是过于苛刻了。我希望对于粗粒度的并行性,也能用类似 OpenMP 那样的标记方法把可以并行的”并行模块”之间的依赖关系描述出来,然后编译器来处理.也许操作系统调度上也需要改进来处理这种程序内部的”并行模块”.
嗯，如果关于并行的任务相当一部分交给了程序员，那么哪些关于并行的任务可以留下来让编译器自动完成或者智能判断的呢？
@baozii, 细粒度的应该交给编译器来做。粗粒度的，任务级，都应该是程序员完成。程序员应该主导整个并行化工作。编译器只能在程序员写好的程序中，再试图找出更多的机会。
今天一有空就来看看，呵呵，拿到板凳了…
你以前的一篇文章曾经提到共享内存式的编程很容易出错，那么象actor这样的消息传递模型能“简洁”地在多核芯片上实现嘛？好像现在编程在一个芯片内部的多核之间还是使用共享内存的模式，在计算节点之间才使用消息传递的模式…
@baozii, actor不是很了解。但片上多核间消息传递用的比较少。