[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-webassembly-to-c-rivals-native-runtimes-2026-zh":3,"article-related-webassembly-to-c-rivals-native-runtimes-2026-zh":33,"series-research-a5119837-3405-44e3-86fd-cf3923096cb2":78},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":25,"views":29,"created_at":30,"published_at":31,"topic_cluster_id":32},"a5119837-3405-44e3-86fd-cf3923096cb2","webassembly-to-c-rivals-native-runtimes-2026-zh","WebAssembly-to-C 仍能打平原生執行環境","\u003Cp data-speakable=\"summary\">2026 年的 libsodium 基準顯示，WebAssembly-to-C 在加入 wide arithmetic 後，仍能和 Wasmer、Wasmtime 這類原生執行環境正面競爭。\u003C\u002Fp>\u003Cp>Frank DENIS 重新跑了一次 2026 基準測試。結果很直接，WebAssembly 編成 C 之後，速度還是能跟專用 runtime 正面對打。更意外的是，這件事發生在 WebAssembly runtime 已經有更好的 compiler、lowering，還多了更寬的指令支援之後。\u003C\u002Fp>\u003Cp>這次測的是 \u003Ca href=\"https:\u002F\u002F00f.net\u002F\" target=\"_blank\" rel=\"noopener\">Frank DENIS\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwasmer.io\u002F\" target=\"_blank\" rel=\"noopener\">Wasmer\u003C\u002Fa> 7.1.0、\u003Ca href=\"https:\u002F\u002Fwasmtime.dev\u002F\" target=\"_blank\" rel=\"noopener\">Wasmtime\u003C\u002Fa> 46.0.0，還有 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FWebAssembly\u002Fwabt\" target=\"_blank\" rel=\"noopener\">WABT\u003C\u002Fa> 裡的 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FWebAssembly\u002Fwabt\u002Ftree\u002Fmain\u002Fwasm2c\" target=\"_blank\" rel=\"noopener\">wasm2c\u003C\u002Fa> 路徑。DENIS 也把 wide arithmetic proposal 補進自己的 wasm2c fork，再用 \u003Ca href=\"https:\u002F\u002Fziglang.org\u002F\" target=\"_blank\" rel=\"noopener\">zig cc\u003C\u002Fa> 搭配 -O3 -march=native 編譯。\u003C\u002Fp>\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>項目\u003C\u002Fth>\u003Cth>數值\u003C\u002Fth>\u003Cth>意義\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd>Wasmer 版本\u003C\u002Ftd>\u003Ctd>7.1.0\u003C\u002Ftd>\u003Ctd>比較用 runtime 之一\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Wasmtime 版本\u003C\u002Ftd>\u003Ctd>46.0.0\u003C\u002Ftd>\u003Ctd>比較用 runtime 之一\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>建置特徵\u003C\u002Ftd>\u003Ctd>lime1 + simd128 + wide_arithmetic\u003C\u002Ftd>\u003Ctd>所有版本共用的功能集合\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>編譯器\u003C\u002Ftd>\u003Ctd>zig cc -O3 -march=native\u003C\u002Ftd>\u003Ctd>最後的原生 C 編譯路徑\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>記憶體量測\u003C\u002Ftd>\u003Ctd>15 次、取 median RSS\u003C\u002Ftd>\u003Ctd>看冷啟動記憶體用量\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch2>這次基準測試到底改了什麼結論\u003C\u002Fh2>\u003Cp>DENIS 自己也說，他原本以為 WebAssembly-to-C 的優勢會慢慢縮小。這個直覺很合理。runtime engine 一直在進步，JIT 能做的優化，也比單純 transpiler 多。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1783647172829-3d39.png\" alt=\"WebAssembly-to-C 仍能打平原生執行環境\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>但 2026 的數字往另一邊走。這次測的是 \u003Ca href=\"https:\u002F\u002Flibsodium.org\u002F\" target=\"_blank\" rel=\"noopener\">libsodium\u003C\u002Fa>，而 wasm2c 在加入 wide arithmetic 後表現很穩。文中的結果顯示，median 跟 Wasmer 打平，geomean 只有 Wasmer 的 0.887x，也只有 Wasmtime 的 0.814x。\u003C\u002Fp>\u003Cp>這代表一件很實際的事。當 WebAssembly module 事先已知，而且可以先編譯成 C，最後交給成熟的 native compiler，表現還是很能打。這種路線沒有大家想像中那麼老派，反而很務實。\u003C\u002Fp>\u003Cul>\u003Cli>Median 結果：與 Wasmer 打平\u003C\u002Fli>\u003Cli>Geomean runtime：wasm2c 為 Wasmer 的 0.887x\u003C\u002Fli>\u003Cli>Geomean runtime：wasm2c 為 Wasmtime 的 0.814x\u003C\u002Fli>\u003Cli>Benchmark 目標：libsodium\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>為什麼 C 路徑還活得很好\u003C\u002Fh2>\u003Cp>原因其實很簡單。輸出結果是普通 C。最後那段 codegen 交給成熟的 native compiler，不需要自己維護一套小型 backend。這種做法很土，但土得有效。\u003C\u002Fp>\u003Cp>DENIS 也提到，wasm2c 補 wide arithmetic 沒那麼痛苦。它主要靠 compiler carry intrinsics，再加上 C 的 128-bit integer type。對工程師來說，這代表功能擴充不一定要把整個\u003Ca href=\"\u002Fnews\u002Fultralytics-yolo26-vision-tasks-zh\">工具\u003C\u002Fa>鏈翻掉。\u003C\u002Fp>\u003Cp>還有一個常被忽略的優勢。WebAssembly runtime 會把 engine code、startup state、JIT machinery 一起帶進 process。C 編譯後的 module 不會。這種差異在短命工作負載上很明顯。\u003C\u002Fp>\u003Cblockquote>“The best WebAssembly runtime may still be no runtime at all.” — Frank DENIS\u003C\u002Fblockquote>\u003Cp>這句話很直白。當你已經有 module，而且不需要 runtime 服務時，多一層 engine 可能只是多一層成本。\u003C\u002Fp>\u003Ch2>記憶體才是很多人沒算進去的帳\u003C\u002Fh2>\u003Cp>DENIS 用 \u003Ccode>\u002Fusr\u002Fbin\u002Ftime -v\u003C\u002Fcode> 看 cold process RSS，再取 15 次的 median。這種量法很適合看啟動成本，因為很多服務在真實環境裡根本不會一直熱著。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1783647177086-5178.png\" alt=\"WebAssembly-to-C 仍能打平原生執行環境\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>他也提醒了一個常見誤區。runtime 的成本可以被攤平。只要服務會長時間存活，或者會重複跑很多 module，engine 的固定開銷就沒那麼刺眼。\u003C\u002Fp>\u003Cp>但如果是一次性工作，情況就變了。批次任務、短命 CLI 工具、部署環境很受限的系統，這些場景都會把 startup overhead 放大。這時候，C 路徑就很有存在感。\u003C\u002Fp>\u003Cul>\u003Cli>量測方式：\u003Ccode>\u002Fusr\u002Fbin\u002Ftime -v\u003C\u002Fcode> 的 cold RSS\u003C\u002Fli>\u003Cli>每個配置執行：15 次\u003C\u002Fli>\u003Cli>線性記憶體上限：64 MiB\u003C\u002Fli>\u003Cli>主要成本來源：engine executable 與 startup state\u003C\u002Fli>\u003C\u002Ful>\u003Cp>所以這個結果不是在說 runtime 沒用。它是在說，當啟動成本被算進去，整個經濟模型就變了。\u003C\u002Fp>\u003Ch2>部署選擇也跟著改變\u003C\u002Fh2>\u003Cp>WebAssembly-to-C 會把部署目標換掉。目的機器不需要 WebAssembly runtime，只需要 C compiler 和足夠的 libc 支援。這讓它變成很傳統、也很實際的 portable 方式。\u003C\u002Fp>\u003Cp>DENIS 也提到，編譯器本身現在就是選項。你可以用 \u003Ca href=\"https:\u002F\u002Fclang.llvm.org\u002F\" target=\"_blank\" rel=\"noopener\">clang\u003C\u002Fa> 或 \u003Ca href=\"https:\u002F\u002Fgcc.gnu.org\u002F\" target=\"_blank\" rel=\"noopener\">GCC\u003C\u002Fa>。如果你在意不同的信任模型，還能考慮 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002FPLSysSec\u002FFil-C\" target=\"_blank\" rel=\"noopener\">Fil-C\u003C\u002Fa>。如果你要的是驗證過的 code generation，\u003Ca href=\"https:\u002F\u002Fcompcert.org\u002F\" target=\"_blank\" rel=\"noopener\">CompCert\u003C\u002Fa> 也在桌上。\u003C\u002Fp>\u003Cp>這種彈性很少被拿來認真談。專用 runtime 給你單一執行模型。WebAssembly-to-C 則讓你自己選 compiler，再決定要速度、要安全，還是要形式化保證。\u003C\u002Fp>\u003Ch2>Wasmer 和 Wasmtime 還是有強項\u003C\u002Fh2>\u003Cp>DENIS 也沒有把 runtime 說死。他很清楚，WebAssembly-to-C 不適合動態載入不受信任的 code，也不適合 policy enforcement、preemption、fuel metering、component-model machinery，或共享 engine 的 multi-tenant 環境。\u003C\u002Fp>\u003Cp>\u003Ca href=\"https:\u002F\u002Fwasmer.io\u002F\" target=\"_blank\" rel=\"noopener\">Wasmer\u003C\u002Fa> 的 \u003Ca href=\"https:\u002F\u002Fwasix.org\u002F\" target=\"_blank\" rel=\"noopener\">WASIX\u003C\u002Fa> 很重要。它補了不少 WASI 還不完整的 POSIX 缺口。如果你要跑現成應用，這條路比 transpile 成 C 直接得多。\u003C\u002Fp>\u003Cp>\u003Ca href=\"https:\u002F\u002Fwasmtime.dev\u002F\" target=\"_blank\" rel=\"noopener\">Wasmtime\u003C\u002Fa> 則有 \u003Ca href=\"https:\u002F\u002Fcomponent-model.bytecodealliance.org\u002F\" target=\"_blank\" rel=\"noopener\">Component Model\u003C\u002Fa>。它讓 WebAssembly 模組之間有型別化邊界，方便組合。DENIS 提到，理論上也能把 component 分開編成 C，但他沒有深入測。\u003C\u002Fp>\u003Cul>\u003Cli>適合 runtime：不受信任 code、policy、fuel、多租戶\u003C\u002Fli>\u003Cli>適合 WebAssembly-to-C：已知 module、先編譯、短命任務\u003C\u002Fli>\u003Cli>Wasmer 強項：WASIX，補足 POSIX 類工作負載\u003C\u002Fli>\u003Cli>Wasmtime 強項：Component Model，適合 typed composition\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>這對工程師的實際意思\u003C\u002Fh2>\u003Cp>這份結果最有意思的地方，在於 WebAssembly 走了兩條路。runtime engine 變強了，compile-to-C 的路線也沒有掉隊那麼多。尤其 wide arithmetic 落地後，這條路在 cryptographic code 上還是很能打。\u003C\u002Fp>\u003Cp>如果你現在要選 WebAssembly 方案，別先背口號。先看你需不需要 engine，會不會跑不受信任 code，還有 module 是否必須跨主機保持一致。答案如果偏向 runtime，就用 runtime。答案如果偏向控制權和精簡堆疊，WebAssembly-to-C \u003Ca href=\"\u002Fnews\u002Ftesla-model-y-l-family-ev-premium-real-zh\">仍然\u003C\u002Fa>值得放進選項。\u003C\u002Fp>\u003Cp>我會把這篇的結論講得更直接一點：很多團隊其實不需要 runtime，只是習慣先裝 runtime。下一次做技術選型時，先問自己一件事，你的 WebAssembly 工作負載，有多少真的需要 engine 提供的那些額外服務？\u003C\u002Fp>\u003Ch2>台灣團隊可以怎麼看這件事\u003C\u002Fh2>\u003Cp>如果你在做後端服務、CLI 工具，或是要把一段安全敏感的邏輯塞進產品裡，這篇很值得記下來。WebAssembly 常被包裝成「到處都能跑」，但\u003Ca href=\"\u002Fnews\u002Fopenai-54-token-efficiency-ai-coding-battleground-zh\">真正\u003C\u002Fa>落地時，啟動時間、記憶體、部署包大小，常常比理論更重要。\u003C\u002Fp>\u003Cp>台灣很多團隊的部署環境都很現實。容器數量有限，CI\u002FCD 要快，機器規格也不一定豪華。這時候，少一個 runtime，常常比多一個優化 flag 更有感。先把成本攤開，再談架構，會比直接選最潮的方案更省事。\u003C\u002Fp>\u003C\u002Fh2>","2026 年的 libsodium 基準顯示，WebAssembly-to-C 在加入 wide arithmetic 後，仍能和 Wasmer、Wasmtime 這類原生執行環境正面競爭。","00f.net","https:\u002F\u002F00f.net\u002F2026\u002F07\u002F08\u002Fwebassembly-compilation-to-c-2026\u002F",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1783647172829-3d39.png","research","zh","3765fb1b-e8c7-4e81-8ed0-24a1a67e2928",[17,18,19,20,21,22,23,24],"WebAssembly","wasm2c","Wasmer","Wasmtime","libsodium","wide arithmetic","Zig","C 編譯",[26,27,28],"2026 的 libsodium 基準顯示，wasm2c 在加入 wide arithmetic 後，仍能和 Wasmer、Wasmtime 正面競爭。","WebAssembly-to-C 的優勢在於少一層 runtime、冷啟動更輕、部署目標更單純。","runtime 仍適合不受信任 code、多租戶、policy 與 Component Model 場景。",0,"2026-07-10T01:32:30.98686+00:00","2026-07-10T01:32:30.958+00:00","c3937d1d-0239-49de-aab9-c0b782d315a3",{"tags":34,"relatedLang":37,"relatedPosts":41},[35],{"name":17,"slug":36},"webassembly",{"id":15,"slug":38,"title":39,"language":40},"webassembly-to-c-rivals-native-runtimes-2026-en","WebAssembly-to-C still rivals native runtimes in 2026","en",[42,48,54,60,66,72],{"id":43,"slug":44,"title":45,"cover_image":46,"image_url":46,"created_at":47,"category":13},"7773aa86-8276-49ff-8fce-a58639ce180c","benchmark-scientific-lineage-reasoning-zh","IG-Bench：測科學譜系推理","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1783666980843-7o76.png","2026-07-10T07:02:31.047117+00:00",{"id":49,"slug":50,"title":51,"cover_image":52,"image_url":52,"created_at":53,"category":13},"7be813ff-524d-4445-a924-5c11002c87cf","opencof-video-generation-reasoning-zh","OpenCoF 讓影片模型逐幀推理","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1783665174981-siq1.png","2026-07-10T06:32:29.458194+00:00",{"id":55,"slug":56,"title":57,"cover_image":58,"image_url":58,"created_at":59,"category":13},"5c1a4cfe-93d9-4619-8f04-67a10de880ce","uniclawbench-proactive-agents-live-tasks-zh","UniClawBench：活體任務測主動式代理","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1783663371728-73eg.png","2026-07-10T06:02:24.502805+00:00",{"id":61,"slug":62,"title":63,"cover_image":64,"image_url":64,"created_at":65,"category":13},"ed59677b-bc56-4c01-b1e8-163b6c6744dc","analysis-driven-transformer-linearization-zh","線性化 Transformer 但不掉品質","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1783580571758-gqu7.png","2026-07-09T07:02:26.210405+00:00",{"id":67,"slug":68,"title":69,"cover_image":70,"image_url":70,"created_at":71,"category":13},"3e8fbc00-9a1f-4e79-bfc2-ca933bf09eb9","co-lmlm-continuous-query-limited-memory-models-zh","Co-LMLM 讓 LLM 持續查知識","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1783578779210-wi5d.png","2026-07-09T06:32:30.404486+00:00",{"id":73,"slug":74,"title":75,"cover_image":76,"image_url":76,"created_at":77,"category":13},"2b8e7059-ee9e-40a7-9f1f-d80dbf122859","scireasoner-structure-property-reasoning-zh","SciReasoner讓結構變成可讀證據","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1783576975609-6pfl.png","2026-07-09T06:02:30.862628+00:00",[79,84,89,94,99,104,109,114,119,124],{"id":80,"slug":81,"title":82,"created_at":83},"f18dbadb-8c59-4723-84a4-6ad22746c77a","deepmind-bets-on-continuous-learning-ai-2026-zh","DeepMind 押注 2026 連續學習 AI","2026-03-26T08:16:02.367355+00:00",{"id":85,"slug":86,"title":87,"created_at":88},"f4a106cb-02a6-4508-8f39-9720a0a93cee","ml-papers-of-the-week-github-research-desk-zh","每週 ML 論文清單，為何紅到 GitHub","2026-03-27T01:11:39.284175+00:00",{"id":90,"slug":91,"title":92,"created_at":93},"c4f807ca-4e5f-47f1-a48c-961cf3fc44dc","ai-ml-conferences-to-watch-in-2026-zh","2026 AI 研討會投稿時程整理","2026-03-27T01:51:53.874432+00:00",{"id":95,"slug":96,"title":97,"created_at":98},"cf046742-efb2-4753-aef9-caed5da5e32e","adaptive-block-scaled-data-types-zh","IF4：神經網路量化的聰明選擇","2026-03-31T06:00:36.990273+00:00",{"id":100,"slug":101,"title":102,"created_at":103},"53a0dc54-0371-4e40-8d5e-74e94a73840c","geometry-aware-similarity-metrics-for-neural-representations-zh","超越距離測量：用微分幾何重新理解神經網路","2026-03-31T06:01:01.241968+00:00",{"id":105,"slug":106,"title":107,"created_at":108},"fee7d472-a775-4b1d-bbc2-1e8bca1bbf8b","on-the-fly-repulsion-in-the-contextual-space-for-rich-divers-zh","讓AI繪圖更有創意：用排斥力提升生成多樣性","2026-03-31T06:01:25.439673+00:00",{"id":110,"slug":111,"title":112,"created_at":113},"a9901203-d69b-447b-8854-15d14eab32b4","vision-aided-beam-prediction-cnn-eca-zh","影像輔助波束預測升級 CNN","2026-04-01T10:00:25.8073+00:00",{"id":115,"slug":116,"title":117,"created_at":118},"b55e7dd4-0a24-4b3d-804d-b0309a03f498","triple-band-fss-mimo-antenna-sub-6-ghz-zh","三頻 FSS MIMO 天線瞄準 sub-6 GHz","2026-04-01T13:18:36.857305+00:00",{"id":120,"slug":121,"title":122,"created_at":123},"f68290bd-e7f3-4b30-ba22-dcd4e0130a66","openclaw-1299-repos-eight-weeks-analysis-zh","OpenClaw 1299 個 Repo 的資料解讀","2026-04-02T05:03:45.208411+00:00",{"id":125,"slug":126,"title":127,"created_at":128},"ed9f80eb-eb02-4d35-8ad4-0ddf428751dd","beam-coherence-aware-combining-mmwave-mimo-zh","毫米波 MIMO 的雙階合併法","2026-04-02T05:27:26.897188+00:00"]