回看板
Disp BBS
作者 erspicu (.)
標題 [討論] 有公司使用到WASM技術了嗎?
時間 Tue Jul  2 01:51:58 2024


只是sideproject需求 想說wasm出來也算幾年了

撇開.NET的Blazor框架不談 (是說轉戰Blazor的公司也不多的感覺)

目前好像看到wasm應用的機會不是很廣

不是說它不厲害 而是到底要做什麼方面的應用

當然我知道可以port c/c++其他語言到網頁上 移植遊戲

或是做一些比較需要高效能的運算等等 不過一般狀況下好像就不知道怎樣應用好

但我之前有一個構想 就是上傳圖片.縮圖.壓縮 或是上傳影片

這些原來的設計多數是把檔案原封不動上傳到後端 再從後端排程處理

如果前端可以直接處理掉圖片.影片的縮圖與壓縮 再把處理結果上傳到後端

理論上可以減輕後端負擔以及節省上傳頻寬資源

自己是想用這種方式來處理相簿上傳照片的處理方式 所以稍微study實作了概念

https://github.com/erspicu/LanczosWasmDemo
GitHub - erspicu/LanczosWasmDemo: Lanczos縮圖演算法用C# WASM實作測試
[圖]
Lanczos縮圖演算法用C# WASM實作測試. Contribute to erspicu/LanczosWasmDemo development by creating an account on GitHub. ...

 

Lanczos縮圖法 大概是幾年前我所知縮圖品質比較好的方式 實作也不會太複雜

我自己用在x64 win11環境下測試用.net framework 最優化後

(用很c風格的指標處理方式+多核平行運算)

好比說4096*3072 縮到1600x1200 一張圖計算大概都是100ms內 一瞬間的事情

原本參考這方式
https://koshian2.hatenablog.jp/entry/2017/11/23/212813
C#でLanczos法による画像リサイズ - shikoan’s memo
[圖]
画像をリサイズ＋αをするプログラムを作りたくなったので、Lanczos法の実装を行ってみた。 自力で実装 クォリティはさておき、とりあえず一回ぐらい自力で実装してみようということでまずは考え方から。このサイトが参考になった。 このサイトでは拡大のみだが、拡大にしろ縮小にしろ要するにピクセル単位で整数 ...

 
但這效能差 而且其實算出來的畫面有些問題

想說效果很不錯想把縮圖算法移植到wasm功能上

剛好看到  https://tinyurl.com/mrm2r86r 這篇
C# in Browser via WebAssembly (without Blazor) - CodeProject
[圖]
In this article I describe how to write C# code that runs in Browser. ...

 
可以用我比較熟悉的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 (臺灣)
※ 作者: erspicu 2024-07-02 01:51:58
※ 文章代碼(AID): #1cWkp2Tb (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1719856322.A.765.html
※ 同主題文章:
[討論] 有公司使用到WASM技術了嗎?
07-02 01:51 erspicu
Re: [討論] 有公司使用到WASM技術了嗎?
07-06 04:00 oopFoo
推 ohmylove347: https://squoosh.app/
要不要參考這個項目，好像是谷歌寫的PWA，也是壓縮圖片影片之類的，還能安裝在本地的樣子，或許跟你的專案有相似的地方1F 07/02 01:55
Squoosh
[圖]
Squoosh is the ultimate image optimizer that allows you to compress and compare images with different codecs in your browser. ...

 
類似做法 看他的GITHUB 一些演算法.編解碼也是用WASM移植其他語言專案
但.NET方案有點像套娃 理論上他的效能會比較好 有現成工具可以順利應用的話
如果效果理想 大概就可以直接用了
※ 編輯: erspicu (219.68.24.12 臺灣), 07/02/2024 02:15:47
→ GoalBased: compress.js, pica, browser-image-compression5F 07/02 03:33
推 oopFoo: 你知道wasm跟js是怎麼互相call？資料怎麼傳？你這個要搞清楚。wasmGC是用來解決一部份這類的問題。wasm你需要管理記憶體，不然光是copy就吃掉一堆效能。而且wasm的compiler本來就比java/c#差很多，效能差是正常的。所以不用c/c++或直接wasm assembly，還要規劃好資料的傳遞，不然根本直接js+typedarray就好了。
js的效能是非常好的，不要有錯誤的觀念。所以除非你的
wasm程式規劃的很好，不然比js差是正常的。c#除非移植到wasmGC，不然高效能是很難的。
https://web.dev/case-studies/google-sheets-wasmgc6F 07/02 06:17
Why Google Sheets ported its calculation worker from JavaScript to WasmGC  |  web.dev
[圖]
Calculations in Google Sheets were initially done on the server, then on the client in JavaScript, and now on the client in WebAssembly Garbage Collec ...

 
推 takasaki: 問過safari用戶了嗎？相容性搞死你16F 07/02 06:39
推 oopFoo: webgl/glsl來跑lanczos是最快，最簡單，相容性最好的方法webgl/glsl處理影像容易，程式也容易，只是入門難而已。https://stackoverflow.com/questions/54299457
從這篇追回去，你大概就知道怎麼做了17F 07/02 06:46
webgl - Image resize with large scaling factor - Stack Overflow
[圖]
For context, this question followed this one.
The intent of this shader is to have a predictable image resize algorithm, so that I know if the resulti ...

 
推 neo5277: 推一個實作精神21F 07/02 13:50

--
作者 erspicu 的最新發文:
點此顯示更多發文記錄