[WEBGL] [转]WebGL、WebCL、多核：使用RiverTrail在浏览器中并行运行Javascript的现状和未来

315 主题	0 听众	1万积分

资深设计师

Rank: 7 Rank: 7 Rank: 7

纳金币: 10878
精华: 0

电梯直达

楼主

发表于 2011-11-23 11:43:00 |只看该作者 |倒序浏览

         虽然当下连移动设备都具有了并行处理的能力，但JavaScript还是停留在串行时代。

         Intel实验室正在致力于开发一个JavaScript的扩展

         ，该扩展可以充分利用多核心系统的优势，目前已经释出了

         Firefox的插件

         。


         这个JavaScript的并行扩展的开发代号叫做River Trail，Intel实验室试图凭借这个项目为web应用带来Intel多核CPU和其矢量扩展指令集的强大处理能力。River Trail将尝试把一些对计算能力敏感的应用程序，例如照片编辑，带入到浏览器当中。


         River Trail会在运行时将JavaScript翻译到低级的硬件抽象层，成为确定的并行数据架构。在多核CPU和矢量指令集的作用下，River Trail宣称已经可以

         为原本串行计算的JavaScript带来显著的性能提升

         。


         特别值得一提的是，它为JavaScript添加了一种新的数据类型ParallelArray，这是一种只读的数据结构，用于储存当前的并行数组数据。并行数组可以从JavaScript数组、类型化数组或者是用于生成并行数组数值的函数中创建。比如“new ParallelArray([1,2,3])”可以创建一个值为“1,2,3”的并行数组。作为返回值的结果，并行数组中的内容可以被像

         combine

         、

         filter

         、

         map

         、

         reduce

         等等这种并行处理数据的函数访问；这些JavaScript函数都被编译成OpenCL，可以作为JavaScript的子集使用。


         关于River Trail项目，InfoQ独家访问了Intel实验室的Stephan Herhut。


         InfoQ：River Trail项目的动机是什么？


         Stephan：这个项目启动的时候我并不在Intel。所以我询问了一开始就在项目组里工作的Rick Hudson，项目是怎么启动的。他是这样说的：“启迪我们动机的是，我们相信多核、众核以及矢量指令集可以简化并提供给终端程序员，特别是使用JavaScript工作的web应用程序员。为web应用程序员提供高性能还是高产能，一直是一个顽固的问题，也是其中一个吸引我们的地方。


         InfoQ：比起来直接写OpenCL代码，你认为用JavaScript作为输入语言有什么关键的优势？


         Stephan：对于这个问题应该从两个角度来看：对于web开发者有什么优势，以及对于JavaScript引擎和浏览器的开发者有什么优势。


         对于web开发者，我觉得最主要的优势在于简单易用：他们不必学习一门新的语言，可以继续留在他们熟悉的编程环境。RiverTrail构建于JavaScript的概念之上，比如数组、函数，像map和reduce函数，闭包作为函数参数来传递等等。实际上RiverTrail中真的没有新的语言结构。另外，当迁移至RiverTrail时，在大多数情况下web开发者可以直接复用他们的代码。他们只需要将for循环用RiverTrail自己的基元比如map替代，但是这很容易。实际的工作量并没有增加。至少这是一个愿景。我们当前的原型因为本身的限制还没有达到这个目标，但是我确信我们肯定可以实现的。


         另外一方面对于引擎开发者来说，最主要的优势在于安全。浏览器是主要攻击对象，用户们都希望浏览器可以确保一种安全的web体验。OpenCL被设计成工作于客户端应用程序，这些程序通常来说都是用户从可信任的地方获得并由他们自己安装的。它们基本上都是由C语言系的语言的编写的，有它的好处也有危险之处。而JavaScript，是开发给web使用的，而web上的代码通常信任度都不高。我们保持了那种设计思路。RiverTrail使用了和顺序执行相同的安全机制，比如数组边界检查。


         另外一个问题是可用性。Web应用会运行于许多不同的平台和设备上，从笔记本电脑到移动电话。在所有这些平台上JavaScript都已经可以运行了，而OpenCL却不行。在浏览器本地的JavaScript引擎中应用RiverTrail可以直接将RiverTrail代码翻译成矢量化的机器码。即使是一个完全的顺序执行也可以使用。所有API的设计目的通常已经足够允许不同的实现。


         InfoQ：有没有不能用JavaScript语法表达的OpenCL代码？JavaScript不要求类型声明的缺点是不是一个麻烦？


         Stephan：RiverTrail从来不是想要被设计成为web上的OpenCL的。我们只是在原型中使用OpenCL作为后端技术。RiverTrail使用了更高级的抽象。因此，我们不支持一些低等级的OpenCL特性，比如本地内存共享、屏障同步或Workgroup同步。对于像RiverTrail这种高级API来说，这些都太OpenCL了。类型的问题比我们预想的要轻松很多。首先，之前在WebGL中引入的类型化数组已经给予了程序员一种影响数据布局的工具。我们在RiverTrail原型中只是扩展了一下。其次，JIT引擎在优化数值表现形式方面做得越来越好了。为JavaScript加入类型推断的工作也取得了重大的进展，它可以在计算时对数据类型进行性能最优化的猜测。RiverTrail可以顺其自然的从中受益。


         InfoQ：是否可能在某些地方同时使用RiverTrail和WebCL？这时还是否可能是一个纯JavaScript操作？比如，不需要本地OpenCL运行库？另一个想法是将WebCL和WebGL结合在一起。看起来好像River Trail可以从Canvas中取出位图数据，而且还能拷贝到OpenCL内存中，或者从OpenCL内存中拷贝出来。结合WebGL和WebCL，是否可以用WebCL（用River Trial生成内核）来处理WebGL的数据，然后再将数据直接返回到WebGL中而不拷贝回到浏览器内存中？


         Stephan：我们决定采用Firefox扩展的形式有它的历史原因。当我们开始RiverTrail项目时还没有WebCL；而当WebCL可用时，我们已经完成了自己的接口。这个接口是一个简化的、降低功能性版本的WebCL。在GitHub上，除了我们的Firefox扩展，RiverTrail已经有一个使用WebCL作为后端实现的分支。我不确定它是否支持在WebCL和WebGL之间共享缓冲。目前我的着眼点在于向web开发者学习，如何才能让RiverTrail更好的满足他们的需求，并基于他们的反馈来更新API。我欢迎任何人来构建基于WebCL的版本，我会全力提供支持。比如哪些方法可以提供潜在的优化，这很有意思。


         InfoQ：目前JavaScript的哪些语言结构是你们支持的？你们是否计划添加更多支持？


         Stephan：我们在GitHub上的原型只是一个概念证明和我们实验语言特性的地方。目前，我们只支持原始数据数组。我们还支持数组嵌套，但是它们只能是规则的形式。比如，我们建立一个含有4个矢量元素的矩阵模型来表示一个canvas中的图像数据。另外一个限制是，我们不支持引用全局值或内核中的函数调用。大部分的这些限制都是因为我们的原型不是内置于JavaScript引擎中的。相反，我们的编译器是用JavaScript编写的，并运行于JavaScript引擎之上。这种途径允许我们可以快速建立特性原型，但是限制了我们对于引擎内部信息的访问。现在已经有工作开始让SpiderMonkey公开更多内部信息给脚本层，一旦其得到了实现，我们会检查是否可以去除一些限制。最后，也许，RiverTrail应该直接成为JavaScript引擎的一部分。


         InfoQ：对于目标语言OpenCL限制了JavaScript的特性你们支持的如何？


         Stephan：主要的限制就是堆（heap）管理。OpenCL需要我们把那些想要访问内核内部的JavaScript堆强制映射到OpenCL堆。这也正是现在我们只支持原始类型数组的原因之一。对于数组嵌套和任意对象数组的完全支持需要跨越甚至拷贝底层数据结构。这根本不可能，对于CPU端的执行也是没有必要的。


         InfoQ：数字，你们把所有JavaScript抽象语法树中的数字都翻译成double了吗？还是说，你们会区分double和integer？（比如，x=42会被翻译成一个整形数吗？）


         Stephan：JavaScript的语义要求所有计算都用64位浮点数执行。许多情况下并不需要这么高的精度，RiverTrail允许web开发者在内核执行中指定使用32位浮点数。除此之外，我们还使用了范围分析来推断用整形计算是否安全。这常用于循环边界。在你说的例子中，如果我们的编译器能够证明接连不断的写入x的操作都会限制在32位整形数范围内，那么x=42会让x作为整形数来储存。如果我们不能证明，那么x会被作为浮点数或双精度浮点数来储存。


         InfoQ：ParallelArray是目前River Trail提供的主要的抽象封装。你们还会添加其他的抽象封装吗？还是说所有的任务都可以映射成为ParallelArray？


         Stephan：ParallelArray的抽象封装很适合于并行数据的负载。并行编程中另一个有趣的地方是并行任务的负载。分而治之算法就属于这个领域。Web worker有点像往那个方向发展的意思，但是它太臃肿了，也不允许共享状态。我目前还没有明确的答案，但是看起来并行任务是一个很值得深入的领域。


         InfoQ：Web开发者可以直接利用GPU和多核CPU，你怎么看未来的web应用？


         Stephan：我自己并不是web开发者，但是我对他们的创造力非常钦佩。当年Chrome和Mozilla放出WebGL的demo的时候，我坐在我的笔记本前面都惊呆了。所以真的很难说将来会怎么样。从能力的角度上来说，web应用将会越来越像本地应用，但是又完全不一样。Web应用的一个巨大优势就是连通性。它们可以接入不同的数据源、将不同的东西混搭、加入实时信息，然后用让人惊叹的视觉方式展现出来。我希望web拥有越来越强的沉浸感，少一点集中于网页的web。我唯一知道的可以确定的事情就是，我一定会为开发者的创作而感到震惊。


         InfoQ：这个项目未来的路线图是什么样的？


         Stephan：我们正在致力于消除原型的限制，并探索如何能够推进项目以便完全支持JavaScript。其中的一个部分就是将RiverTrail直接放到JavaScript引擎里面。我们正在和Mozilla合作，将RiverTrail内置整合到他们下一代JavaScript引擎中，对于更多的引擎支持，我们欢迎任何帮助。另外一个相当重要的事情就是用户反馈。最后，我们乐于看到RiverTrail作为一项公开的标准成为JavaScript的一部分。然而，我们还是想要确认它是否满足了web开发者的需求以及他们关注的可用性。对于反馈，我们依赖于网络社区。所以，请试试RiverTrail吧！用它创作出一些新的东西，并告诉我们你的体验！





         原文地址：

         http://www.infoq.com/news/2011/11/webgl-webcl-multicore-rivertrail




         HiWebGL翻译整理  （原文http://www.hiwebgl.com/?p=608）