Rust在浏览器Wasm和后端服务器中运行性能比较

22-03-07 banq

需求：有一个计算密集型程序，实现快速的算法速度，然后需要将最终结果传递给浏览器；
解决方案：是在服务器端（在 actix Web 服务器中）运行它？还是在浏览器内的 Wasm 模块中运行它？

WASM 通常在客户端运行，虽然它被编译为二进制格式，但它仍然在 WASM VM 中运行，这意味着它可能有点接近本机机器代码；
另一方面，在服务器上运行的本机编译的 Rust 代码通常会在本机机器代码的帐户上更快（但同样有很多变量和上下文无法承受）。

一些 CPU 密集型程序有时在 wasm 中明显变慢，没有明显的原因。这是当前 wasm 实现的缺点之一，并且很难在程序方面修复：论文。

服务器端代码很可能能够使用 simd，但是并非所有浏览器都支持 SIMD，检测一下浏览器是否支持它，如果支持，则获得相当显着的加速（并且 SIMD 首先适用于您的用例）。这几乎是 WASM 在长时间运行的任务中比 JS 具有非常显着的性能优势的主要情况。
然而，您需要考虑的另一个因素是负载平衡：当客户端数量增加时，您的服务器是否仍然会更快？
最后，是否要将您的页面提供给手机？如果是这样，您的服务器很可能会更快。

当你做你的 wasm 基准测试时，你是否打开了 devtools标识？如果你这样做，它会在某种调试模式下运行，速度会慢 5-10 倍。
在Chrome浏览器中的开发工具dev tools控制台有一个性能标签，可以全速运行，当控制台打开时，wasm代码是 "分层 "的；而Firefox也有类似的 "打开devtools "后速度更慢的行为。
在运行fibonacci算法时，如果不打开这个标识开关，其实现的WASM版本比javascript实现慢了5倍，打开devtools后。一旦刷新了页面，关闭了它们，情况就相反了：WASM的速度是JS的5倍。

WASM VM 的性能无法与编译为 x86 的应用程序相提并论：
一个方面是调用WASM模块的开销。传递数据来往。这并不像人们想象的那样多。如果你经常来回调用，这可能是一个需要优化的领域。这也包括有多少数据被传递过去。因为这被复制了。
当你编译Rust到WASM时，你会得到为你生成的捆绑JS文件。另一个需要调查的领域是研究如何优化这些胶水代码。
WASM模块在使用前也要进行编译和实例化。检查这是否被包括在你的基准中。因为你可以在页面加载后，在后台，在你需要运行WASM数学代码之前提前做这个。

浏览器中的 WASM 目前通常非常缓慢且令人失望？错了，纯粹的计算（即不调用会减慢它的 JS）可以非常接近本机速度，如果它涉及大量 SIMD，您甚至可以击败本机代码。Idiomatic Rust 的速度也经常以 > 10 倍的速度击败惯用 JS。
JavaScript JIT 在优化方面表现出色，而 WASM 代码似乎没有得到同样的处理， wasm 仍然无法直接访问任何浏览器 API。