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


需求:有一个计算密集型程序,实现快速的算法速度,然后需要将最终结果传递给浏览器;
解决方案:是在服务器端(在 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。