@dubroy.com alerted me to the Safari release notes (developer.apple.com/documentatio...) say version 26 ships an in-place interpreter for WebAssembly, which is in part based on the Wizard design, but adapted for Safari's use cases.
Today I finished implementing the last of the relaxed-simd proposal (now Phase 4). That completes Wizard's support for all of the Wasm 3.0 features, which includes all the good things like exception handling, function references, garbage collection, and tail calls!
Yeah, unaligned loads are generally pretty fast on intel, but keep in mind that you're benefiting a lot from a forward scan, so prefetching is going to have cache lines ready. It hurts most when you cross a cache line boundary, which is only a fraction of accesses.
Whenever a new feature is hot off the presses I am a little hesitant to use it in "production" code, and certainly a self-hosted compiler requires a stable rev to be usable, but man--unittests? Blast away with those lambda bombs.
First there were just Class, Functions, Tuples, and Type Parameters. Then there were algebraic data types. Then, partial application. Now, full lexical closures!
First there were just Class, Functions, Tuples, and Type Parameters. Then there were algebraic data types. Then, partial application. Now, full lexical closures!
As of last December, release 2.0 of the #Wasm specification is “official”! Read Andreas Rossberg's post, which happens to be the first real post on the #WebAssembly website's new News 🗞️ section: webassembly.org/news/2025-03....
We haven't experimented much with Wasip2 yet, but your comment gives me the idea that we could recompile the wasmtime implementation with the Rust target...hmmm :)
Yesterday we put up the camera-ready for the WALI paper!
This paper introduces Thin Kernel Interfaces for WebAssembly which allows a new class of powerful applications for Wasm and building higher-level interfaces like WASI in an engine-agnostic way.
Performance is a red herring I think here. Getting efficient data represents (read: avoiding boxing and unnecessary allocations) is more than half the battle. But systems also could benefit from some esoteric features like data layouts, which is something I've focused on recently.
Well systems programming is my niche and I feel like systems languages have an unfortunate habit of morphing into application languages. The real systems problems are data representations and safety--not on chasing market share through better ergonomics.
Wizard has supported Wasm GC for a while now, but now it finally supports all GC opcodes in JIT-only mode. The object model needs work, but this unblocks more perf work for stack switching.
Over the past week or so I spent some time adding some syntactic sugar (with type inference) to Virgil. The idea is that function/method bodies that are a simple return of an expression can have their return types inferred. A can of worms, but looks nice, IMHO.
Not that surprised. Back when we were working on Spectre we thought about speculation on data values but concluded CPUs weren't doing it. This is a form of data value speculation and it's extremely hard to reason about all the possible weird things that can happen in speculation because of it.
I had a programming book on Windows 95...in 1994!! 500+ pages that documented darn near everything. Glossary, index, working examples, migration path. The amount of preparation that went into this launch was astounding.
Finally pulled the trigger on another stable revision of the Virgil compiler (checking in the binaries of the compiler having compiled itself), which is good because right after is the perfect time to shake things up with new features and optimizations!
