WebGL, WebCL及多核：在浏览器中使用River Trail实现并行JavaScript的现状与未来

现在连移动设备都具备了并行处理能力，但JavaScript仍然是串行的。Intel实验室正在着力创建JavaScript的一项扩展，该扩展会利用多核系统优势，并已发布了Firefox插件。InfoQ对来自Intel实验室的Stephan Herhut进行了关于这项工作的独家采访。

这种开发代码为River Trail的JavasScript扩展是Intel实验室的一个项目，该项目致力于将Intel多核CPU的处理能力以及向量扩展（vector extension）应用于web应用程序中。River Trail正努力使计算密集型（compute intensive）应用程序——如图像编辑软件——能在浏览器中运行。

River Trail使用确定性数据并行结构对JavaScript进行扩展，该结构在运行时会被转换到底层硬件抽象层。通过调控多个CPU核心与向量指令，River Trail将大大提高并行JavaScript的性能。。

值得注意的是，River Trail在JavaScript中添加了ParallelArray数据类型，这是存储真实并行数组数据的只读数据结构。我们可以用JavaScript数组，类型化的数组，或用于产生并行数组数据的函数来创建并行数组。例如，“new ParallelArray([1,2,3])”将创建一个存储数值1，2，3的并行数组。该数组的内容能够被combine，filter，map，reduce等对数据进行并行处理的函数访问。分配给它们的JavaScript函数会编译成OpenCL。这些函数能够使用JavaScript的一个子集。

InfoQ对来自Intel实验室的Stephan Herhut进行了关于这项工作的独家采访。

InfoQ：请问开发River Trail项目的动因是什么？

Stephan：该项目开始的时候我还不在Intel，所以我问了参与这项工作的Rick Hudson，这个项目是如何开始的？他说：
“因为我们相信可以对多核程序和向量指令系统进行简化，从而提高编程人员——特别是使用JavaScript的web应用开发人员——的生产力。向web应用开发人员提供高性能和高生产力的结构是个棘手的问题，同时也是激励我们的原因之一。”
我在年初就参与了这个项目，真正使我感到兴奋的是River Trail非常符合HTML5技术。有很多问题限制了web应用能够具有内建应用所具有的功能，HTML5解决了很多方面的问题。然而，谈到性能时，web应用仍然有很大的差距。浏览器厂商在提高JavaScript引擎性能方面已经做了很多工作。当我在内建JavaScript中看到broadway h.264这样的解码器时非常惊讶。然而，JavaScript基本上是串行的。WebWorker允许后台长延时处理，但对于并行计算来说过重。River Trail解决了数据并行处理的问题，我们在GitHub上的原型证明了这是一种可行的方法。

InfoQ：你认为与直接编写OpenCL代码相比，使用JavaScript作为输入语言的关键优势是什么？

Stephan：这个问题涉及两个方面：一是对web开发者来说有什么好处，二是对JavaScript引擎开发者以及对浏览器来说有什么好处？
对web开发者来说，我相信最大的好处就是易于使用：他们不需要学习一门新语言，能够继续使用他们熟悉的编程环境。RiverTrail建立在已有的JavaScript概念之上，比如数组，map和reduce函数，作为函数参数的闭包等等。在River Trail中并没有新的语言结构。所以，很多情况下开发者能直接在Reiver Trail上重用他们的代码。他们需要将for循环替换成River Trail的基本类型，比如map，仅仅如此而已。实际的实现方式通常不需要变化，至少我们希望如此。我们目前的项目原型还不能做到这样，但我相信我们最终能实现。

问题的另一个方面是对引擎开发者来说有什么好处？最大的好处就是安全性。浏览器是一个主要的攻击入口，而用户希望浏览器能提供安全的上网体验。OpenCL是为客户端应用程序设计的，用户通常会从安全的地方得到安装程序。它基本上是C语言的翻版，具有C语言一样的功能和安全问题。因此，JavaScript是被设计成在web上使用的语言，来自web的代码通常不可信。我们坚持这样的设计原理，即River Trail使用和序列化执行同样的安全机制，比如数组边界检查。
另外一个问题是普遍性。web应用程序运行在许多不同的平台和设备上，从笔记本到手机都有。在这些平台上JavaScript普遍存在，但OpenCL也许不存在。River Trail在浏览器JavaScript引擎上的内建实现可以将RiverTrail代码转换成向量化的机器码。即使完全序列化的执行也是有效的。API都是经过精心设计的，很具有一般性，允许有许多不同的实现方式。

InfoQ：存在不能用JavaScript语法来表达的OpenCL代码吗？JavaScript缺乏类型声明不会出现问题吗？

Stephan：我们从来没有把RiverTrail成web版的OpenCL。只是我们恰巧在项目原型中使用了OpenCL作为后台技术。RiverTrail使用了更高层次的抽象。因此，我们并不支持底层OpenCL特性，比如本地内存共享，同步屏障或工作组。这些特性是OpenCL才应该有的，但并不适合River Trail这样高层的API。类型问题并没有我们所想的那样大。首先，WebGL引进的类型化数组已经能让程序员操纵JavaScript中的数据存储方式。这已经一定程度上在我们的River Trail项目原型中采用了。其次，JIT引擎在优化数据表示上越来越强大。JavaScript类型推断的研究取得了不错的进展，目前能推断出哪些计算最好在哪些类型中执行。RiverTrail顺其自然地受益于这些进展。

