在前面的一篇文章《TensorFlow.js 微信小程序插件开始支持 WebAssembly》中,我们谈到了 Tensorflow.js(tfjs) 的新后端 WebAssembly(WASM)。这篇文章进一步挖掘 tfjs WASM 后端的更多信息,并探讨一下 tfjs 为何要引入 WASM 后端。
首先澄清一个概念,WASM 后端只是 tfjs 的一种实现,就和 WebGL 实现的后端一样,对于微信小程序或 WebApp 而言,并不与后端直接打交道,并不会感知到 WASM 后端的存在。
其次,就实现而言,WASM 后端和 WebGL 后端是平行存在的,不存在谁取代谁的问题,针对不同的用户场景,选择合适的后端。而实现上的区别, WebGL 后端需要 GPU 支持,且要支持 WebGL ,而 WASM 完全是基于 CPU 运算的。当然,除了这两个后端,还有一个基于 CPU 运算的普通 Javascript 实现。
我们知道, GPU 非常适合机器学习的运算,不论是模型训练还是推导, GPU 能从性能上提升好几个数量级,一般而言机器学习离不开 GPU。那 Google 为何又要为 tfjs 开发出一个 WASM 后端呢?这不是在开历史倒车吗?
查看了 Google 的官方资料后,总结出如下几点理由:
从上表可以看出 WASM 后端比普通 JS(CPU)后端快 10-30 倍。与 WebGL 的 PK 则互有胜负,对于类似 MediaPipe 的 BlazeFace 和 FaceMesh 等超轻量级模型,WASM 与 WebGL 速度相当,或比之更快。而对于类似 MobileNet、BodyPix 和 PoseNet 的中型模型,WASM 的速度比 WebGL 慢 2-4 倍。
tfjs WASM 后端因其设备支持广泛,在性能上又能取得不错的平衡,特别是对于微信小程序而言,通常不会选用太复杂的模型,性能优势更明显。而 SIMD 和线程之类的新扩展,将如虎添翼,让 tfjs WASM 后端越来越受欢迎。作为一名 C++ 程序员,我也希望我的 C++ 编程技能也能在 Web 应用开发方面一展拳脚。