江苏龙网

  1. 首页 > 资讯 > 科技 > >

InfoQ|WebAssembly如何演进成为“浏览器第二编程语言”？( 二 )


需要注意的是 ， 表单元的引用依据实际上会依赖于行号以及参数类型 ， 假设我们有如下的代码：
functiondoSomething(value){// performing some operations}constarr = [0,"String"];for(leti =0; i < arr.length; i++) {doSomething(arr[i])}由于数组 arr 中存在两种数据类型（Number/String） ， 当我们多次执行相关代码时 ， doSomething函数会被 JIT（Just-In-Time）引擎创建并编译出两个不同类型的机器码执行代码版本 ， 并且使用不同的表单元引用 。 当然 ， 由于机器码执行代码的创建和编译存在代价 ， 因此不同的 JIT（Just-In-Time）引擎会有不同的优化策略 。 如果部分代码执行得异常频繁 ， 那么自然的这部分解释执行的代码会被发送给优化编译器（Optimising Compiler）进行更高程度的优化 ， 从而创建并编译出相比 warm 阶段更高效的机器码执行代码版本 。
与此同时 ， 在创建这些高度优化的机器码执行代码期间 ， 编译器将会严格限制执行代码的适用类型（比如仅适用于 Number/String 或某些特定类型参数） ， 并且在每次调用执行前都会检查参数类型 。 如果匹配则使用这些高度优化的机器码执行代码 ， 否则将会回退到 warm 阶段生成的机器码执行代码或是直接解释执行 。
JavaScript 有了 JIT（Just-In-Time）后就能高枕无忧了么？不尽然 。 从上面的介绍中我们可以看到 ， JIT（Just-In-Time）引擎的优化并非是完全无代价的 。 同时由于 JavaScript 自身的灵活性 ， 如果我们编写 JavaScript 代码时并没有将数据类型严格固定 ， 那么 JIT（Just-In-Time）的效果将会大打折扣 。 在 Google V8 团队的 《JIT-less V8》 文章中我们可以看到 ， 使用 JIT-less 模式的 V8 在运行 Youtube 的 Living Room 页面时 ， 其测试成绩与使用 JIT 的 V8 实际差距仅为 6% 。 这个测试侧面反应了 JIT 在生产中并不是完全的“性能银弹” 。
InfoQ|WebAssembly如何演进成为“浏览器第二编程语言”？
本文插图

JIT-less 模式下 V8 与基线的对比那么 JavaScript 能变得更快吗？还是说我们需要其他技术来解决 JavaScript 的性能问题？此时 NaCl 和 PNaCl 应运而生 。
NaCl 与 PNaCl尽管 JavaScript 由于 JIT 的加入在性能上有了很大的提升 ， 但在许多性能敏感的领域 ， JavaScript 仍旧无法满足需求 。 因此在 2008 年 ， Google 的 Brad Chen、Bennet Yee 以及 David Sehr 开源了 NaCl 技术 ， 2009 年 ， NaCl 技术正式达到生产可用状态 。 NaCl 全称为“Native Client” ， 其由 C/C++ 语言编写并定义了一套 Native Code 的安全子集（SFI 技术) ， 同时执行于自己独立的沙盒环境之中 ， 以防止安全性未知的 C/C++ 代码对操作系统本身产生危害 。
NaCl 应用及其模块在性能上与原生应用的差距非常小 ， 但由于 NaCl 与 CPU 架构强关联且不具有可移植性 ， 需要针对不同的平台进行开发和编译 ， 导致开发者无法自由分发 NaCl 应用及模块 。 为了解决这个问题 ， NaCl 改进技术 PNaCl 出现了 。
InfoQ|WebAssembly如何演进成为“浏览器第二编程语言”？
本文插图

NaCl 的性能损耗极小PNaCl 的全称为"Portable Native Client" ， 其通过替换 Native Code 为 LLVM IR 子集并在客户端编译为 NaCl 的方式解决了 NaCl 的分发问题 。 PNaCl 不依赖于特定的 CPU 架构 ， 更易于被部署和使用 ， “一次编译 ， 到处运行”在 PNaCl 上得到了实现 。 但同样的 ， PNaCl 也是运行在自己的独立沙盒之中 ， 其无法直接的访问 Web APIs ， 而是需要通过一个名为“PPAPI”的接口来与 JavaScript 通信 。


推荐阅读


上一篇：|华为8月19日发布MateBook X：主打轻薄设计

下一篇：|Galaxy Note20 Ultra将采用NXP UWB技术，定位更精准