BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 D. Synodinos 关注 0 他的粉丝 , W. Schuster 关注 0 他的粉丝 ,译者 蔡坚安 关注 1 他的粉丝 发布于 2011年11月29日. 估计阅读时间: 14 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

现在连移动设备都具备了并行处理能力,但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的并行数组。该数组的内容能够被combinefiltermapreduce等对数据进行并行处理的函数访问。分配给它们的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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

并发性,多核开发 by 王 秋

js发展到现在不仅仅是作为只是针对DOM操作的语言了。并发性的研究也渐渐被重视起来,前端工程师们,给力呀。
谢谢译者的翻译和分享。

美好的方向 by è°¢ 蔚

需要主流js引擎能够支持它,道路还比较艰辛。后端更应该重视js带来的改变,与其可行性。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

2 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT