技术奇异点

在美国参加了一周的公司 Tech Summit ，之后几天做了一些项目上的交流。这是工作以来到国外出差最愉快的一次。其中的原因是因为所在的公司不同，所工作的产品不同，交往的人不同，也因为我自己和以前不同。美国的工程师和经理都非常友好而且优秀。其中两位华人更是在工作中充满活力和激情，而且为人豪爽。

除了大基调比较愉快之外，还有一些小细节准备得比较成功。

首先是一定要带自己的 laptop 。每天不能睡自己的床，不能盖自己的被子，不能待在自己的书房，不能用自己的专用浴袍，这些本来就是很不爽的事情。如果再加上不能在熟悉的 laptop 上阅读和娱乐，那整个行程中几乎就没有任何放松的机会可言。所以，即便回了酒店只是用 Safari 上上网，也必须打开自己的 laptop 才能算真正的放松。更何况在这边买了《 StarCraft II 》，如果不在自己的 laptop 上也有诸多不便。所以，千万不能偷懒只带公司的 laptop ，我曾经有三次出差不带自己的 laptop 的经历，都不太愉快（当然也不是带了就一定愉快，还有很多其它因素）。我还曾经把公司的和自己的两台 laptop 都作为随身行李，结果旅途中和安检的时候都非常累。这次把公司的 laptop 随托运行李，所以很轻松。

其次是一定要早睡早起。这样白天精神好，应付工作不会觉得压力大。特别是从开会到中午吃饭聊天开玩笑都必须全程英文的时候，这种压力甚至稍稍超出了工作的范畴。早起争取的时间很珍贵。如果不是单独出差，那么同行的同事计划安排之间的一些冲突和摩擦是一种额外的无形压力，每天从别的同事起来的那一刻就扑面而来 —— 打到你房间的电话、在 lobby 商讨出行和会议的安排等等。比其他人都早起几个小时是一种非常大的优势，可以不受打扰的观察和思考全天的安排或者决定打扰别人（而比其他人都晚睡几个小时是得不偿失的，甚至是不可能的）。

最后，从睡眠的另一方面来说，越早消除 jet lag 的影响，也就拥有越大的优势。所以从踏上启程航班开始，就要严格按照目的地时间安排睡眠。

18 日清晨，步行去公司的路上。准备喝杯咖啡然后把停在公司停车场的车开到酒店。离回国的航班起飞还有 6 个小时。

度过了异常忙碌的一周。后天就要去美国参加公司的 Tech Summit 了。晚上把包收拾一下。这个是我自己的 MacBook Pro 。明天还要用内胆包带一个公司的 MBP 。如果只拿公司的本子，就会觉得晚上过的很没意思。

每当提到如何『评价』面向对象技术时，很多人的直接反应就是上升到世界观层次。说它让软件设计和客观世界更好的一一对应云云。我非常怀疑这种思考方式。客观世界是多维度的，面向对象的软件系统只能选取一个维度进行描述，同时为兼顾其它维度要做各种 leaky 的妥协。因此，对一个客观场景总有很多个可能的面向对象『设计』存在，每种『设计』都不能被认为是错的，甚至不能被认为是差的。这种一对多的情景很难让我信服面向对象技术比其它手段能更『自然地』描述世界。对我来说『自然地』只有一种标准 —— 容易取舍的单一选择。

面向对象技术没有脱离面向过程和命令式（ imperative ）的思维。有经验的 C++ 、Java 、Objective-C 程序员在阅读和编写代码时能熟练到近乎反射地把 this 或者 self 作为一个参数来思考（比如 0->func() 这样的调用为什么在某些情况下是可行的），或者把函数 override 作为函数指针的另一种形式（比如 0->func() 为什么在某些情况下是不行的）。这里没有任何世界观的升华。面向对象真正的便利仅限于消除负面副作用（ negative side-effects ）。

