多线程是个不靠谱的东西

这只不过是假象而已


(lambda x:x+3) (x+2)

Apply alpha[x/y]: lambda z . (lambda y . y+z)) (x + 2)
Apply beta: (lambda y . y + x + 2) 3
Apply beta: 3 + x + 2.

对于任何一个纯函数，都能表达为lambda式。对lambda 式可以使用树规约或者图规约.
前者是串行的而后者是天然并行的
比如说这是一个典型的bottom up树规约
((2 + 2) + (2 + 2)) + (3 + 3)
= ((2 + 2) + 4) + (3 + 3)
= (4 + 4) + (3 + 3)
= (4 + 4) + 6
= 8 + 6
= 14
或者构造一个的top down树规约
((2 + 2) + (2 + 2)) + (3 + 3)
= ((2 + 2) + (2 + 2)) + (6)
= ((2 + 2) + 4) + 6
= (4 + 4) + 6
= 8 + 6
= 14
这两种规约都是一颗树

           +
       +      +
    +     +  3 3
 2   2  2  2

这几天搞Parllel，才发现多线程远比想像中的困难，而不只是资源的冲突和锁定那么简单。利用多线程，首要目标是让任务并行，让数据的处理更有效率。但是，问题是什么样子的数据该并行处理？？

首先我排除了大部分的文件读写操作，顺序读取会导致文件指针的移动，这显然会导致不确定数据结果，特别是要把数据填充到一系列结构（Struct)中去的时候，多线程产生了一堆错误的结果。

其次内存中数据操作似乎也不好确定是否该用多线程，线程的生产、切换、消费都要消耗时间，在single core的机器上，多线程只会更没效率而不是更有效率。对于multi core的机器呢。。。情况似乎变得复杂，线程时间片和操作时间片的长度似乎是一个很关键的因素。对于“短”操作来说，花在线程消费上的开销，远远大于起并行带来的时间减少，因此，多线程只会更慢，而不是更快。但难点是，如何找到一个临界点，以作为是否引入多线程操作的阀值？ 线程消费的开销，可能随着机器的情况而变化，包括CPU的usage，CPU的核心数目。。。。


我翻了MC#(multi core C#)，PLinq，Parallel C#,谁也没告诉我答案，我们不缺工具，但缺best practise

我们花了 N 多资源来研究和制造多核 CPU，我们花了 N 多资源来研究并行计算的各种技术，然后却发现找不到合适的靶子 —— 究竟哪些问题是需要而且能够用并行计算来提升性能的？大多数应用，性能瓶颈不在计算能力上；瓶颈在计算能力上的应用，多数位于专业领域，怎么分解怎么并行，早研究透了，成熟的解决方案一堆一堆。于是手里拿着 PFor，却是把剑四顾心茫然。

嗯嗯，我预言，为“不得不购买多核 CPU”的主流市场找到新的应用，会是并行和多核领域后面几年的焦点。能找到的人，就成功了。

怎么分解怎么并行，早研究透了，成熟的解决方案一堆一堆。

究竟哪些问题是需要而且能够用并行计算来提升性能的？

瓶颈在计算能力上的应用，多数位于专业领域，怎么分解怎么并行，早研究透了，成熟的解决方案一堆一堆。于是手里拿着 PFor，却是把剑四顾心茫然。

嗯嗯，我预言，为“不得不购买多核 CPU”的主流市场找到新的应用，会是并行和多核领域后面几年的焦点。能找到的人，就成功了。

都有哪些方案?
基础原理是"纯函数 + 副作用隔离屏蔽"吗?

我的理解是,
应用领域中,纯函数能够描述的问题是小部分,大部分都是在处理副作用.
而只有纯函数才能够多核并行.
因此,并行计算在应用领域中,难以找到用武之地.
是这样吗?

其实, 静态页面 HTTP Server就是一个很典型的纯函数并行应用领域.不涉及到任何副作用.
不知道有没有这方面的产品?
可以添加修改数据的动态HTTP Server一定会涉及到副作用,但是大部分应该还是纯函数.

游戏中,并行计算有没有用武之地? 比如,大型动画图像的动态计算渲染显式.
这些只需要按照空间分块,就可以多核并行计算(分任务,分函数都行)吧?

关键的问题是要便宜，首先应用硬件要便宜,这方面现在的确便宜了，几年前搞并发/并行的那几个人难道还不是窝在通信/服务器那陀人?为啥亚，买个双CPU主板是要银子地.
其次是写程序要便宜,这东西现在来看其实还不便宜，别的不说瞧瞧从通信出生的那陀人吧，开发的时候还不是抡着lock,event_driven大榔头赤膊上阵，程序出错的时候，那个不是撩起袖子倒腾几百兆的log查bug？
只有等写程序真正便宜了，才会有新的应用。就像VB/Delphi之前的时代，有人会用WINSDK写仓库管理系统吗?

游戏倒的确是一个很典型的需要并行计算能力的领域，不过很大一部分计算量是显卡承担的。

还记得MPEG解压卡，和SB32的时代么?

记得啊，我还知道 intel 有个计划用数十核的 CPU 来把这部分计算量重新纳入 CPU。不过这次世道可能不一样了：

1. 上次我们还没碰到半导体技术的物理瓶颈。
2. 3D 游戏需要的计算量比那两个大若干数量级。
3. 现在来看，CPU 要想接管显卡的工作，唯一的办法是自己加上几十个专用的运算核心，这个其实等价于把显卡做进 CPU 去，我不看好这种做法的性价比。换句话说，成本上未必有优势。
4. 不是每个人都喜欢玩 3D 游戏的，很多人不会愿意为这个能力买单。所以这方面的能力做成一个“选配件”要比集成进 CPU 更讨人喜欢。