作者erspicu (.)
看板Soft_Job
标题[讨论] 有公司使用到WASM技术了吗?
时间Tue Jul 2 01:51:58 2024
只是sideproject需求 想说wasm出来也算几年了
撇开.NET的Blazor框架不谈 (是说转战Blazor的公司也不多的感觉)
目前好像看到wasm应用的机会不是很广
不是说它不厉害 而是到底要做什麽方面的应用
当然我知道可以port c/c++其他语言到网页上 移植游戏
或是做一些比较需要高效能的运算等等 不过一般状况下好像就不知道怎样应用好
但我之前有一个构想 就是上传图片.缩图.压缩 或是上传影片
这些原来的设计多数是把档案原封不动上传到後端 再从後端排程处理
如果前端可以直接处理掉图片.影片的缩图与压缩 再把处理结果上传到後端
理论上可以减轻後端负担以及节省上传频宽资源
自己是想用这种方式来处理相簿上传照片的处理方式 所以稍微study实作了概念
https://github.com/erspicu/LanczosWasmDemo
Lanczos缩图法 大概是几年前我所知缩图品质比较好的方式 实作也不会太复杂
我自己用在x64 win11环境下测试用.net framework 最优化後
(用很c风格的指标处理方式+多核平行运算)
好比说4096*3072 缩到1600x1200 一张图计算大概都是100ms内 一瞬间的事情
原本参考这方式
https://koshian2.hatenablog.jp/entry/2017/11/23/212813
但这效能差 而且其实算出来的画面有些问题
想说效果很不错想把缩图算法移植到wasm功能上
刚好看到
https://tinyurl.com/mrm2r86r 这篇
可以用我比较熟悉的c#去做移植
但移植出来的成果运算速度差 .net framework在win11 x64上太多
可能有100倍以上差异 打个比方 90ms 变成 9秒
原本以为可以把c#编译成不需要仰赖.net虚拟机的方式跑
结果稍微看架构 好像是把.NET虚拟机在WASM实作然後去跑.NET PORT过去的东西
加上在浏览器WASM环境内 没有像直接跑在电脑上 有JIT优化
所以速度有差 (wasm虚拟机跑.net虚拟机跑.net cli 套娃...)
但不排除有再优化的可能性 像C#的Parallel.For
移植到WASM上後 其实并没有平行加速运算的实际效能...
给大家研究看看 (所以最後还是换成单纯回圈)
C/C++ N年没相关工作经验写了 说不定C移植过去效能会好上非常多
我的专案就分享给对C#在WASM应用有兴趣的人参考
https://github.com/erspicu/LanczosWasmDemo
也希望加速的部分 可以分享解决方案
Parallel.For 也不知道实际移植过去到底是怎样
平行处理的部分可能用别方式置换掉
Web Worker或是webgpu不知道可不可行
最终我心中的理想应用场景 大概是使用者上传图片和影片
把缩图跟编码的工作丢给前端处理完上传
这大概是目前我想到还满好用通用的应用场景
ps.c#移植wasm,其实满多功能无效,编译器会提醒,
有些功能不然就要找别方案替代,不然就要自己实作,
所以也不是爽爽可以无痛把c#相关资源丢到前端上
牵涉到跟os依赖的部分 很多都不可用 看跳一堆警告
最後毅然把原本的bitmap物件使用移除掉了
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 219.68.24.12 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1719856322.A.765.html
2F：→ ohmylove347: 要不要参考这个项目，好像是谷歌写的PWA，也是压缩图 07/02 01:55
3F：→ ohmylove347: 片影片之类的，还能安装在本地的样子，或许跟你的专 07/02 01:55
4F：→ ohmylove347: 案有相似的地方 07/02 01:55
类似做法 看他的GITHUB 一些演算法.编解码也是用WASM移植其他语言专案
但.NET方案有点像套娃 理论上他的效能会比较好 有现成工具可以顺利应用的话
如果效果理想 大概就可以直接用了
※ 编辑: erspicu (219.68.24.12 台湾), 07/02/2024 02:15:47
5F：→ GoalBased: compress.js, pica, browser-image-compression 07/02 03:33
6F：推 oopFoo: 你知道wasm跟js是怎麽互相call？资料怎麽传？你这个要搞清 07/02 06:17
7F：→ oopFoo: 楚。wasmGC是用来解决一部份这类的问题。wasm你需要管理 07/02 06:19
8F：→ oopFoo: 记忆体，不然光是copy就吃掉一堆效能。而且wasm的compiler 07/02 06:20
9F：→ oopFoo: 本来就比java/c#差很多，效能差是正常的。所以不用c/c++或 07/02 06:22
10F：→ oopFoo: 直接wasm assembly，还要规划好资料的传递，不然根本直接 07/02 06:24
11F：→ oopFoo: js+typedarray就好了。 07/02 06:25
12F：推 oopFoo: js的效能是非常好的，不要有错误的观念。所以除非你的 07/02 06:35
13F：→ oopFoo: wasm程式规划的很好，不然比js差是正常的。c#除非移植到 07/02 06:36
14F：→ oopFoo: wasmGC，不然高效能是很难的。 07/02 06:38
16F：推 takasaki: 问过safari用户了吗？相容性搞死你 07/02 06:39
17F：推 oopFoo: webgl/glsl来跑lanczos是最快，最简单，相容性最好的方法 07/02 06:46
18F：→ oopFoo: webgl/glsl处理影像容易，程式也容易，只是入门难而已。 07/02 06:47
20F：→ oopFoo: 从这篇追回去，你大概就知道怎麽做了 07/02 06:59
21F：推 neo5277: 推一个实作精神 07/02 13:50
22F：→ testPtt: Blazor就容易上手 没有容易的框架这是wasm主要的门槛 07/02 15:38
23F：→ keel90135: 支援度没办法全部就没法正式上线 只能当玩具 07/02 19:23
24F：→ keel90135: 上线一堆奇怪手机浏览器直接搞死你 07/02 19:24
25F：推 guanting886: 就稍微可以用client端摊原本server端要做的运算 07/02 19:25
26F：→ guanting886: 然後有些运算可能javascript算得比wasm还快 07/02 19:26
27F：→ guanting886: 就当作玩具 什麽时候还有机会要用不知道 影片编码就 07/02 19:27
28F：→ guanting886: 算了 速度真的不行 07/02 19:27
29F：→ Killercat: 有几个crypto project就是用wasm部署到用户client 07/02 23:33
30F：→ Killercat: 让用户的浏览器可以做一些链操作 07/02 23:34
32F：→ TakiDog: ffmpeg 可以简单做些操作 07/04 18:26
33F：→ s25g5d4: 曾经做过 WASM 插进 envoy 里当作 microservice sidecar 07/05 15:17
34F：→ s25g5d4: filter 07/05 15:17
35F：推 s25g5d4: 另外一个神级 WASM 应用范例是 Figma 07/05 15:19
36F：推 abccbaandy: Figma有很神吗？ 启动慢到想到当年的java applet 07/06 02:12