InfoQ：有可能在某些地方将River Trail和WebCL一同使用吗？如果这样的话，可以保留一个纯JavaScript的版本吗？比方说不需要内建OpenCL库的版本？另一个想法是整合WebCL和WebGL。好像River Trail能够从Canvas中获取位图数据，但好像它是在OpenCL内存之间来回复制的。通过整合WebGL和WebCL，有可能可以获取WebGL数据，用WebCL进行处理（使用River Trail产生的核心），然后再将数据转移到WebGL，而不用将它复制回浏览器内存。

Stephan：我们决定实现自己的Firefox浏览器扩展完全是由于历史原因。当我们开始Reiver Trail工作的时候还不存在WebCL，而当WebCL出现后我们已经实现了自己的接口。该接口相当于WebCL的简化版本。在GitHub上有一个River Trail的分支项目，该项目使用WebCL作为后台实现，而不使用我们的Firefox浏览器扩展。但我不确定该项目是否支持在WebCL和WebGL之间进行缓存共享。我现在关注的重点是从web开发者那里了解River Trail是否符合他们的需求，然后根据他们的反馈改进API。我欢迎有人能开发一个基于WebCL的版本，并乐于提供帮助。我很有兴趣看看这种方式能有怎样的改进潜力。

InfoQ：你们目前支持什么样的JavaScript语言结构？你们计划提供更多的支持吗？

Stephan：我们在GitHub上的项目原型是对概念的验证，也是我们对语言特性的实验。目前，我们只支持基本数据数组。我们虽然也支持内嵌数组，但要求其具有最简单的形式，例如，我们将canvas中的图像数据构建成具有4个元素向量的矩阵。另一个限制是我们不支持对全局数值的引用和在内核中的函数调用。这些限制大多数是由于我们的原型不是在JavaScirpt引擎内实现的。相反，我们的编译器是用JavaScript语言编写的，并运行在JavaScript引擎之上。此方式能让我们迅速地构建原型特征，但限制了我们访问引擎的内部信息。SpiderMonkey正在进行将更多内核信息暴露到脚本层的工作，一旦此工作完成，我们会看看是否能再消除掉一些限制。但最终来讲，River Trail应该直接成为JavaScript引擎的一部分。

InfoQ：OpenCL目标语言对于你们提供JavaScript特性支持有哪些限制呢？

Stephan：最大的限制就是堆管理。OpenCL要求我们显式地将那些我们要从内核中访问的JavaScript堆映射到OpenCL堆。这就是我们目前只支持基本类型密集数组的原因之一。要完全支持内嵌数组和任意对象的数组，须要遍历和深入地复制底层数据结构。这在CPU上执行是不可行也没有必要的。

InfoQ：关于数值，你们将JavaScript AST中的所有数值都转换成双精度浮点型吗？还是你们会区分双精度浮点型和整型？（例如：‘x = 42’会被转换成整型吗？）

Stephan：JavaScript语义要求所有计算都应在64位浮点上进行。但我们通常不需要这样高的精度，River Trail允许web开发者指定在内核执行时使用32位浮点。除此之外，我们已经实现了一系列分析，用以推断在整型上计算是否安全。在循环边界判断上通常就是这样。对于你的例子，如果我们的编译器能证明对x的连续写操作能保持在32位整型值范围之内，‘x = 42’就会使x作为整型存储。如果我们不能验证这样做的稳定性，那么x就会作为单精度浮点型或双精度浮点型存储。

InfoQ：ParallelArray目前是River Trail提供的主要抽象。你们有提供其它抽象的想法吗？或者说所有的任务都能被映射成ParallelArray吗？

Stephan：ParallelArray抽象非常符合数据并行负载。并行编程的另一个有趣主题就是任务并行负载。分而治之的样式算法也在这个主题之内。webworker也有同样的特性，但它们过于复杂，同时也不支持状态共享。我还不知道确切答案，但任务并行是个值得研究的领域。

InfoQ：在web开发者可以直接调控GPU和多个CPU核的情况下，你认为web应用在不久的将来会有什么样的进步？

Stephan：我自己不是web开发者，但我非常敬佩他们的创造力。当看到Chrome和Mozilla的WebGL示例出现的时候，我坐在我的笔记本前感到非常惊讶。所以很难预料将来会发展成什么样。在功能上，web应用将会越来越像内建应用，但在其它方面又会有很大的不同。web应用最大的优势就是它们的连接性。它们可以使用不同的数据源，将数据进行整理，实时地更新数据，用很炫的视觉效果展现数据。我希望web能变得更具有渗透性，而不仅仅是以页面为中心。我能肯定的是我将会为web开发者创造出来的东西感到震惊。

InfoQ：该项目接下来的计划是什么？

Stephan：我们目前正在努力提高原型的适用范围，同时正在探索如何尽可能地完全支持JavaScript。其中一部分工作就是将River Trail直接引进JavaScript引擎。我们正在与Mozilla合作将RiverTrail整合进它们的下一代JavaScript引擎，同时我们也欢迎与其它浏览器引擎的合作。还有另外一项重要的工作就是处理用户反馈。最终，我们希望RiverTrail成为JavaScript的一部分，作为一项开放标准。我们想保证它确实能满足web开发者的需求以及他们关注的可用性。我们想依靠web社区来完成这些事情。请玩玩RiverTrail，用它构建新玩意，并将意见反馈给我们。

查看英文原文：WebGL, WebCL, MultiCores: The State and Future of Parallel Javascript in the Browser with RiverTrail