举个例子来说明什么叫负面副作用。假设在程序中有个二维的『单位向量（ normalized vector ）』，其方向任意，长度必须为 1 。这个数据通常表式为 x 分量和 y 分量。作为单位向量，必须满足 x 和 y 的平方和始终为 1 ，这种条件叫做对象数据的不变式（ invariation ）。不小心打破不变式，比如把 x 和 y 都设成了 1 （平方和变成了 2 ），这种行为就叫负面副作用。在数据暴露给所有算法代码的编程方法中，不变式是通过文档由程序员人工保证的。面向对象方法认为人工保证容易出错，所以通过隐藏对象的数据，只允许有限的成员函数访问它们来保证不变式。这样需要精心维护的涉及不变式的代码仅限于少量成员函数。类似的例子还有如何表示一个钢体（内部没有复杂结构，各部分的相对位置不会变化的物体）在三维空间的位置和姿态。钢体本身的形状一般用一组顶点表示，它在三维空间的位置和姿态用一个 4 x 4 的变换矩阵表示。熟悉 3D 几何的人知道，4 x 4 矩阵可以表示拉伸、平移、旋转、甚至扭曲等任意的变换。但是对于钢体来说，只有旋转和平移是有物理意义的。所以必须对这个数据结构中的 4 x 4 矩阵做出限制，即钢体对象的不变式。

从另一个角度来看，面向对象保证不变式的方式未必是理想的。首先，人工约束不变式并非那么难。Linux kernel 核心数据结构的不变式就是通过活跃的讨论和 code review 保证的。其次，人工约束不变式可以让设计者天然地保持警觉，把核心数据结构的数量最小化。最后，不变式可以通过合理的设计数据结构来减小甚至消除。比如上面单位向量的例子里，可以把单位向量用一个夹角 —— 即它和坐标系的某个轴的夹角来表示。这样的表示法不再需要额外维护不变式。类似地，在钢体的例子里用一个平移向量和一个旋转向量代替 4 x 4 矩阵表示位置和姿态，可以减少要维护的不变式。

这两个例子都说明，不变式来自数据结构的信息冗余。当然，表示复杂的对象很难做到完全消除信息冗余。若底层 framework 的 API 直接提供 4 x 4 矩阵运算或者 (x, y) 二维向量运算，我们就要考虑在这样的系统上构建对象的简便性和复杂度，未必要舍近求远用平移、旋转和夹角来表示。同时，保持冗余信息也是提高性能的手段，很多操作都需要 x / y 分量或者 4 x 4 矩阵，如果不直接存储它们，就要在每次需要的时候临时计算。所以造成不变式的信息冗余又来自两处：一是性能优化的需要；二是支持我们构建对象的底层系统中可以被直接操作的模块粒度不够小。这就像现实中我们没法构建一个无需仓库的物流，也无法用纳米亚原子直接打造机器。

前面提到用非面向对象技术消除副作用并非难如登天。另一方面，复杂系统的信息冗余不可能完全消除决定了面向对象技术多少是有用的。这里的结论是不要把一种消除副作用的便宜之计吹捧成改变世界观的灵丹妙药。特别是在一叶障目之后，容易忽视背后的更本质更有效的手段。很多吹捧面向对象技术的人往往喜欢把系统的核心数据结构设计的非常庞大，信息非常冗余。从编写复杂的保持不变式的代码中获得不真实的成就感。这种过度吹捧在面向对象以外也有例子。并行化技术最大的负面副作用是不同线程同时修改一份数据，即 race condition 。消除这个副作用有几个方法，其一是被诟病的 lock 技术。Lock 的问题在于为了试图保证数据的不变式引入了时序上需要额外保证的不变式。在《多核与锁》里有所讨论，这里不过多涉及。

接下来是两种直接保证并行处理中数据不变式的手段。一个方法是只用栈变量，因为栈是每个线程独立的。更精确的说是只使用 per-thread 数据，因为有些 per-thread 数据其实在全局堆里，只是通过 per-thread 的引用来管理，而且后面马上说到有些系统的 per-thread 数据不是基于栈。这方面有一个最近成为热门的例子 —— GPU 运算。OpenGL 的 GLSL（ shader language ），CUDA 和 OpenCL 的编程语言处理的数据都仅限于当前 GPU core 使用的 per-thread 变量。另一种方法是根本不用变量，那就是一小撮人推崇备至的函数式编程（ functional programming ）。在《并行计算的解药》里我讨论过，前一种手段里分割输入数据才是关键。而后一种，我认为根本是步子迈的有点大，扯着了。对这两种手段的评价，都只能限于消除副作用的影响，解决问题的真正关键在于更高层次的数据分割。

一项技术技术是否能被主流软件开发社区采用，不在于世界观和哲学那类东西，而是更实际的 —— 在消除副作用的同时保持原有的思维方式；至少增加的额外思考不能超过熟练程序员的反射弧。要求改变世界观的技术一开始就失败了一半。

