TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Show HN: (bits) of a Libc, Optimized for Wasm

78 点作者 ncruces27 天前
I make a no-CGO Go SQLite driver, by compiling the amalgamation to Wasm, then loading the result with wazero (a CGO-free Wasm runtime).<p>To compile SQLite, I use wasi-sdk, which uses wasi-libc, which is based on musl. It&#x27;s been said that musl is slow(er than glibc), which is true, to a point.<p>musl uses SWAR on a size_t to implement various functions in string.h. This is fine, except size_t is just 32-bit on Wasm.<p>I found that implementing a few of those functions with Wasm SIMD128 can make them go around 4x faster.<p>Other functions don&#x27;t even use SWAR; redoing <i>those</i> can make them 16x faster.<p>Smooth sort also has trouble pulling its own weight; a Shell sort seems both simpler and faster, while similarly avoiding recursion, allocations and the addressable stack.<p>I found that using SIMD intrinsics (rather than SWAR) makes it easier to avoid UB, but the code would definitely benefit from more eyeballs.<p>See this for some benchmarks on both x86-64 and Aarch64: <a href="https:&#x2F;&#x2F;github.com&#x2F;ncruces&#x2F;go-sqlite3&#x2F;actions&#x2F;runs&#x2F;14516931864">https:&#x2F;&#x2F;github.com&#x2F;ncruces&#x2F;go-sqlite3&#x2F;actions&#x2F;runs&#x2F;145169318...</a>

6 条评论

fuhsnn27 天前
Wasm intrinsics look neat as a higher-level fixed size SIMD abstraction. I wonder how good the compilers can do if using them for AOT targets with libraries like simd-everywhere.<p>string.h is missing strstr(), there&#x27;s an algorithm of similar complexity you might consider: <a href="http:&#x2F;&#x2F;0x80.pl&#x2F;notesen&#x2F;2016-11-28-simd-strfind.html" rel="nofollow">http:&#x2F;&#x2F;0x80.pl&#x2F;notesen&#x2F;2016-11-28-simd-strfind.html</a>
评论 #43731344 未加载
phickey27 天前
This looks like a nice approach to making wasi-libc faster. Could you submit these changes upstream?
评论 #43730651 未加载
cedws26 天前
Would you consider writing some blog posts or other resources about WASM? I was experimenting recently with WIT, and ran into a mountain of issues. There&#x27;s a lot of jargon that could do with some untangling.<p>It took me a lot longer than it should have to put together this basic module, and even then there&#x27;s this shared library I had to download to build it, and I couldn&#x27;t figure out why this requires a libc:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;cedws&#x2F;wasm-wit-test">https:&#x2F;&#x2F;github.com&#x2F;cedws&#x2F;wasm-wit-test</a>
评论 #43737586 未加载
tuananh24 天前
very cool project.<p>it&#x27;s kinda frustrating to compile sqlite for wasm. can be done but quite troublesome.
forrestthewoods26 天前
What is SWAR?
评论 #43734741 未加载
nu11ptr27 天前
It is still a bit early, but I&#x27;m majorly bullish on WASM for multiple use cases:<p>1. Client side browser polyglot &quot;applets&quot; (Java applets were ahead of their time IMO)<p>2. Server side polyglot &quot;servlets&quot; (Node.js, embedded runtimes, etc.)<p>3. Language interop&#x2F;FFI (Lang A -&gt; WASM -&gt; Lang B, like wasm2c)<p>Why is #3 so interesting? The hardest thing in language conversion is the library calls. WASI standardizes that, so all the proprietary libs will eventually compile down to WASI as a sort of POSIX&#x2F;libc like layer. In addition, WASM standardizes calling convention. The resulting new source code may not look like much, but it will solve the FFI calling convention&#x2F;marshalling&#x2F;library issues nicely.
评论 #43731316 未加载
评论 #43731214 未加载