Do I understand the last section correctly that any function will get an implicit pool scope and delete all its temp allocations implicitly? And nothing prevents leaking pointers to the temp memory? If yes, that sounds like a really unfortunate default?
Multiple JavaScript engines had an exploitable vulnerability due to WebAudio changing CPU flags affecting floating point semantics that then led to breaking assumptions done by the JIT compilers (e.g. range analysis): issues.chromium.org/issues/38200...
Wasm code only tiers up after many calls / loop iterations (per function), another guess could be that arm64's native instructions might be more suitable for this use case. Potentially the relaxed SIMD feature can help. ("-mrelaxed-simd" in emscripten?)
3.7x slowdown is a lot.
Have you tried running it in a JS loop many times to see if the numbers get better over time? Chrome uses tiered compilation and your measurements might only hit the baseline compiler.
Great for anyone learning English:
1) Homophones: air and heir, weather and whether, ate and eight
2) Heteronyms: read, wind, tear
3) Heteronyms where the stressed syllable changes: content, produce, object
V8 requires SSE4.1 for Wasm SIMD support on x86 (github.com/v8/v8/blob/m...), so desktop CPUs <15 years old should support it afaict?
V8 Security is hiring in Munich, Germany: www.google.com/about/career...
Great opportunity to work on some really hard and interesting problems in the security space!
V8's optimizing compiler for #wasm can now perform more speculative inlining and can use deoptimizations to enable more aggressive optimizations:
v8.dev/blog/wasm-sp...
I'm not sure if JSPI covers these use cases but the Wasm stack switching proposal should: github.com/WebAssembly/...
The experimental implementation in V8 has been started but is still in an early state afaict.
Unfortunately, the inlining hints part of the compilation hints proposal has not been implemented in V8, yet.
1MB sounds like a lot. May I ask if you use binaryen for additional wasm-to-wasm optimizations?
For wasm this was seen as an issue and addressed with the introduction of memory64: github.com/WebAssembly/...
It doesn't however mean that a web application should use more than 4 GB of linear memory. :)
For the conversion between wasm-gc arrays and strings, there is a GitHub issue for it: github.com/WebAssembly/...
(But it will probably not be addressed soon as the current proposal is already stage 4, so it would require a new one.)
If you only need quick access to UInt8Arrays, in v8 if you exactly import "Function.prototype.call.bind(DataView.prototype.getUint8)", it will perform a direct built-in call without first calling to JS (this is only supported for specific JS functions like data view getters and setters).
Also, as your blog post uses user space JS interop: the wasm community group is exploring richer interop that could include attaching prototypes to wasm objects: github.com/WebAssembly/...
The wasm objects would still be opaque but a toolchain could e.g. install functions like the "res.is_ok()".
Very cool post and I'm happy to see more toolchains picking up the JS string builtins. Had you experimented with the stringref proposal before the builtins proposal came along?
Do the builtins miss anything that you'd like to have faster access to?
If you use node v23, the wasm version should already be faster than the JS version (I see 6.5 vs 7.5s) while on v22 they are about the same speed.
The speedup is caused by inlining being enabled for wasm by default now. (To see the effect, " node --no-experimental-wasm-inlining ..." disables it.)
Could you run it multiple times from JS to see if results improve? V8 doesn't support OSR for wasm, so it might run unoptimized code only.
It might help to replace mutable globals with passing as arguments as global accesses require some indirections. wasm-opt might also find some improvements.
