“AI 技术+人才”如何成为企业增长新引擎?戳此了解>>> 了解详情
写点什么

WebAssembly 2021 年回顾与 2022 年展望

  • 2022-02-07
  • 本文字数:5005 字

    阅读完需:约 16 分钟

WebAssembly 2021 年回顾与 2022 年展望

本文最初发布于 Uno 平台的博客。


和去年(去年作者写了 WebAssembly 2020 年发展和 2021 年预测)一样,本文将先回顾下 WebAssembly 过去一年的发展,然后预测下其未来一年的趋势。

回顾 2021


过去一年 WebAssembly 的发展远比我之前预测的要快很多,Safari web 浏览器这方面尤为突出。

Safari 浏览器


在 2017 年 WebAssembly 刚刚发布 MVP 版本的时候,Safari 还和其他浏览器一样处在相同水平线上。然后经过多年的发展,Safari 很不幸被甩在了后面。


时间来到 2021 年,看到 Safari 不断发布对 WebAssembly 支持的更新,我感到兴奋不已。这或许是 Safari 赶超其他厂商的开始。随着 2021 年 12 月 14 日 Safari 15.2 版本的发布,2021 年全年 Safari 更新发布了如下功能特性:


  1. 流编译

  2. 大内存操作

  3. 可寻址内存达到 4GB

  4. 异常处理

  5. 支持 COOP 和 COEP 的响应头

  6. 原子指令

  7. 对于使用了 COOP/COEP 响应头的网站重新开启对共享缓存区的支持

共享缓存区


借助共享缓存区,WebAssembly 可以在多线程之间实现内存共享。不过可惜的是,由于共享缓存区目前存在 Spectre 和 Meltdown 安全漏洞,因此在人们找到合适的漏洞解决方案之前,共享缓存区是被禁用的。


Chrome 桌面应用是第一个通过采用站点隔离作为漏洞解决方案来重新启用共享缓存区的。至此之后,在响应头添加 COOP 或 COEP,就意味着是告诉浏览器需要创建一个隔离的环境,以便安全地重新启用共享缓存区。


Firefox 桌面应用则是在 2020 年首次通过在响应头中添加这些响应头来重新启用共享缓存区。到了 2021 年初的时候,Chrome 桌面应用将对共享缓存区的支持更新到了最新标准。此后,如果你想使用共享缓存区功能,就必须添加这些响应头了。


同时,Chrome 的安卓端也在 2021 年初宣布对这些响应头的支持,使得在移动端使用 WebAssembly 的多线程成为可能。随着 Safari 最新版本重新开启对共享缓存区的支持后,除了 Firefox 移动端之外,所有的现代浏览器都支持了 WebAssembly 的多线程。


我本来预计 Firefox 移动端会在 2021 年支持这些响应头,不过可惜并没有发生。不过在 2022 年 Firefox 移动端极有可能完成对这些响应头的支持。

固定宽度 SIMD


SIMD 是将相同的指令同时作用在数据的多个节点上,通过这种方式可以大幅提高计算性能。例如,通过利用 CPU 的 SIMD 指令的优势,可以大幅提高图片处理能力。


SIMD 有很多种类型,作为一个开始,WebAssembly 决定先支持 128 位固定宽度 SIMD 操作。


Chrome 和 Firefox 分别在 2021 年 5 月和 6 月增加了对固定宽度 SIMD 的支持,不过目前 Safari 还未支持。

异常处理


直到现在,WebAssembly 还没有内置的异常处理模块,为了弥补这个空缺,应用不得不使用 JavaScript 来增加额外的异常处理代码。然而,当将这些异常处理的逻辑代码构建到模块内部后,不但会使模块体积变大而且还会影响性能。所以,通常建议非必需就不要在模块中使用异常处理。


Chrome 在 9 月份正式发布了异常处理,不过,令我惊讶的是,Safari 也在 12 月份实现了异常处理功能并且决定在 15.2 版本中正式对外发布。


目前 Firefox 和 Node.js 还不支持,他们还在努力开发中。


根据 V8 (Chrome 和 Node.js 的 JavaScript 引擎)的发布说明显示,使用 WebAssembly 的异常处理比使用 JavaScript 的异常处理代码大小下降了 43%,与不使用任何异常处理相比代码大小增加了 9%。与此同时,WebAssembly 的异常处理对性能无影响,而 JavaScript 的异常处理则会对性能产生 30% 的负面影响。


