Matthias Liedtke

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.

YouTube video by Loic Suberville English Makes No Sense: Eight vs. Height

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. :)

Fast conversion to/from ASCII/one-byte strings? · Issue #44 · WebAssembly/js-string-builtins It's a near universal optimization within JS implementations to split strings into two representations: a one-byte and a two-byte. Even the size-optimized runtime XS does it. It brings a massive sp...

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).

Proposal: Custom RTTs, Type-Associated Data, and WasmGC JS Interop · Issue #1552 · WebAssembly/design WebAssembly structs and other heap values are currently associated at runtime with “runtime type” objects, or RTTs, which contain the information necessary to implement structural casts and type ch...

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.