并行计算有向无环图和fork/join 框架

    从多任务OS开始，线程主要用来表示IO异步；而今随着4G和多核等的到来，计算密集型又热门起来了。

硬件价格和性能从低到高：
PC/Laptop multi core, memory shared
PC clusters
SuperComputers
假设一个理想并行计算机：每个处理器计算能力相同，忽略调度，

static thread 是对一个虚拟处理器的软件层面的抽象;
static强调的是线程一直存在，不包含线程的创建和销毁。

dynamic multithreded concurrency platform:
通讯协议，负载平衡调度器
spawn a subroutine
parallel loop


并行计算有向无环图
只有三个关键字： parallel, spawn, sync
并行控制指令:spawn, sync, return(包括函数末尾的隐式return)
不包含并行控制的指令序列表示为一个顶点;
顶点u到v的有向边表示指令序列u必须先于v执行; 这时称u,v是串行的，
否则是并行的。
我们把边(u,v)分为：
continuation: 在同一过程实例中，v是u的直接后继。
spawn: 如果u spawn v。
call:  如果u直接调用了v。
return: u返回到调用它的过程，v是这个过程里面紧接sync的。


性能度量
work 是指仅在一个处理器上总的执行时间。如果把一个顶点的执行时间是1,
则work就是顶点总数。
span 是图中最长的路径执行的时间。如果一个顶点花的时间是1,
则span等于图的关键路径长度+1。


Tp记为用p个处理器所花的的总时间。
P*Tp >= T1
T1 是用1个处理器所需的时间，显然，T1 = work。
Tinf 表示用无穷多个处理所需的时间， 显然，Tinf = span。
T1/Tp 称为加速量(speedup)。如果T1/Tp = P, 则称为perfect linear speedup。
T1/Tinf 称为并行度(parallelism)。
T1/(P*Tinf) 称为slackness。


一个好的调度器追求的目标就是越来越接近perfect linear speedup。
贪心调度器：在每个时间步，把尽可能多的顶点分配给处理器。
定理： 使用贪心调度器, Tp <= T1/P + Tinf。
实践中，
slackness 至少是10，则Tinf < 0.1 T1/P，从而Tp <= 1.1 T1/P，对于工程应用已经足够好了。
这里我们看到并不是并行度越大越好。


例1
FIB(n)
 if(n <= 1)return n;
 else x = spawn FIB(n-1)
      y = FIB(n-2)
      sync
 return x + y;
T1(n) = T(n) = \phi^n;
Tinf(n) = max(Tinf(n-1), Tinf(n-2)) + 1
    = n;
容易看到，n值不用太大，就可以达到perfect linear speedup.


例2
MATVEC(A,x)
 n = A.rows;
 parallel for i = 1 to n
  yi = 0;
 parallel for i = 1 to n
  for j = 1 to n
    yi = yi + aij * xj;
 return y;
把第二个parallel 用spawn来实现：
MATVEC_LOOP(A, x, y, n, 1, 8);
MATVEC_LOOP(A, x, y, n, i1, i2)
  if i1 == i2
    for j = 1 to n
 yi = yi + aij * xj;
  else mid = (i1+i2)/2;
       spawn MATVEC_LOOP(A, x, y, n, i, mid);
  MATVEC_LOOP(A, x, y, n, mid+1, i2);
       sync 
spawn 个数对应为二叉树内部节点个数=叶子树n-1，总共有n个叶子，因此额外开销spawn分摊到每个叶子为常量。 每个叶子的计算量此时不能再看做1,而是n。因此
 span = lgn + n,
 work = n^2,
并行度 = n.
如果对for j 也加上parallel, 则并行度可达到n/lgn。

工程实践：
C/C++ 有 gcc/cilkplus， 因为我下载网上的x64二进制文件， 一直搞不定LD_LIBRARY_PATH，需要从源码编译工具链， 有空的时候练一下。

java 有fork/join framework ，这个框架有什么优点？
当一个fork子问题join等待另一个子问题时，会去偷尚未运行的子问题来执行。
因此每个子问题应该避免使用synchronized,sleep,阻塞IO或过多访问共享变量。

ForkJoinTask类的抽象方法比较多，不适合直接继承，而是继承它的子类RecursiveTask/Action。
子问题执行由ForkJoinPool来调度。

work stealing 如何做到负载平衡？
每个工作线程A都有自己的一个队列。当A划分出一个新任务，把它加入到队列头部(TBD)；只有A才可以操作它的队列头部并取出来执行。
当A的队列为空时，它将尝试从另一线程B的队列尾部偷一个任务。
由于这种队列操作特性，是的最大的任务排在队列尾部，从而是的其他线程来偷取实现负载平衡。

一个简短的例子说明多线程的优势：

参考：

[0] 算法导论第三版

[1] 两种任务分发方式的比较: http://stackoverflow.com/questions/7926864/how-is-the-fork-join-framework-better-than-a-thread-pool
[2] concurrent collections 的介绍: http://www.ibm.com/developerworks/cn/java/j-tiger06164/
[3] parallel for: http://stackoverflow.com/questions/4010185/parallel-for-for-java