如果对 V8 版本中针对 WebAssembly 异常处理的详细信息感兴趣的话,可以查看 V8 版本发布说明:https://v8.dev/blog/v8-release-95#webassembly

模块链接和接口类型


模块链接提案是关于在两个或多个模块定义之间建立链接,且让 WebAssembly 运行时在运行期间为你处理这种链接的过程。


接口类型提案描述的是模块相互之间如何通过高级的数据类型定义实现相互之间的通信。例如,一个模块可能使用 UTF-8 字符串,而另一个模块可能使用 UTF-16 字符串,通过描述它们的数据类型,WebAssembly 运行时就会更加容易实现模块间的通信。


我原先预计这两项提案会在 2021 年完成,目前看来,虽然取得了一些阶段性的成果,但未来仍然需要继续发力。

.NET 6


过于的一年里,为了进一步提高对 WebAssembly 的支持,不管是在工具方面还是性能方面,.NET 都做了很多努力。在 11 月份 6 版本中发布的 AOT 编译功能就是其中之一。


通常.NET 代码的编译分两步,首先将本地代码编译为 IL(.NET 架构中的中间语言),然后在部署的目标机器上,通过目标机器的即时编译完成剩下的编译。这个过程其实和 WebAssembly 的工作机制有点类似。


当这种编译机制的代码运行在客户端浏览器的时候,WebAssembly 代码就是.NET WebAssembly 运行时本身,而应用的代码则全是 IL 文件。这种按需编译执行 IL 文件的方式在性能上无法和直接执行已编译文件的方式相提并论。


在 AOT 编译方式中,应用的.NET 代码将全部被编译为 WebAssembly。这种方式虽然增加了文件的大小,但却获得了更好的性能,不过,大文件会导致应用的首次加载时间过长。


考虑到 IL 和 AOT 两种不同编译方式的优劣,使用配置导向的 AOT 编译或许是最佳选择。通过这种方式,我们可以将频繁使用的代码通过 AOT 进行编译,而剩下的部分则采用 IL 的编译方式。


除此之外,我们的 Uno 平台还引入了一个名为 XAML 资源修剪的功能。它可以与 AOT 编译一起删除那些未使用的代码。人们在测试中发现,通过这种方式可以使 WebAssembly 应用程序的代码减少 50%。

字节代码联盟


字节码联盟最初是由英特尔、Mozilla、红帽和 Fastly 组成的一个组织,其目标是通过利用 WebAssembly 和 WASI 等标准,构建一个可以在任何平台、设备或操作系统上运行不可信代码的安全平台。


WASI(WebAssembly 系统接口)是如何在浏览器之外的场景安全且一致的使用 WebAssembly 的标准。如果你想了解更多相关信息,Lin Clark 写了一篇很好的文章来解释 WASI: WASI-WebAssembly 系统接口标准:https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/


联盟从一开始就希望更多的组织加入,为此组织内部的架构必须做相对应的调整,才可以满足组织未来的发展和壮大。在创建基金会的时候,红帽公司退出,微软加入且帮助其他创始人将该组织合并为一个非营利性组织。2021 年,联盟得以扩大,现在组织成员包括了微软、谷歌、Arm、DFINITY 基金会、普莱普工作室、Shopify 和加州大学圣地亚哥分校。


除了支持 WASI,该联盟也是 Wasmtime、cranlift、Lucet、WAMR 和 Enarx 等项目的来源。如果你对字节码联盟感兴趣,可以通过链接获取更多信息:https://bytecodealliance.org/

WebAssembly 应用领域


每年我们都看到越来越多的商业产品增加了对 WebAssembly 的支持。例如,在 2020 年,Zoom、谷歌 Meet、谷歌 Earth 和 Firefox 浏览器都加入了诸如 Cloudflare Workers 等基于 WebAssembly 的无服务计算产品竞的争行列。除此之外,还有 eBay 的条形码扫描仪、AutoCAD 的 web 应用程序以及 Unity 游戏引擎。


2021 年也不例外,下面是一些运用 WebAssembly 的新领域:


  1. Disney+ 应用程序开发工具包使用 WebAssembly

  2. 网页上发布了一个简化版的 Photoshop

  3. 微软的飞行模拟器有一个基于 webassembly 的插件系统


随着功能和工具的改进,以及越来越多的商业产品使用 WebAssembly,我们开始看到 WebAssembly 在框架和常规 Web 上的应用。虽然应用的领域和产品还是很少,但是他的持续增长是令人兴奋的。