自从成为 Mac 用户之后，我一直非常想把 Firefox 从系统中清除出去。原因有三个：第一，我基本不用 add-on ，偶尔重度使用的几个功能也都有 Safari extension 或者 Chrome extension ；第二，从 code base 的角度说，我对 Webkit 的信任度大于 Firefox ；第三，Firefox 太『土气』。前两条我认为尚属个人感觉。这第三条从道理上说主观的不能再主观，可我相当肯定这种感觉。和 Safari 相比，Chrome 经常给我欠修饰，不圆润的感觉，但绝对没有『土气』。可看到 Firefox 就和看到上世纪 80 年代风格的服饰一样，而且是那种绝不会借复古卷土重来的土气。

最近发现一例，是对正在下载图片的处理（注意这里的例子是正在下载但还没有结束也没有彻底下载失败的图片）。Safari 是直接留白（强调一下，Safari 对彻底下载失败的图片的处理并非留白）。

Firefox 的处理是从上世纪不变的黑框加『圆、方、三角』图标。

这两种效果有什么区别？不用讲太多道理，第一感觉就是 Firefox 的效果太『土气』。我和同事曾经比较过一些应用的界面。一个可拖动的分割线（ draggable separator ）是单像素宽的黑线还是多个像素宽的伪 3D 效果，这点区别就能决定一个界面是整洁还是凌乱（猜猜哪种让界面更整洁）。这种感觉不易量化，但绝对客观存在。不管有什么理由，『土气』就是一种缺陷，就意味着你得花额外的精力从其它方面弥补。

Firefox 的『土气』带来了什么收益？它告诉了用户一个在今天的网络状态下持续不会超过两秒钟的状态（为了抓上面那张图我费老了劲了，真想找个让网速临时慢下来的工具）。去掉这个状态的可见性不会令用户丝毫不便，刻板的显示这个状态给用户带来的只有一闪而过的『视觉污染』。就这个例子来说，Firefox 的设计不仅仅是土气的问题，它忽视了 UI 设计的一个基本原则，不要浪费用户的注意力。用户的『注意力』是稀缺资源，这种知道不知道两可的程序内部状态无需让用户费心。这是 Firefox 对拨号时代的遗产长久不加审视的体现。我不敢说从这个例子可以总结出什么一般规律，但是我怀疑那些表面上看着土气的设计也总是隐藏着对可用性的某种深层次的忽视。

作为一个棋力不高，但尚可作为消遣的普通人，我认为棋力的高低体现在头脑中能预先演算多少步棋。不过，听说即使是高手演算时也常会犯一种错误。举例来说，当演算到第三步的时候把一个子移开，但是演算到第五步的时候会下意识觉得那个子还在第二步的位置。这叫做『残影』棋子。

在做编程这样的复杂工作时，也经常在逻辑概念的变换中构建『残影』。最近就因为一个『残影』两天没有睡好觉。先不说犯错的经历，讲讲相关的概念本来应该是什么样子。计算机图形系统的终极目标是生成二维图像，这个图像可能会显示在显示器上，或者存储成文件，可能是一幅静态图片，也可能是一组图片构成的动画，可能是一幅照片，图案，也可能是一个虚拟 3D 场景的影像，总之终归是一个（或者多个）二维图像。生成二维图像需要预先开辟绘制的空间。这种空间一般显卡的显存中创建，因为这样才能使用 GPU 硬件加速。OpenGL 里对这种空间的抽象叫做 Framebuffer Object（ FBO ）。

我在《 OpenGL 随想》系列里说过 OpenGL 是一个重度依赖 context 的系统（ Cocoa 的 Quartz 和 Windows 的 GDI+ 也依赖 context 。Quartz 的概念模型来自 PDF ，所以文档和打印系统也依赖 context 。由此可见一切图形相关系统都建立在 context 这个基础概念之上）。Context 这个概念有多重要，多基础，就体现出我后面犯的那个错误多愚蠢。FBO 是 OpenGL context 中的一部分，一个 context 可以拥有多个 FBO 。其中 ID 为 0 的 FBO 用于屏幕显示。

如果严格如上所述，那么这个模型是优美的。可是，OpenGL 设计之初只考虑到屏幕显示，FBO 在 OpenGL 2.1 和之前都不是标准的一部分，只是一个扩展（ FBO EXT ）。所以屏幕显示并不是真的被称为 0 号 FBO 。创建所谓『 0 号 FBO 』的过程和创建其它 FBO 的过程大不相同，所需的参数都直接传给创建 context 的函数。就是这个陷阱构建了逻辑『残影』的陷阱 —— 我把 context 当成了对『 0 号 FBO 』的封装。

