自主学习报告第二周S_Part

并行编程

并行与并发的区别

并行与并发是两个不同的概念。从CPU的角度上看，并行是将命令切分成多个等分部分同时执行，而并发是多个线程在同一个单核CPU上交互执行。并发是在一个单核CPU上实现多线程“同时”运行的效果，而并行才是真正利用到多核CPU的特点。

并行

首先说说数据流并行处理的底层实现：数据流并行处理的底层实现是依托fork/join框架，相信大多数人都听闻过这个框架。

当一条数据在线程中被执行，fork框架会递归把命令等分成多个部分，然后在各自的线程中同时执行，当然这个同时执行是有条件的，就是CPU的核心数足够执行这些命令。当然也有可能fork在递归等分数据的时候可能，而且是很有可能先读取核心数，然后根据核心数等分数据（这是因为我在本地八核CPU执行并行流的时候，唤醒了八个线程执行，这一点上一篇有提到）。假如核心此时刚好在处理别的一些数据，这时就难免粗现竞争了。

最后各个线程执行完毕之后把结果汇总到join层进行整合，这就是为什么我们下文即将会提到的状态会对并行有影响。

对并行有影响的因素

这一节我觉得特别重要，我自己也在这个问题上纠结了很久。

我们只知道，并行会提高效率，却从来没想过也许并行只会降低效率，至少我之前没这么想过。最近看了并行这部分的书籍之后对并行有了一个初步的了解。深深地了解到，并行编程并不是单单只是把代码从串行改成并行而已。分析一个并行算法的时间，远比你下手写代码的时间占比重要大。

首先说一下目前的硬件方面的现状。（对于这方面我只是大致了解，有错误的地方请帮我纠正。）很久以前，摩尔定律统治芯片界大半个世纪。智库百科上对摩尔定律是这样描述的：

摩尔定律是指IC上可容纳的晶体管数目，约每隔18个月便会增加一倍，性能也将提升一倍。摩尔定律是由英特尔(Intel)名誉董事长戈登·摩尔（Gordon Moore）经过长期观察发现得之。

在很长的时间这个定律都是正确的，直到到了近代，这个定律开始慢慢失效。IntelCEO贝瑞特单膝下跪标志着统治芯片界大半个世纪的摩尔定律轰然倒塌。

单核CPU的发展已经到了瓶颈，很多人都认为，在新的研发工艺问世之前，单核CPU的处理能力已经很难被提高了。于是工程师们想到了一个对程序猿们而言十分糟糕的想法：搭载多核心的CPU，这样就把问题顺利的踢给了程序猿。

那么问题就被踢皮球给了程序猿。就目前而言软件的发展已经远远跟不上硬件的发展了。因为懒惰的工程师们想到了那个该死的搭载多核CPU的想法，于是超级计算机也很快问世了，很多家用计算机也被搭载了多个核心处理器。这样程序猿面临的问题就是如何更高性能地利用多核的优点。答案很明显，就是设计并行程序。优秀的并行程序并不仅仅是尽可能低的代码串行化，而是能真正提高运行效率的。因此，并行程序的因素就是设计并行程序的程序猿们不得不考虑的问题。下面是我总结的几个影响因素：（如有缺漏，请指出，谢谢。）

首先并行必然有等分数据，整合数据的时间开销，因此一个程序有没有必要设计成并行，这是我们不得不优先考虑的问题。桌面应用我们一般不会设计成并行，因为他没有那么大的数据操作，并行的代价远比并行为它带来的收益要大。一般有被考虑设计成并行的有后台服务端的开发，而且是那种被大量访问的服务端，还有图片软件这一类，因为它涉及大量的像素点计算。

然后在使用并行流处理数据的时候要考虑状态，前一篇我们讲过了有状态和无状态的区别，简单来讲，有状态和无状态的区别主要在于生成newstream的元素是否依赖oldstream的元素。上面我们也讲了fork/join框架，这是大多数并行程序流行的框架，这样就很容易联系两者了。假如是有状态的流转换，意味着我们在等分数据的时候就把这种状态检查的工作也等分了，这样到了合并的时候我们不得不再检查一次各元素的状态。因此在流的处理中，无状态的转换远比有状态的多。

暂停，等到有些许经验再更。