2021 年对 WebAssembly 来说是伟大的一年,那么我们对 2022 年有什么期待呢?

预测 2022


我认为 2022 年一定会发生的事情是,WebAssembly 在几乎所有领域的功能会得到进一步的增强和改善。这其中我最期待的是异常处理。

异常处理


异常处理是许多编程语言必要的一个主要特性,因此它位于待办事项列表的前列。Safari、Chrome 和 Edge 已经具备了此功能,并且 Firefox 和 Node.js 也在积极开发中。


由于低性能的 JavaScript 版本依然还能继续使用,因此当你的模块中需要用到异常处理的时候,如果可以使用性能更好的 WebAssembly 异常处理那么就升级使用,否则就回退到使用 JavaScript 异常处理的版本。

共享缓存区


正如前面提到的,包括 Firefox 桌面在内,几乎所有现代的桌面端和移动浏览器现在都支持了 COOP/COEP 响应头。这些响应头允许浏览器安全地启用共享缓存区,从而允许你的模块使用 WebAssembly 多线程。


在现代浏览器中,现在只剩下 Firefox 移动端不支持这些响应头,不过 Firefox 移动端已经规划在 2022 年 2 月发布的 97 版本中支持这些响应头。

固定宽度 SIMD


我预测此功能将在今年的 Safari 版本中实现。


我的理由是,Safari 在 2021 年增加了对 WebAssembly 的支持,WebAssembly 固定宽度 SIMD 规范现在已经标准化,而且 Xcode(苹果的操作系统开发环境) 也已经支持了 SIMD。

尾部调用


为了支持 WebAssembly,一些编程语言不得不运用尾部调用,虽然很多事情都可以有变通的路径,但其过程缓慢。除此之外,尾部调用在编译优化和流程控制上也是有积极的作用。该提案已经完成一段时间了,但至如果想要进入到第四阶段,就必须至少有 2 个厂商(Chrome、Firefox 或 Safari)实现此功能。Chrome 已经在一个版本标签中实现了此功能,但在它达到第四阶段之前 Chrome 并不打算正式发布它。所以我们仍然必须等待至少再多一个厂商实现此功能。


并非各厂商不想实现此功能,而是他们都为各自认为更重要的事情而忙碌。因此人们正试图提高此功能在各个厂商眼中的重要性和优先级。

支持多内存


此提案是使模块拥有多个内存模块。


多内存的一个使用场景是,模块将一个内存区域作为自己的内部数据区域使用,将另外一个内存区域传递给某些需要写入数据的模块使用。通过此方式,你可以防止模块内部数据因为外部模块的异常写入而发生错误。同时这种方式还可以很好的隔离敏感数据和共享数据,起到一定的安全作用。


另一个多内存的使用场景是,在 WebAssembly 的多线程中,你可以让这些线程有一个共享的内存区域,同时将其他的模块数据保存到另外一个内存区域中。