正在开发的程序对 OpenGL 的应用都是 offscreen 渲染。所有的 onscreen 显示都在 OpenGL offscreen 渲染之后用其它方式完成。因为开发刚开始的时候在 Windows 平台上没来得及搞清如何使用 FBO EXT ，所以在 Windows 上的 offscreen 渲染也用的是『 0 号 FBO 』（ Mac OS X 版本从一开始就使用了 FBO EXT ），必须创建一个不可见的窗口并将其 DC 句柄作为『 0 号 FBO 』传给 wglCreateContext() 。由于『 0 号 FBO 』和显示硬件紧密绑定，所以对高级需求有一些不可接受的限制。比如，普通 PC 显示器的单个色彩通道深度不超过 8 位，用『 0 号 FBO 』就没法生成 16 位色彩深度的位图。这时我开始在 Windows 上研究使用『真正的』FBO EXT 。

工作了一夜之后，我开始认为『真正的』FBO 解决了问题，而最初构建的那个逻辑『残影』从此开始作祟。因为把 context 当成了 『 0 号 FBO 』的封装，同时有了『真正的』FBO，我毫不犹豫的删掉了创建 context 的代码，包括在 Windows 上创建隐藏窗口和调用 wglCreateContext() 的代码，和在 OS X 上创建 CGL context 的代码。

结果当然是悲剧了。为了让过程更悲壮，删掉创建 context 代码之后的程序居然在一台 Windows PC 上和所有 Mac 上运行正常（除了一个不怎么被测试到的 case ）。这个结果当然让我的『 context 不过是 0 号 FBO 的封装』的歪曲理论更加坚固。随着程序在其它 Windows PC 上产生垃圾结果，以及那个失败 case 被发现，我的头脑也跟着崩塌了。早上还在和同事夸耀删掉了创建 context 的『无用』代码，晚上就陷入了呆滞。

第二天早上醒来，迷迷糊糊中突然想起了什么是 context 的真实含义。早晨同事见到我的第一句话是『我觉得是删掉 context 的缘故』。知道这件事的美国同事也来信说他猜想是 context 的问题，尽管他只看到了运行结果没有看过代码。看来大家晚上都在思考啊（虽然美国是白天）！

回头分析，凭空构建出『残影』固然在于我因为时间紧迫没有仔细思考概念，但是很大程度上也是因为 OpenGL 的 API 由于历史原因没能清晰和正交的反应真正的概念。各个 FBO 本该在概念上平等，而且完全不用『 0 号 FBO 』的情况也是合理的，那么从 OpenGL 的状态机概念来讲，FBO 应该在 context 创建之后挂靠其上，而不应该和创建 context 的函数有任何语法上的直接关系。但是实际创建 context 的函数（ CGLCreateContext() 和 NSOpenGLContext ；wglCreateContext() ）都需要一个事前创建的『 0 号 FBO 』作为参数，哪怕这个『 0 号 FBO 』完全没有用处。

能在沙发上看电子书是件很爽的事情。但是我又不喜欢长时间用 iPad 这样不够通用的设备。宜家的这个小板子还是很不错的。喜欢开『卡车』的也可以很舒适。

前几天看到 reddit.com 的 programming 类别第一名是《 Parallelism is Not Concurrency 》。读完之后发现和我去年的《多核与锁》有很多观点上的共通之处。《 Parallelism is Not Concurrency 》的开篇行文更流畅幽默，对并发（ concurrency ）和并行（ parallelism ）有更精辟的总结。比如：

Concurrency is concerned with nondeterministic composition of programs (or their components).  Parallelism is concerned with asymptotic efficiency of programs with deterministic behavior. Concurrency is all about managing the unmanageable. … Parallelism, on the other hand, is all about dependencies among the subcomputations of a deterministic computation.  The result is not in doubt, but there are many means of achieving it, some more efficient than others.

谈及『依赖（ dependency ）』在并行计算方面的关键地位之后，《 PINC 》进行了一个有趣的推理：

1. 因为依赖是个关键概念而且它是高于硬件的抽象概念，所以我们需要一个基于语言的并行计算模型；
2. 因为依赖阻碍并行，所以我们需要一个消除了依赖的并行计算模型；
3. 由 1 和 2 ，我们需要一个能最大限度消除依赖的编程语言；
4. 所以，functional 编程语言是解决并行计算的终极形态。

