burntcaramel

Now with Mojo and WebAssembly I notice 3 different approaches for platform-independent SIMD. For examples operating on an array of floats:

- WebAssembly: 4 float32s

- Mojo: N float32s where N is a compile-time parameter

- Go simd: vector of float32s

I’ve been surprised how feasible static allocation has been. I thought it would be too restrictive and you’d be constantly hitting a wall. I’m writing WebAssembly in Zig/Odin/C and I’ve been able to have a linter reject the `memory.grow` wasm instruction and just use fixed-sized buffers in my code.

It me you think “ok, how big do I want the maximum image to be?” I’ve settled on 25 megapixels, which in the hundreds of megabytes. Since most images are much smaller, I believe on all mainstream hosts the memory isn’t paged in until it is first read/write so the memory footprint is much smaller.

From listening to Chris Lattner in interviews my guess it’s learning from when Swift became open source. The beta versions of Swift had massive language changes in how value types worked like with Array. Mojo is trying to get this language design locked down first, which is easier to do behind closed doors.

A compiler promising source stability is a different commitment than the compiler’s code being ready for outside contributors. Which is also different to having ABI stability, which took until 5.0 for Swift to achieve (I think Mojo does not have ABI stability as a goal as it doesn’t have to link to OS frameworks).