如果你对多内存区域的使用场景感兴趣,可以查看多内存介绍(https://github.com/WebAssembly/multi-memory/blob/main/proposals/multi-memory/Overview.md)来了解更多使用场景。


目前此提案已经到了第三阶段,同时还有很多引人注目的应用场景。所以我特别希望它在今年能正式发布。

WASI(WebAssembly 系统接口)


在本文的前面提到,我预期模块链接和接口类型两个提案会在 2021 年完成。不过可惜,它们目前依然还在推进中,并没有像我的预期那样在 2021 年完成。


这些建议不仅仅是 WebAssembly 的一部分,它们还是创建组件模型必不可少的功能。根据此 WASI 的帮助文档描述,组件模型和操作系统的进程模型类似,都是用来定义进程是如何启动以及相互之间通信的。WASI 的在这里扮演的角色就类似操作系统的 API 层。


所以,2022 年组件模型和 WASI 的接口类型提案都将持续发展。如果你对 WASI 的提案感兴趣,可以通过 WASI 提案列表(https://github.com/WebAssembly/WASI/blob/main/docs/Proposals.md)查看更多。

总结


过去的一年里,在提高 WebAssembly 性能方面,我们看到了 WebAssembly 多线程的共享缓冲区、固定宽度 SIMD 和异常处理等特性。同时,.NET6 中提高了对 WebAssembly 的支持,并且.NET 和 Uno 平台都通过增加 AOT,进一步提高 WebAssembly 的性能。


Safari 在 2021 年是一个大惊喜,他们在追赶其他浏览器的 WebAssembly 支持上做了很多工作。

在 2021 年,我们看到更多的商业产品加入了使用 WebAssembly 的行列,同时,WebAssembly 也开始在大众网络上得到应用。


如此看来,2022 年必将会是 WebAssembly 发展的又一个好年份,因为那些现在还不支持的功能特性,很有可能在 2022 最终正式发布且投入生产。


针对 WebAssembly 本身有非常多有趣的功能提案,同时字节码联盟也将继续助力 WebAssembly 在浏览器以为场景的落地和功能升级。


如果你对 WebAssembly 功能支持的发展路径有兴趣的话,可以通过下面的网站进行了解。第一列显示的是特性列表:WebAssembly 功能特性 RoadMap(https://webassembly.org/roadmap/)。


感谢特邀嘉宾 Gerard Gallant,他是“WebAssembly in Action”一书的作者,也是一名高级软件开发人员,他写了另一篇关于 WebAssembly 当前和未来状态的综合文章。


原文地址:


https://platform.uno/blog/the-state-of-webassembly-2021-and-2022/

2022-02-07 16:0511676

评论

发布
暂无评论
发现更多内容

AI人脸编辑让Lena微笑

逝缘~

华为云 AI Gallery 7月月更

Nginx 主机配置文件中如何配置能够支持 IPv4 和 IPv6

HoneyMoose

【LeetCode】 解密消息Java题解

Albert

LeetCode 7月月更

ServiceMesh主要解决的三大痛点

阿泽🧸

Service Mesh 7月月更

谈谈讲清楚这件事的重要性

阿里巴巴中间件

阿里云 技术 云原生

【愚公系列】2022年7月 Go教学课程 005-变量

愚公搬代码

7月月更

async / await

Jason199

Async await 7月月更

想要在Linux中只显示隐藏文件,用对ls就可以实现

wljslmz

Linux 运维 7月月更

自律,提升自制力原来也有方法

沃德

程序员 7月月更

抖音或将推出独立种草社区平台:会不会成为第二个小红书

石头IT视角

牛客java选择题每日打卡Day8

京与旧铺

7月月更

一个酷酷的“幽灵”控制台工具

为自己带盐

C# 控制台 7月月更

当我们谈论不可变基础设施时,我们在谈论什么

阿里巴巴中间件

阿里云 容器 云原生 托管

Ubuntu22.04 源码安装Python3.10

IT蜗壳-Tango

7月月更

全链路压测:影子库与影子表之争

阿里巴巴中间件

阿里云 云原生 全链路压测 影子

OpenSergo 即将发布 v1alpha1,丰富全链路异构架构的服务治理能力

阿里巴巴中间件

阿里云 微服务 云原生 云原生开源 OpenSergo

当 Knative 遇见 WebAssembly

阿里巴巴中间件

阿里云 容器 云原生 Knative WebAssenbly

算法入门很简单:算法题的破解之道上篇

宇宙之一粟

算法 7月月更

Java 9 中的字符串(String)压缩的改进

HoneyMoose

架构实战营模块 6 作业

Roy

架构实战营

offer如何选择该考虑哪些因素

KEY.L

7月月更

鸿蒙智联汽车【1.0】

坚果

HarmonyOS OpenHarmony 7月月更

一个开发者自述:我是如何设计针对冷热读写场景的 RocketMQ 存储系统

阿里巴巴中间件

阿里云 RocketMQ 云原生编程挑战赛

Android 面试知识点

沃德

android 程序员 7月月更

Qt 实现容器的DELETE的方式

小肉球

qt 7月月更

Salesforce 容器化 ISV 场景下的软件供应链安全落地实践

阿里巴巴中间件

阿里云 容器 云原生 安全

LinkedBlockingQueue源码分析-初始化

zarmnosaj

7月月更

windows下设置TortoiseGit客户端连接git不用每次输入用户名和密码

乌龟哥哥

7月月更

组织实战攻防演练的5个阶段

穿过生命散发芬芳

攻防演练 7月月更

【问道】编译原理解析

小明Java问道之路

编译原理 编译器 汇编语言 7月月更 Graal编译器

《HarmonyOS实战—入门到开发,浅析原子化服务》

攻城狮杰森

操作系统 HarmonyOS 7月月更

WebAssembly 2021 年回顾与 2022 年展望_大前端_Uno平台团队_InfoQ精选文章