BT

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

讨论:我们是否需要一种通用的Web字节码?

| 作者 Abel Avram 关注 9 他的粉丝 ,译者 臧秀涛 关注 4 他的粉丝 发布于 2013年5月29日. 估计阅读时间: 8 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

我们是否有必要费力创造一种通用的Web字节码?LLVM就是解决方案吗?Mozilla asm.js和Google PNaCl这两种支持在浏览器中运行原生代码的机制,哪种更好呢?本文汇集了网络上的一些相关观点。

ArsTechnica上发布了一篇有关以JavaScript编写视频编解码器的文章Raniz的评论在评论区和网络上引发了激烈的讨论。Raniz提议“在浏览器中使用一种标准化的字节码,使开发者可以在更多的语言中做出选择”,开发者可以选择他们所喜欢的Web编程语言,不一定使用JavaScript。字节码可以是与JVM或CLR的字节码类似的通用平台,不过这里支持的是Web开发而已。这种想法乍看上去很有意思,有人甚至建议将LLVM的位码(bitcode)用作中间“字节码”。目前包括ActionScript、Ada、D、Fortran、Haskell、Java字节码、Objective-C、Python、Ruby、Rust、Scala和C#等多种语言都有了相应的LLVM编译器

位码要依赖于目标平台,这是其主要问题,也就是说,为不同架构生成的位码是不同的,这与Java不同,因为不管面向哪种平台,Java生成的字节码都是相同的,由JVM针对所运行的机器生成原生代码。通用的Web字节码还存在其他一系列问题,其中有一些也困扰着LLVM位码(详情请参阅这里),msclrhd在评论中指出了一些问题,下面我们节选了一部分:

将字节码标准化会给浏览器如何优化JavaScript代码带来一些限制……

基于什么字节码进行标准化也存在问题,因为不同的JavaScript引擎会使用一组不同的字节码,而且语义不同。所有引擎需要就字节码的使用达成一致。

还有一些需要注意的问题,比如不同引擎使用的字符串表示有所差别(V8/Chrome使用的是ASCII字符串变体,而Mozilla选择的是UTF-16),类型表示也不相同(比如Firefox使用了64位的fatvals,其中32位表示值的类型,32位表示值;64位的double用到了NaN值的表示……)。

如果字节码是二进制的,还有大小端和浮点数表示等问题。

AlonZakai是Mozilla的研究人员,主要从事Emscriptenasm.js相关的工作,他就通用的Web字节码写了一篇完整的博客,其中列出了实现该目标面临的一些困难:

因为各种原因,你想要这种字节码,而他想要那种字节码。有人就是偏爱某种虚拟机上的语言。但有的字节码虚拟机是专有的,或者受专利保护,或者被某家公司牢牢控制,有人就不喜欢这样的东西。因此实际上并没有哪种可以选作Web上通用的字节码。我们只能寄希望于某种理想的字节码,这样可选的就多了。

Zakai也列举了这样的字节码应该满足的一些条件:

  • 支持所有语言
  • 高速运行代码
  • 便于编译器生成
  • 格式紧凑,容易转换
  • 标准化
  • 平台独立
  • 安全

Zakai并没有给某种满足需求新的字节码很多机会,他认为JavaScript就是正确的选择:“参考上面列出的7个条件,可以说JavaScript所提供的东西已经非常接近字节码虚拟机了。”他也提到了JavaScript仍然存在的一些不足:

这方面JavaScript主要有两点不足。首先,这一点我们前面也有所提及,对有些语言的支持尚不成熟;其次,有些平台限制会影响性能,尤其是缺乏SIMD和共享状态的线程。

对于SIMD和内存可变的线程,JavaScript能弥补其问题吗?时间会说明一切,我认为这需要花很大精力,不过我相信,标准化JavaScript要比标准化一种全新的字节码简单几个数量级,而且更为现实,这是很明显的。这方面引入一种字节码没有任何优势。

Zakai又列举了创造通用虚拟机存在的更多困难,比如语言之间的类型冲突和垃圾收集问题等,之后他总结道:

因此,从技术角度讲,我认为考虑一种新的Web上的字节码没有多大好处。这种方法能带来的唯一明显的好处是,如果我们从头开始设计,没有历史包袱,或许会得到一个更优雅的解决方案。这种想法很吸引人,而且一般说来优雅的方案会带来更好的结果,但以前也争论过,在这一特定情况下,优雅的方案可能没有明显的技术优势,那就是为了优雅而优雅了。

尽管看上去通用字节码成功的机会并不大,但在将其他语言带向Web开发方面,仍然至少有两个重要的尝试。这些尝试都从C/C++开始,但相关工作很容易扩展至其他语言,而且有趣的是,它们都使用了LLVM:

  • Mozilla:C/C++ –> LLVM位码 –>Emscripten –> asm.js –> 浏览器
  • Google:C/C++ –> LLVM位码 –>PNaCl –> 浏览器

asm.js尝试标准化能够在任何浏览器中运行的一个JavaScript子集,其设计便于JavaScript引擎优化。Emscripten是另一个项目,可以从LLVM位码生成asm.js。据Zakai介绍,在Firefox中通过asm.js运行的C++代码速度是原生代码的50%,他们预计随着时间的推移,性能会有所改进。

Google最近宣布了PNaCl,InfoQ也进行了详细地报道。该项目支持在浏览器的沙盒中运行C/C++代码,据David Sehr介绍,其速度是原生代码的80-90%,而且还有改进空间。尽管性能比Mozilla的好得多,但这是有代价的:PnaCl已经开发了两年多了。有很多相当棘手的问题需要处理,比如多种架构上的大小端、指针大小和浮点数表示存在差异。改进Chrome使之包含asm.js优化则容易得多。但另一方面,asm.js可能会特别慢,就像yab**uz评论的那样

我决不会使用asm.js,仅仅是因为支持asm.js的浏览器太慢了。在最新的Core i7-3770K处理器上,Epic Citadel每秒才跑20帧,这就是个笑话,比Flash播放器还慢!

JavaScript是 Brendan Eich在1995年用10天时间设计的,本意是成为一种客户端脚本语言,以支持向那时的静态页面中注入一些动态性。或许当时没有人会预料到,在差不多20年后,尽管广受批评,缺点很多,这种小语言在今天竟然有了如此重要的地位。今天JavaScript广泛应用于所有主流浏览器的客户端,而且,尤其是随着Node.js的流行,它还进入了服务器端。这并不是因为JavaScript设计得好,而是因为我们很难把所有的主要参与者聚到一起做出一个更好的方案,软件上的各种东西也很难切换了。和HTTP和HTML一样,尽管存在各种缺点,尽管我们都知道如果能够达成一致,我们可以做得更好,JavaScript还是会走向繁荣。

既然我们在JavaScript上遇到了困难,那我们至少会有一种通用的Web字节码吗?我们真的需要吗?尝试在浏览器中运行其他语言编写的代码,比如用Mozilla asm.js或Google PnaCl,是否有吸引力呢?asm.js和PnaCl哪种方案更好?期待您的评论。

查看英文原文Debate: Do We Need a Universal Web Bytecode?

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的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通知我

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

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

讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT