Patrick Walton
@pcwalton.bsky.social
Programming languages and graphics person. Rust compiler, Firefox, and Bevy contributor. Currently working on an unannounced project!
Note that these instructions by themselves won't enable fast emulation without the virtual memory proposal.
November 8, 2025 at 1:38 AM
Note that these instructions by themselves won't enable fast emulation without the virtual memory proposal.
Yeah, I looked it over. I filed a couple of issues to add things that v86 would need: github.com/WebAssembly/... and github.com/WebAssembly/...
Add “try-load” and “try-store” instructions · Issue #23 · WebAssembly/memory-control
JITting emulators like http://copy.sh/v86 incur significant overhead from having to check page tables on every memory access. Traditionally, emulators implement this by trapping SIGSEGV. The signal...
github.com
November 7, 2025 at 6:36 PM
Yeah, I looked it over. I filed a couple of issues to add things that v86 would need: github.com/WebAssembly/... and github.com/WebAssembly/...
Well, I guess nommu doesn't help that much when you still need to invalidate jitcode. You're paying most of the cost of a TLB in that case...
Wish wasm had better support for setting page permissions and catching faults.
Wish wasm had better support for setting page permissions and catching faults.
November 6, 2025 at 10:10 PM
Well, I guess nommu doesn't help that much when you still need to invalidate jitcode. You're paying most of the cost of a TLB in that case...
Wish wasm had better support for setting page permissions and catching faults.
Wish wasm had better support for setting page permissions and catching faults.
By the way, the built-in benchmark on the Arch distro there reports 1GHz Pentium III performance for integer ops on my M4 iPad Pro, which really isn't too bad for softmmu wasm.
November 6, 2025 at 9:59 PM
By the way, the built-in benchmark on the Arch distro there reports 1GHz Pentium III performance for integer ops on my M4 iPad Pro, which really isn't too bad for softmmu wasm.
The particles were launched randomly. So when the normalization code looked at the vector length, it would effectively make a random vector, take its length, then make a *new* random vector, and divide the new vector by the length of the *old* one!
Solution: add more temporaries. Compilers! 3/3
Solution: add more temporaries. Compilers! 3/3
September 22, 2025 at 12:56 AM
The particles were launched randomly. So when the normalization code looked at the vector length, it would effectively make a random vector, take its length, then make a *new* random vector, and divide the new vector by the length of the *old* one!
Solution: add more temporaries. Compilers! 3/3
Solution: add more temporaries. Compilers! 3/3
I look at the shader source. Wait, why are there so many calls to random here?
Turns out, the Hanabi node-graph-to-WGSL compiler wasn't generating temporaries for side-effecting expressions like random. So every time you used a random node it would generate a new random number. 2/
Turns out, the Hanabi node-graph-to-WGSL compiler wasn't generating temporaries for side-effecting expressions like random. So every time you used a random node it would generate a new random number. 2/
September 22, 2025 at 12:54 AM
I look at the shader source. Wait, why are there so many calls to random here?
Turns out, the Hanabi node-graph-to-WGSL compiler wasn't generating temporaries for side-effecting expressions like random. So every time you used a random node it would generate a new random number. 2/
Turns out, the Hanabi node-graph-to-WGSL compiler wasn't generating temporaries for side-effecting expressions like random. So every time you used a random node it would generate a new random number. 2/
This is temporary, because upstream also wants to implement batching, just in a different incompatible way. Once that happens I'll deprecate this fork.
September 16, 2025 at 11:35 PM
This is temporary, because upstream also wants to implement batching, just in a different incompatible way. Once that happens I'll deprecate this fork.