这个四步推导其实非常脆弱。首先看第 2 步，它的结论是需要一个『消除了依赖的并行计算模型』，这与《多核与锁》中谈到并行计算需要把数据分割成没有依赖关系的独立块的说法是一致的。但是，『消除依赖』是指在数据中消除依赖，是指对问题本身，或称为『问题域』消除依赖。因此准确的推导应该在第 3 步中提及的『最大限度消除依赖的编程语言』之前加上『在问题域中』这个修饰语。但是，很不幸，第 4 步的 functional 编程语言只是在编程阶段，或者称为『实现域』中消除了程序员引入依赖的能力。

人们经常想当然地把『消除』视为『消除烦恼』的同义词。但是，只有在问题域中的消除才基本保持这个同义性。而在实现域中编程语言消除程序员的某种能力更贴近于『强迫』。『强迫』的好处在于让程序员更自觉的用更好的更清晰的方法考虑问题。前提是，程序员已经拥有更好的更清晰的方法，只是经常限于时间和精力图省事抄近路采用一些丑陋的方法。这个前提在很多时候是成立的，比如说，程序员都能轻易的避免使用混乱的 goto ，而另一方面，他们又都倾向于随意使用 goto ，所以，一种禁止使用 goto 的编程语言是好的（当然，C 并没有禁用 goto ，而是把 if-else 、while 、for 等等分支功能做得易用而且优美，从而比粗暴的禁止更好发挥作用）。

很明显，这个前提在并行计算中不成立！程序员还没有一种真正通用的方法可以在问题域消除影响并行的依赖。假设一个程序员精通各种顺序排序算法，唯独没有学习过 Quick Sort 算法。那么即使学会 functional 编程语言之后，这个程序员也不可能自动的把原来的顺序算法改写成适合并行的形式。消除依赖需要在问题域的艰深研究而不是实现域编程语言的强迫。研究万有引力需要高深的微积分工具，而其结论万有引力公式只需要简单的代数知识就能在大多数场合应用。类似的，一旦在问题域中取得了消除依赖的突破，传统的编程语言往往也能很轻易的实现并行。例如并行编译这个问题，因为 C 语言在设计的时候就保证了单个文件在编译时没有对其它文件的依赖，所以并行编译只要简单的多运行几个编译器进程就能实现。（不要把这里的『设计语言』和原文四步推导中的『语言』混淆。对于编译来说，C 语言的设计是问题域而非实现域。）这时形式上消除依赖的 fucntional 编程语言倒是多余的了。

另一个例子是 3D 图形处理，这个问题包含大量的数据计算，比如顶点位置。而每个顶点的位置可以独立计算没有相互依赖。因此业界可以为这个问题建立消除依赖的硬件模型 —— GPU（ 同样，这里的消除是『强迫解除能力』的意思，因为问题域本身天然地免除了依赖 ）。这就给《 PINC 》中的第 1 步推导提出了反例，对天然免除了依赖的问题是可以建立基于硬件的模型的。而另一方面，因为 GPU『强迫解除』了通用 CPU 的很多能力 —— 比如要求数据的小粒度分割和缺乏对分支的支持，当业界想把 GPU 用于通用并行计算的时候，遇到的最头疼的问题是如何把原来在 CPU 上运行的程序改写成适合 GPU 的形式。当 functional 编程的拥趸苦恼 functional 语言的小众化现状的时候，其实已经有了一个流传广泛的低级 functional 编程语言，这就是 GPU 及其接口 OpenGL/OpenCL/CUDA 。这个模型已经在大多数 PC 上（包括 Mac ）甚至很多 mobile device 上得到推广，实现了 functional 编程拥趸们在推广度方面的梦想。但是奇迹并没有自动出现，在问题域还是遗留了众多的工作要做。

所以，解决并行性能的关键，不在于急匆匆的在编程语言级别剥夺程序员引入依赖的能力，而在于研究更多问题的本质，去掉那些直观上存在但是并非本质上不可消除的依赖。实现域的『强迫解除』并不能带来问题的自动解决。等问题域的依赖被解除了，再考虑语言级别的问题不迟。即使到了那个时候，我也不认为 functional 语言会成为主流，因为和用来取代 goto 的 if-else 、for 、while 相比，functional 语言解决问题的方式还是十分丑陋的。