顾轶灵: W3C Web中文兴趣组侧重识别来自国内社区的技术要点及标准需求，提供一个加强中国Web社区对Web标准工作的参与的平台。兴趣组目前有来自16个组织的成员参与，去年我们举办了小程序/快应用和媒体的话题研讨会，之后成立了相应的社区组来进一步孵化技术提案和标准化思路。
今天我们有6位来自不同组织的讲者与大家分享WebAssembly当下应用及实现，同时欢迎各位参加本次会议。提示：请大家修改自己的参会名称为姓名+公司名称，需要提问时请在聊天频道中输入q+。今天共计6个议题，每个议题半小时，含20分钟报告及10分钟讨论。下面开始第一个议题分享：
赵磊（中国移动咪咕）: 我叫赵磊，来自中国移动咪咕前端开发。
首先给大家分享一个图，自从JS创建到现在，每10年都会有新的变化，我们会想到下一个10年的爆点在哪，我们浏览器的优化速度跟不上技术的更迭，JS具有解析、编译执行、垃圾回收等步骤，所以有没有更多的优化可能？
WASM将是一个优化的方式，WASM是一个可移植的，WASM为什么可以更快，与JS相比有什么特别，我们通过图片可以看到，WA是直接编译的，没有GC，紧凑的二进制，解码更快， 更为接近机器吗，高度优化，已经有静态类型校验WASM 的生成，有WAT， WAT是WASM汇编生成格式，我们来看看通过WAT生成WASM，如slide所示，JS调用如slide所示。同时slide中还有一个汇编的WAT样例供大家参考，汇编效率比较低，我们会用一些工具，如assemblyscript， 如slide中例子，会相对比较方便调试，大家可以去官网了解更多。
Golang一般用于服务端开发，或者worker的开发，可以直接简单的调用，syscall.js，比较类似的使用方式，如slide所示，目前有些游戏也在使用
Emscripten在生产中使用较多，使用简单，通过emcc进行编译，然后生产main.js，如slide所示，我们只需要通过module进行调用，可以直接对参数进行传递。可以简单方便的帮我们实现代码。
MD5 一般多用于文件上传等，在md5中，我们使用了openssl的库， 因为openssl是x86的，所以我们对openssl重新编译，md5输入和输出的都是指针，记得free，防止内存泄漏。
这里有一个简单MD 5的benchmark，在字符串长度在128bytes内时， JS表现的更优秀，大于128后WASM的表现会越来越好，优于JS，wasm前期慢的原因可能是指针等的损耗，所以wasm适用于大的数据量。
一个机遇WASM的人脸识别demo展望WASM的未来，浏览器的多线程支持，更完善SIMD指令的支持，ES6模块等。谢谢大家！
欧波同（UCLA）: 人脸识别的程序是在浏览器上执行的吗？
赵磊（咪咕）: 我们都是在浏览器端离线
欧波同（UCLA）: 怎么确保wasm有权限去访问摄像头？
赵磊（咪咕）: 人脸识别的代码编译称wasm二进制，直接导入
欧波同（UCLA）: 是不会做检查吗？
赵磊（咪咕）: 目前是一个沙箱
欧波同（UCLA）: 目前是访问OS的权限
赵磊（咪咕）: 我们是通过RTC，这是个流，这些都是浏览器来控制的，在调用的时候也会检查接口。
林作健（阿里巴巴）: 现在用go能够支持gc吗?
赵磊（咪咕）: wasm本身是不支持gc，go里边能不能模拟我也不清楚。
高纯（Agora）: 人脸识别用的机器学习框架是什么？
赵磊（咪咕）: pyTorch
朱金鹏（华为）: 能不能详细解释一下MD 5加密
赵磊（咪咕）: 如ppt所示: MD5 加密，MD5返回值为32为，通过malloc申请空间，ptr则为数值型，这样我们得到一个typearray的指针，然后直接进行传递，malloc在wasm里申请空间。
陈嘉恺（北京复方科技）: 因为可以用C转wasm，那么在c中产生的内存泄漏，如果在wasm里恶意内存溢出的话会有安全问题吗？
赵磊（咪咕）: wasm是个沙箱，所以不会有缓存溢出的问题，但是内存泄露确实存在
吴龙（网易）: 各种开源库，在选择开源库的时候，哪些点需要关注？
赵磊（咪咕）: 不是所有库都适用不同场景，wasm对多线程支持不够好，有些还不支持，有时我们会编译openGL为WebGL，但是有时还不如直接用，WebGL，所以在选择的时候应该注重他们的特性，同时UI也是需要考虑。
高纯（Agora）:推理预测用的什么模型？
赵磊（咪咕）: 这个属于我们AI模型组，听说都是用的C++，只知道训练的时候用的是pyTorch
于航（PayPal）: 议程中有很多深入技术的话题，所以我想讲一下应用场景。我是于航，很早就关注WASM，著有一本书《深入浅出 WASM》。
总结了排名前10的领域，如ppt所示：新型语言，多媒体，仿真器，Web前端框架， 库，编译器，虚拟机，云，游戏引擎，工具等，
新兴语言，机遇WASM开发的语言：Walt 如slide，用于WASM的语言，比WAT更抽象一层；Astro多范式的语言，可以用于WASM，所以有两类语言，语言抽象专注于WASM，还有一种@@
多媒体是典型的场景，比如GlitchBitch用于图谱制作的，举个例子，squoosh在线图片处理，会发现图片处理的速度还是很快的，动态流媒体，和在线静态图片处理，是两个比较突出的处理方向
仿真器：关键点是如何编译和处理数据，举个例子，如gomeboycolor，如slide所示，使用canvas来处理，分为浏览器和worker两部分，module会放在worker中运行，体现了WASM一个很重要的方向，更安全，可移植，可复用。
Web前端框架，没有看到WASM和常用的react，vue等的联系，一般都是构建框架，如用rust构建等，目前我们能做的还有线，很多都缺少人做，如像react方向去靠，我目前正在做一些工作，
所以目前来看，没有一些直接的时间结合js和wasm库，列出了集中常用的库，如GLMW，这里有一个比较重要的tensorflow，WASM可以提高到20倍以上的速度
编译器，这个是WASM实践方向最多的一个，如slide，大家可以了解一下slide上个人所做的一些编译器
虚拟机，slide中列出了一些个人觉得比较好用的，可以用在不同领域，如ssvm更多的用在ai和blockchain，WASM3可以用作高性能的解释器，重点想介绍一下wasmer，带有包管理能力的wasm虚拟机, wasemer社区比较完善，活跃
Demo of wasmer
云，简单介绍一下这一块，重点介绍一下waSCC，是一个运用框架，有底层的交互协议等，可以作为一个云端的service，内部会用一个actor module，同时会列出module的capabilities，这也是保证wasm安全的重要部分，将会分享一个链接。
游戏引擎，最初是Unity和unreal engine支持移植，
工具，主要介绍WABT，可以看到WASM内部信息，支持WAT和WASM互相转换，WASM转换成C语言等，binaryen也是常用的一个。
杨建东（华为）: WASM不仅用于Web还用于其他语言，我们想通过WASM把其他语言和C++通讯起来，有没有相应的实践？比如可以从C++看到swift的类。目前内存布局指针等不同。
于航（PayPal）: 有一个interface time的提案，可以映射到WASM，社区目前用WASM来重写了一些库，目前支持C的一些库，对于多种函数调用我们可以私下继续聊一下。
杨建东（华为）: 对线程的以来，那个虚拟机比较好？
于航（PayPal）: wasmtime目前支持比较好
杨建东（华为）: 有什么数据可以分享吗？
于航（PayPal）: 暂时还没有，目前的优先级较高的需求是实现标准，咱们没有稳定的vm数据
王鑫（Intel）: AUTOCAD的wasm版本已经对外可用了吗？
于航（PayPal）: 尝试了一下，和native相比功能少了一部分，相当于一个lighten版本，具体的可用性还需要探究
吴忠敏（英特尔）: 有没有什么社区推动底层生态的建设？
于航（PayPal）: 暂时是没有的，与framework相关的与各个领域相关，目前两个梯队，一个专注于Web相关，一个关于@@，可以自己先去试一下。
朱金鹏（华为）: ios和安卓的应用？native的应用？
于航（PayPal）: 还没有统计，很少见到。
高裕轩（bilibili）: 大家好，我是来自 Bilibili 的高裕轩，今天想跟大家分享的内容是 WebAssembly 在多媒体场景的一些实践和思考。
在座的各位对 Bilibili 都应该有所耳闻，今天的话题主要围绕 Bilibili 视频投稿 场景展开。这也是让普通 B 站用户成为 up 主的第一步。
这是 Bilibili 的视频投稿页面，用户可以首先选择本地文件上传，在上传文件的同时，用户还需要填写部分信息：如选择封面图。我们会根据视频内容截取部分画面，经过筛选推荐给用户作为可选项。去年我们尝试对这个投稿页面进行优化，在此过程中遇到两个问题，一是用户选择的本地文件可能就存在问题，如文件可能扩展名是mp4，但它本身不是视频文件。或者文件的部分内容损坏无法解码，如文件内部不存在有效的视频轨道。这些情况下文件无法成为视频投稿。还有对互动视频，为了文件效果统一，我们可能对分辨率进行限制。之前，这些问题的检测可能要等到用户文件上传结束后才能进行。这样的话用户可能在操作完毕以后接到私信才知道有问题。所以他只能重新投稿，对用户来说，他没有得到及时的反馈。对我们来说，云端资源也被白白浪费了。如果可以的话，我们希望能将检测逻辑尽量前置。
第二个问题是关于视频的推荐封面。这些封面其实是对文件进行智能截图，然后对截图进行打分才能呈现给用户的。因为云端处理同样要在文件上传完成后才能进行，而且用户还需要在页面中填写其它信息，这就导致用户在提交前看不到推荐的封面。我们希望找到办法尽快地生成这些封面。
之前的所有逻辑操作都是在云端进行，导致上次完成才能进行视频处理。我们就思考能不能把这些处理提前到浏览器进行。这些我们能尽快对文件进行检测和拦截。对于有问题的文件，用户能得到及时的反馈。我们云端资源也不会白白浪费。如果能在上传过程对视频进行截图打分，我们能更早地展示截图封面，给我们的云端分摊计算压力。
在前端方面，浏览器只能处理有限的视频格式。我们希望浏览器能处理更多不同的格式，而且能分析多媒体的信息，进行一些实际的解码操作。如果跳出传统前端领域，我们可以使用像FFMPEG这样C语言库进行预处理。如果能在浏览器使用C语言工具库，我们就能比较好地解决上述的问题。在这样的背景下，我们开始考虑引入 WebAssembly 技术，可以把其它语言的工具库编译到浏览器中运行。因为像 Chrome 它的实现中也会借助 FFMPEG 这样的工具库做解码和播放，多媒体场景在c语言生态中相对成熟。我们也了解到2017年前后，WebAssembly 的 MVP 版本陆续得到主流浏览器的支持，从 C 或 C++ 编译到 WebAssembly 也有官方提供的比较成熟的工具链。我们就有了很大的把握尝试用 WebAssembly 解决我们遇到的问题。
工具库的选择就是刚刚提到的 FFMPEG，它是多媒体生态中使用非常广泛的一个工具库。可以为我们提供封装、解封装、音视频编解码还有视频滤镜等等的一系列功能。FFMPEG 有几个比较核心的工具库，比如多媒体的封装格式操作、codec库可以对多媒体进行编解码、还有库可以添加滤镜效果，我们需要把这些方法编译成一个 WebAssembly 的版本，最终在浏览器中使用它。
在实际编译中，我们会把FFMPEG和其它一些C以来库进行编译，然后生成archive文件，为了方便代码转换我们还会在C与JS的胶水代码中添加一些参数转换的逻辑。
【文件检测代码示例】
检测和拦截前需要获得多媒体文件的信息，见左边的流程图。遍历文件中的流拿到流的编码信息和源信息，如分辨率时长和旋转角度等。右边是js调用时的输出结果，用于拦截判断。
实际调用中，避免阻塞主线程， WASM通常运行在独立的 worker 中，需要和主线程不断通信进行数据交换。
具体通信方式有以下几种：
transable对象，传递比较大的arraybuffer；
分析文件，需要用到Emscripten的文件调用和workerfs，类似filefilter API，支持文件分片读取，保障大文件处理；
对文件结果持久化保存，会使用到IndexedDB；
理想的是使用sharedarraybuffer，满足主线程和worker之间的数据共享，也可以满足多个worker之间的数据共享，但因为某些问题被禁用了一段时间，支持度不太理想，没有直接使用与生产，但长远来说很有潜力。
生成推荐封面，使用两个worker并行处理任务，WASM worker 进行截图，生成压缩过的缩略图，每个视频最多生成30张缩略图，然后传递给 tensorflow worker打分，截图和打分用流水线的方式并行处理。每生成一张截图马上进行打分，全部完毕后挑选得分最高的9张图，再用 WASM 生成清晰截图，并展示给用户选择。
WASM 文件体积需要压缩，如果直接执行FFMPEG体积大概会有50M，需要去除暂时使用不到的文件功能去减少文件体积。
经过实验，基础功能可以压缩到26M左右。核心是缩减decoder的数量。经过数据分析，选取了20多种decoder，文件体积下降到5M左右。通过GZip传输实际体积还会更小。
性能方便，我们进行了比较多的测试，一方面需要验证 WASM 文件执行结果的准确性，也需要保证执行时间在接受范围以内，文件信息检测，随机选取500个多媒体文件，单文件平均耗时40ms左右，和云端结果一致。
生产推荐封面耗时大概1.2秒，总的来说生成最终清晰文件不超过3秒，大大提前了展示时间。
总而言之，WASM允许我们本地完成很多以前只能云端进行的任务，拓展了前端能力，给用户带来性能便利。
除了刚刚提到的投稿场景，我们也把WASM用于其它的多媒体场景，如这个图像预处理例子，需要对图片内容进行计算、分割。
我们也尝试过使用 WASM 处理音频数据，配合 webaudio api 对音频进行调音，改变音高和播放速率，为音频添加声音效果。
同时我们也在尝试云剪辑功能，在浏览器里直接进行音视频编辑。我们相信在多媒体处理上浏览器会给我们带来更多的可能。
一些思考，WASM在现阶段实践中更多的用于多媒体编解码，希望未来为开发者提供更多的API以拓展浏览器的能力，支持多格式多媒体文件的播放处理。社区中有不少讨论，如webcodecs提案，雏形阶段， 不知道W3C有没有相关的标准考虑。希望能直接用WASM创建worker，现在还是需要胶水代码实例化WASM文件，希望未来能更直接一点，如把WASM作为ES Module来使用，希望这个提案被支持后可以拓展更多WASM的使用场景。
谢谢大家。
王鑫-Intel: 你们有没有感受到WASM在不同的平台上有速度差异？
高裕轩（bilibili）: 不同平台， 对我们来说是不同的浏览器，性能并不是我们现阶段最核心关注的指标。我们目标是希望能提前进行一些计算。我们的确能观察到一些数据差异，但波动不是特别大，机器本身、CPU能力影响较大。
沈泽堃-腾讯: 云剪辑用 WASM 怎么做到精确剪辑？直接进行重编码还是只是 copy 一下流？
高裕轩（bilibili）: 细节可以会后讨论，里面用到了一些 FFMPEG 的方法。我们有一些预转码的过程。
赵磊-中移动咪咕: IndexedDB在视频处理的主要使用场景是什么？
高裕轩（bilibili）: 对生成截图的逻辑，部分截图需要持久化，就直接塞进 IndexedDB里。
赵磊-中移动咪咕: 假如用户上传的视频非常大，workersFS在这种场景怎么进行辅助？生成多个worker然后分chunk读取吗？
高裕轩（bilibili）: 这里的workersFS是Emscripten本身提供的一种文件读取系统，默认选项的文件系统会把文件都读进memory里面。workersFS只是一种接口选项，背后的实现还是filereader API，通过Emscripten暴露到 WASM 里，WASM 只要进行标准的文件IO操作就是默认在做分片处理。不会把所有文件都一口气读进内存。FFMPEG本身就是在对文件流进行处理。
谭志杰-北邮: 把一个大型c++项目编译后，我们现在也涉及到一些 worker 和文件读取的功能，但是很困惑开发中有没有一些调试技巧？假如有成千上万行的C++项目怎么调试？
高裕轩（bilibili）: 我们也很头疼，先log到浏览器里，Emscripten 有提供部分调试接口，但我们通常还是会进行一些log，也有方法进行断点，但效果不太明显
谭志杰-北邮: 怎么观察内存消耗情况？它没有垃圾回收机制，内存很容易泄漏。
高裕轩（bilibili）: 浏览器的application里可以看到整体内存使用情况，GC 方面用完一定要记得 free 掉。Emscripten 里一定要注意文件清理。
吴龙-网易: WASM 和 MSE 的结合方面有什么代码库推荐？
高裕轩（bilibili）: 目前最常见的场景是播放器，直播或点播，借助 WASM 进行解码，生成sourcebuffer提供给MSE使用。
吴龙-网易: 刚刚提到的技术方案在移动端有实践性的分析吗？
高裕轩（bilibili）: 暂时都是在PC端。
吕烨鑫-百度: 这边也是把视频解码后在 WebGL 里面做渲染的吗？高清视频会出现卡死的情况吗？
高裕轩（bilibili）: 放进浏览器的时候我们会对视频的分辨率进行压缩，从而避免这些问题。不适合直接对 2k 或 4k 视频进行处理。先压缩，在渲染阶段才用 2k 或 4k 格式进行输出。
吕烨鑫-百度: 压缩是哪一部分去做的？
高裕轩（bilibili）: 也是 WASM，提供分辨率比较小的一帧，给前端渲染到canvas里。压缩部分是和多媒体团队合作，我们能拿到压缩帧的信息。
吕烨鑫-百度: 刚刚提到选择部分的decoder，从而减小文件的size。这里选择decoder的范围大概是怎么样的？
高裕轩（bilibili）: 根据真实场景的用户投稿分析。包括文件的上传格式、编解码格式和封装格式，做一个从上到下的排序，选取前X名，涵盖99.9%的情况。
吕烨鑫-百度: 现在能支持 H265 的编解码格式吗？
高裕轩（bilibili）: 在文件信息检测的时候是有的。
谭志杰-北邮: 云剪辑，用户上传后有没有通过 WASM 进行转码？
高裕轩（bilibili）: 没有本地转码，部分转码在云端进行。文件检测逻辑在本地，计算量不是特别大。
顾轶灵: 谢谢裕轩！
王鑫（Intel）: 简单介绍一下做这个项目的团队背景：团队来自Intel 北京公司，十几年来一直在runtime领域开发，包含Apache Harmony JVM开源项目，android runtime优化项目，以及从零开发的一个轻量级 JVM项目。从2-3年前团队开始了开发一个 wasm 轻量级runtime的内部实验项目，第一个版本是个解释器。经过团队努力让公司批准开源了这个项目，今年以来增加了AoT/JIT等许多新功能。
和前面介绍的浏览器上的WASM应用不一样，WAMR支持独立于浏览器的WASM应用。WAMR项目很注重实用性，是 Bytecode Alliance 的三个开源项目之一。
这个项目对模块化设计有很高的优先级，因为WASM引擎更多的被嵌入到其他的主体软件中来使用。这一点和Java相比不一样，JVM作为独立的进程，能通过完备Java库为负责应用程序提供所有的系统功能。 WASM最早需要基于浏览器提供的系统接口，开始系统功能并不是很完整。WASM除了适合在浏览器以外，还可应用在在低端设备上，边缘设备上，也可以在云上。不同环境需求不一样，技术特性也不同，提出了很对碎片化的应用需求。
同时我们也希望能达到最好的性能，最小的内存消耗。 目前支持解释器、AoT编译和即时编译。支持多CPU架构、多种OS。 实现了自主实现AoT加载器，不需要依赖Linux 的system loader，适应不同环境上的AoT功能。 WAMR也支持多实例，可扩展的WASM微服务和远程管理框架，这是独立使用wasm完成实际工作的的必要支撑。
WAMR对MVP和post MVP的WASM特性的支持非常积极。使用C实现，AoT/JIT基于LLVM的编译框架。WAMR的footprint很小，只支持AoT的话VM core 只需要50k， 支持解释器需要80k。运行简单WASM内存消耗可到16k DRAM以内（不计入加载执行程序所用内存）。
性能方面WAMR解释器和编译器都非常快。解释器在业界处于最快的一个量级，编译器可能也是最快的之一。这是一些性能对比数据，不同版本不同平台数据可能不一样。WAMR对SGX 支持性非常好，原生支持解释器和AoT，可以跑相对完整的应用。 WAMR支持pthread和多模块。社区目前比较活跃，我们团队主要对 Linux 和 Zephyr 提供支持，其它操作支持来自社区贡献。
下面是一些性能数据，以时间长度来计算性能。这是一系列的c语言编写的基准测试，可以看AoT和GCC模式的对比，总体来看性能还是非常理想的，性能损失不大而且保留沙箱的功能。
WASM常见用例和展望：有IoT与穿戴式小程序, 区块链也非常热； 可信运行环境，动态固件引擎 - 传统需要变成image，WASM可以直接布置到部件里； 超轻量级 serverless 容器方面，目前有很多公司在关注。
WAMR的沙箱计算特点，100ms里启动一个新的实例，消耗小，100k以内。高并发特性 - 利用沙箱可以在一个数组进程里启动很多实例并发运行，实例甚至能来自不同客户。实例可以进行快照，转移到另一台机器运行，对serverless可能是个重要的feature。
介绍下今年的开发计划：首先持续开发post MVP的特性。MVP是2017年的WASM 1.0版本，后面新的特性我们叫post MVP。支持threading和pthread，以及multi module都已完成。现在主要在做Source code debugging和SIMD的支持；性能和footprint 的调优会持续投入。
这里介绍一个嵌入式环境下的容器化应用，WAMR提供一套异步编程的框架，见右图展示了一个多实例的模式，隔离和消息通信交互，远程访问服务，安装卸载查询。 例子里是ARM板子上跑的一个嵌入式操作系统，LCD图形界面使用了Lvgl 2d图形库。WASM的字节码还可以跑在Linux里的SDL2模拟器上。这里是一个真的液晶屏上的节目，加载同一份字节码程序，表现都是一样的，展现了跨平台特性。
下面是可信计算环境的应用 - 在手机上和intel系统服务器等都有可信环境。通过硬件支持防止被hack，安全地执行一些任务。WASM是这领域的网红。WAMR对Intel的可信平台SGX有非常完善的支持，一直有很大的投入。可以在SGX里直接跑WASM AoT和解释器，JIT还不能原生支持，需要用到要libOS。WASI是W3C定义的系统访问接口标准提案，WAMR可以提供SGX环境下的WASM支持。这个领域里我们和学术界有不少合作项目，比如Private Data Object (PDO)和Faasm上扩展Trusted FaaS，让机密性云函数计算可以跑在可信环境。
WASM的serverless云端应用 - 大家都在谈这个方向，我目前看到的是实验性的项目比较多，如微软Krustlet，阿里蚂蚁腾讯也有些公开的消息。 serverless可能是miniapp一类应用最好的后端方案，前端和后端都托管给云商。serverless的一个问题是性价比，函数运行不太密集的话会降低性价比，大家都在看能不能用WASM解决这个痛点。 边缘计算是商业化比较成功的一个尝试，Fastly, Cloudflare在用WASM做CDN加速。这一块有很好的前景和空间。 我们在这一块有积极的社区合作。
最后WAMR是个完全开源的项目，托管在github上，欢迎大家加入我们，让开源项目更有生命力。
林作健（UC）: AoT编译是基于LLVM的吗？社区提交好像来自国内比较少？
王鑫（Intel）: 是的。GitHub就是社区，有来自大家的贡献。
林作健（UC）: 对LLVM修改？
王鑫（Intel）: 这一块我们没有在做，intel 可能另外有团队在做LLVM的开发。
欧波同（UCLA）: 我用了WAMR一阵子，WASI标准API在Embedded device上需要做什么调整？
王鑫（Intel）: 有点不容易，WASI现在是以file IO为主，60%-70%，很多的嵌入式操作系统并没有用file IO，可能需要自己来管理存储。
欧波同（UCLA）: 我们最近在做一个项目，看到三星的smart things的device sensor上的都被给出了一个描述，如...
王鑫（Intel）: 希望能offline细节讨论，贡献到社区
朱金鹏（华为）: WAMR在intel内部有落地产品吗？
王鑫（Intel）: 是的，落地产品是开源项目的支撑。
朱金鹏（华为）: release版本有没有官方发布版本号？
王鑫（Intel）: 还没有，这个项目没有投入太多的管理成本，专注于开发，以后会考虑
朱金鹏（华为）: 我们最近用它写了一个WGL应用，字节码是11k，编译成AoT以后扩大了3倍，像33k，理论跟我们实际测试情况有点差距。
王鑫（Intel）: 肯定要增长的，WASM的字节码非常紧凑，原生机器指令比WASM也要大一倍以上，它的每个操作码只有一个字节，一旦展开成机器指令必定要变大，AOT编译以后相比可能还要大，如boundary check的code，这是沙箱的保障，具体尺寸增长这要看不同平台，如X8664和32位。
朱金鹏（华为）: 所有实例都跑在一个runtime的话，每个应用都共享一个global buffer分配内存，这样应用之间的安全能保证吗？
王鑫（Intel）: 排除设计和实现的缺陷，应该能保证。因为都有自己的实例，没法访问相互的空间，需要通过消息和WASI来通讯和访问系统资源
朱金鹏（华为）: 代码中有些GC函数，是否支持GC管理回收？
王鑫（Intel）: WAMR继承了团队曾经开发的轻量级JVM的部分代码，使用了GC模块中的内存分配算法，但是目前并没有提供GC功能。
@@: WASI对C++的支持计划？和其它的runtime有横向对比数据吗？
王鑫（Intel）: C++可以用， 依赖于WASI，异常支持等等，目前工具链支持还不算很完备。Runtime的横向对比会引起不必要的争论。我们的功能相对来说比较完整，有商业支撑和专门的团队开发维护，有长期的路线图。性能方面我们还是挺领先的。footprint是我们的特色，AoT功能也是特意设计可以在嵌入式和TEE里动态加载。举一个例子：某个开源声音固件项目里，支持第三方音频算法，既要保证三方算法模块不破坏系统固件，又需要支持高性能，AoT在这个例子是一个完美支持。
@@: 例子在开源项目里面吗？
王鑫（Intel）:是的
林作健（阿里巴巴）: 大家好，我是来自阿里uc内核的作健，主要做compiler有关的工作，还有安全维护。compiler 用在很多方面，为什么我们要做v8 compiler？是要解决turbofan代码质量差的问题。更加长的时间获得更加好的代码，promise实现用的是builtin。
[展示性能数据] 说完数据我来介绍一下v8的编译流水线，再来讲一下我们是怎么介绍我们的流水线的
[展示V8编译流水线图]
[展示UC编译流水线图] 我们对llvm做了相当多的修改，这次分享讲不完，所以挑一些重点说一下：比如对llvm statepoint的调整，statepoint不生成stackslot。
新问题：statepoint记录了当时的包含值的寄存器，解决方案是调整spiller。
新问题：SelectionDAG合并了某些GC Relocate值
下面我们来讲讲UC版本的wasm AOT，mksnapshot是v8自带的snapshot生成工具，mkwasmsnapshot是UC基于mksnapshot的工具。
王鑫（Intel）: 不太懂浏览器的v8，想问一下这么做的目的是什么？性能？
林作健（阿里巴巴）: 是的
王鑫（Intel）: cache 到本地？
林作健（阿里巴巴）: 是的
王鑫（Intel）: AOT是在云端吗？
林作健（阿里巴巴）: 在pc上预先做好的，省掉了编译的时间
王鑫（Intel）: 是给自己的模块用还是给用户的模块用的？
林作健（阿里巴巴）: 自己的模块
王鑫（Intel）: 所以不会有特别大的安全性问题？
林作健（阿里巴巴）: 为了解决安全性问题，只允许https并且在白名单内的
王鑫（Intel）: 如何知道用户的架构？
林作健（阿里巴巴）: 只有arm架构，没有x86
王鑫（Intel）: js可以做aot吗？
林作健（阿里巴巴）: 可以缓存到字节码。
叶万标（Cryptape）: 我们公司主要做区块链底层技术，这个暑假花了很多时间在这个项目上。区块链虚拟机包括很多，比如wasm evm运行得很好，但是设计很糟糕。有人在尝试把evm编译到wasm，但是相关项目基本都已停止开发了。
solidify->wasm是唯一一个还在维护的项目，wasc项目的名字来自wasm和risc-v的组合，wasc依赖wavm。wavm比较有名，是一个高性能的转换层。wavm最初是wasm官方开发维护，后来独立成了单独的项目。wavm需要运行时，编译完大约2M，但是对于区块链来说太大。
wasc通过gcc最终生成elf文件，wasc使用一个极小的运行时替换了wavm相对臃肿的运行时。
[展示wasc vs wasmtime]
[展示wasc胶水代码] 使用assemblyscript进行合约编程，nervos ckb-vm是一个risc-v虚拟机。
[展示使用assemblyscript进行合约编程]
[展示github上assemblyscript编译的实际代码]
我从17年开始做wasm相关的工作，wasm有一些可以改进的地方。有些区块链直接使用wasm，但是eos只支持c/c++，substrate只支持rust+宏，实现互不兼容，抛弃了wasm最大的优点即通用性。wasm的测试用例有很多问题，wasi官方没有测试集，每一个开源项目的实现都各自写了自己的测试集。我提了一个issue，目前在慢慢改进。
吴忠敏（Intel）: wasc是不是和wavm的object file紧耦合的？
叶万标（Cryptape）: 是的
王鑫（Intel）: 2m的文件用几十行解决，背后的magic是什么？
叶万标（Cryptape）: 是wavm有jit、解释执行、aot执行等很多东西，我把多余的东西全部去掉了，不带bounding checking
王鑫（Intel）: 如何编译成risc-v？
叶万标（Cryptape）: 不在risc-v硬件跑，而是在虚拟机里跑。如果你对risc-v感兴趣，可以看看项目的“how it works“ wavm用了llvm生成的目标文件是机器码，可以是x86可以是risc-v
王鑫（Intel）: 你的目的是让runtime变小？
叶万标（Cryptape）: 性能问题和大小问题
王鑫（Intel）: 如果我们用wamr来做的话，使用aot module loader也可以
叶万标（Cryptape）: 我看过wamr，我的项目结构已经定了，换的话比较难，wamr aot module loader有多大？
王鑫（Intel）: 50kb
叶万标（Cryptape）: wasc 10kb 左右
王鑫（Intel）: 如果这个是一个长期的项目，我觉得使用wamr要更好一些，也可以支持risc-v，和其他架构一样，支持relocation就可以
叶万标（Cryptape）:目前的wasc的项目状态是属于技术储备，目前能编译到risc-v的性能不错的语言只有C。wasc让assemblyscript能够运行，我尝试过修改wamr，没有成功
王鑫（Intel）: 我们准备写一个文档，如何支持新的架构。
顾轶灵: 感谢大家参加今天的会议，感谢各位讲者的精彩分享！今天有WASM应用和实现等各方面的分享，希望今天大家能够得到启发，共同探讨今后的研究方向。大家可以在群里继续围绕相关话题进行提问和交流。我们稍后会公开分享本次会议纪要，在得到讲者许可的情况下会一同分享讲者ppt。
此外，Web中文兴趣组年底左右可能组织一次WebXR话题研讨会，欢迎关注！
[会议结束] 如有任何疑问或需要更多信息，欢迎联系我们。