多核时代的移动开发（二）-水煮并行计算

思前想后决定采取还是把这一系列的博客做成一个互动型的东西，以闲话或者说是水煮的形式来说写今天的话题，不论是问题还是意见我都尽量做出回应。首先我想说这么几点

一、很多人看完第一篇总介之后都觉得所谓的并行计算是编译器的功劳，这种观点没有问题，但是请大家思考以下两点。

1、其实JAVA和c#能完成面向对向的功能也是编译器的功劳，但是不意味着了解了JAVA的语法就能写出面向对象的JAVA代码了，我刚刚开始从C转C++的时候写的其实还是纯C的方式写的面向过程的代码，是不是有真的转变关键在于是否掌握了面向对象的思想，在多核时代的情况也是一样。

2、我这次写博客的目的也完全不想介绍F#的语法，我想表达的意思其实是就像当初在软件工程不断复杂的情况下面向对象的思想获得了极大的发展一样，多核时代的到来使函数式编程的思想在编程领域的应用带来的很大的机会，所以我想透过这种语法分析到今后软件开发的趋势。

二、就像有些网友所说对于很多的移动应用来说只要分清WEB请求，用户界面以及复杂逻辑处理并让他们分别运行在不同线程，就可以最大限度的发挥出多核的优势了，这样的情况其实已经在我上个月序言中所讨论过了，我以拓词或者说是什么宝宝学汉字这类比较火的应用软件为例，其核心价值是创意与相关的教育资源或者说是美工等等，程序员从这些应用的角度切入到移动平台我个人觉得上升空间有限。相反如果能利用现有的移动平台做出更炫的游戏渲染效果，更强的数据处理能力这会是移动程序员核心价值的体现。

好了总结就说这么多，我本篇之所以要叫做冷眼观F#,就是想换一个角度来讲述F#，既然还是有这么多朋友说没看明白，那么本期咱们还是争取把上一期所讨论的理念说透。

我们把上一期的例子换种说法变成一个故事来解读：

一、一个医院在在创立之初只有一个医生可以为患者检查，那么做为院长你采用了如下的策略，为每一个患者编号从1到N，第一患者进来就医给他发送1号号牌，在第一个患者看完病以后，发放2号号牌给第二个患者，以此类推，以上简称号牌法来解决医院就医的问题。（评注：可能您已经注意到这其实是典型的面向过程式的解决方案，所谓的号牌法其实就对应着FOR循环，解决简单的问题时候所谓的高级编程工具什么函数式、面向对象式，其实都不太派得上用场，任何解决问题的方式都会对应一种场景）

二、有了号牌法管理医院,就医的秩序好多了,但是随着医院的规模逐步加大，医院先后上线CT，验血等这些检测措施后，原本简单的就医流程变得很复杂了,还是任何一个小的流程有改变都要把整个就医流程变掉。

面对这样的情况我们就把检测工作的单独提取出来并成立一个检测科，并单独定义照CT及验血的流程，那么好了，在总的流程当中只需要调用验血等这样的接口就可以了，而且无论是CT的流程还是验血的流程变化都不需要再改总流程了，最大的好处是今后再加入新的检测流程也就是检测科的事情了，不需要院长再插手管理了。（评注：其实这部分讲述了面向对象编程思想兴起的情况，随着流程的不断复杂化，把问题解决过程看按照一个整体来管理会有问题，模块化管理形成趋势，这也是面向对向编程兴起的原因）

三、再接下来随着医院中的人员继续增多，像缴费，化验这些耗时较多的工作都会有专门的人来处理，在得到结果并形成相应报告之后再通知给医生。（评注：在组织规模不算太大的时候,让负责主要工作的医生不再需要管什么缴费挂号之类的事情可以提高效率)

四、随着医院规模越来越大,医生也越来越多了,让几个医生同时给一个患者看病其实就是一个医生不断的工作,而其它的医生没有工作做,没有效率可言，那么之前制订的号牌法已经不再适用了。

这时如果想提高效率那么就有两种管理风格可选，第一种就是要结果，我就姑且叫他外行管理模式，院长只是表达提高患者就医效率的目标，至于怎么能提高效率的交给另外的职业经理人来做。第二种就是再有就是将过程详细化，第二种就是要过程，也就是内行管理模式，你要详细的知道每位医有哪些资源是私有的比如医生的办公室（可以理解为CPU的寄存器，每个CPU都有相应的寄存器不会引起冲突），哪些是公共资源比如候诊室（可以理解为内存，如果两个CPU同时对同一内存访问会存在冲突），然后对每个的诊疗的流程制订详细的计划与规则，确保公共资源不会被同时访问。这样也能达到增加并行吞叶量的目的。

好希望上面的例子我们重点来对最后一种并行的情况来做分析。

1、其实无论是内行管理模式还是外行管理模式，最关键的还是在正确的环境下使用正确的做法，其实我们上一篇博客所说的List.Map写法在这个小故事中对应的就是外行管理模式，而有些朋友在博客回复中所提到的ERLANG其实就是内行管理模式，无论采取哪种模式最需要避免其实就是其实是外行还要给制订相应的规则与流程，如果这家医院本身的医生很多，候诊室很大，但还是要坚持号牌法的管理，那恐怕要出问题。

2、其实无论是内行管还是外行管的方式，都不能保证一定可以系统增加吞吐量。一个最简单的例子：假如整个医院空间不足，同时只能接待一位病人，那医院配再多的医生也不解决问题。同理数据处理中计划瓶颈可能不在CPU的数量，那么针对多CPU优化的模式肯定不会起到作用。当然也可能内行管的模式下规则制订有问题，或者外生管理模式下医院请的职业经理人有问题都有效率降低的可能。

3、做一个简单的类比：ERLANG这种对应内行管理的语言，类似于单核时代的汇编语言，而F#这种对应外行管理类的语言，类似于单核时代的C语言。当然这个类比并不够严谨，但是可以表达我要说的事情了，汇编语言执行效率肯定会更高，但是他的代价就是软件开发成本高。而C语言虽然会牺牲部分效率，但是掌握及开发成本相对低，在EARLOG VS F#的时代基本上是类似的情况（请注意我不是指掌握语法的难易）。

    好了，要说的就这么多，我发现做一篇以闲话F#的形式写博客真的是很难，看各位的接受程度吧，如果没什么问题，而且12月22日的太阳还是照常升起的话：），我还将延续这种形式来继续下一个-延时计算。