技术奇异点

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

在做编程这样的复杂工作时，也经常在逻辑概念的变换中构建『残影』。最近就因为一个『残影』两天没有睡好觉。先不说犯错的经历，讲讲相关的概念本来应该是什么样子。计算机图形系统的终极目标是生成二维图像，这个图像可能会显示在显示器上，或者存储成文件，可能是一幅静态图片，也可能是一组图片构成的动画，可能是一幅照片，图案，也可能是一个虚拟 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 语言解决问题的方式还是十分丑陋的。