基于 Webassembly 的一些问题

[seanwhy]

最近在迁移公司 C/S 架构程序（ C++、三维软件），想往浏览器端迁移，目前正在施行的方案是用 emscripten 编译的 webassembly 模块。
公司程序用了大量的三方库比如：gdal 、ffmpeg 、opengles ，三方库又依赖了大量其他的库，比如 gdal 依赖了 geos 、proj 、curl 、libtiff 、sqlite3 等。因此编译采用的是静态链接，即所有.a 最终生成的是一个.wasm 文件。
我这里基本用了最新的版本，以防对 webassembly 缺乏支持。
那么问题来了：
问题 1：基于如此巨量的三方库以及自有实现代码，这个 wasm 文件会很巨大（百兆体量），浏览器能加载的出来吗，或者此种体量是否规范？
问题 2：据说 webassembly 使用内存上限有限制，大概 4GB ，有方法能突破限制吗？我司程序就是个吃内存的家伙
问题 3：如此多的三方库，是要一个个验证能否在浏览器上运行测试用例吗？还是说只要经过 emscripten 编译过，就基本认定在浏览器端运行基本没有问题？
问题 4：性能衰减问题，大概是多少体量，自我感觉能效不高，怕迁移完毕卡成狗。

[Beginner1]

我司跟 3D 上 web 和他们一样，目前感觉也还好。不过我们主要使用 vtk ，代码确实进行了大量整改，就速度来说其实还好。可能我们功能没有他们那么复杂。当然 Ai 这些只有上云了。

[seanwhy]

@cat 说白了浏览器端二次开发者多，客户端二次开发式微了

[seanwhy]

@icyalala 这么严重么？看资料是原生的 1/3~2/3

[gam2046]

@seanwhy #20 一般情况下，纯计算能力，wasm 效率能到 native 的 50%都够呛。毕竟 wasm 还是一个虚拟机，还得交给浏览器解释执行。而且现阶段 wasm 对于 pthread 的支持还是有点磕磕绊绊，很多开源项目的 wasm ，我看他们的处理方式是直接改成单线程保平安。

[tool2d]

@seanwhy "那么用 emsctipten 编译出来，是否就意味着无需验证，也能运行于浏览器？"

验证很简单，写个单元测试跑一下就行了。

把对 wasm 的内心期望减半，再减半，就比较符合浏览器里运行的真实情况。

[kaiserzhang123]

内存 4GB 的原因是因为编译到 wasm32 位的操作，最大就支持 4gb 内存，想要突破就只能使用 wasm64 位

[kaiserzhang123]

@nieyujiang 编译到 wasm64 位就没有 4gb 内存的限制

[icyalala]

@seanwhy https://00f.net/2023/01/04/webassembly-benchmark-2023/ 这有个通用计算的测试接近你的资料，平均下降到 43%，但是这是最快的 wasm 实现的结果。实际浏览器可能会再慢一些。

https://ffmpegwasm.netlify.app/docs/performance/ 这有个 Chrome+ffmpeg.wasm 的性能测试，平均下降到 8%，差了一个量级。

[guanzhangzhang]

大佬，xorg-x11-server 和 openresty 有静态编译姿势吗

[Jirajine]

就算能跑，你觉得 serve 一个 100m 的 wasm 文件给浏览器合适吗？

能编译到 wasm 的代码，可以认为就是可以运行的。但代码可以运行，不代表代码链接/调用的 API 也被支持。所以代码可以重用，其他都得重写。

[br_wang]

提到 wasm ，我也有个问题：一个使用了 wasm 的网页，如果被 iframe 嵌入到另一个网页，还能正常访问到 wasm 文件并顺利运行么？

[rabbbit]

https://v8.dev/blog/4gb-wasm-memory

[churchill]

emscripten 文档上大量篇幅是讲 porting 和 optimizing webgl, 可见坑不少，祝楼主好运
可能不是很恰当的例子，有些图形库说是支持 emscripten 编译，可是桌面上是调的 opengl4.6 ，用 emscripten 编译就使用 emscripten 自带的 gl 头文件了，如果你的 shader 不是针对 es 300 写的运行起来就挂了

[rabbbit]

https://github.com/WebAssembly/memory64/issues/42

[image72]

我觉得你想把这些搬到浏览器运行之前，可以先考虑发几个版本的 electron 编译版试试水，能移植的移植，能改写的改写，再考虑浏览器。electron 也是完整浏览器，也能支持内置 wasm 以及原生
从底层原生一步跨到纯浏览器 wasm, 步子太大，容易扯到蛋

[opengg]

成功的项目基本没有全程 wasm 的，线上大多数都是 web 界面加部分重逻辑重计算部分走 wasm 调用。
当然也有类似的尝试，但我还没见过 full wasm 的商业产品。

[sunzhuo]

@br_wang 没问题

[sunzhuo]

我建议用 threejs 重现桌面版的 api ，然后再考虑 wasm 移植一些 c 功能。

[mahaoqu]

@gam2046 改单线程不用 Webworker 遇到计算密集型不会卡死 UI 么

[mahaoqu]

如果你引用的所有库都能直接源码级跨 Win/Linux 两个系统，那大概率直接用 emscripten 编译到 WebAssembly 是能用的。比如去年谷歌那边就说 SQLite 用浏览器的 OPFS 后端跑通了，但这样的库还是太少。