I recently (within the last 30 days) tried prototyping something with Cranelift / Wasmtime (etc.) using WASI. And that was the problem: WASI isn’t there today, and to do anything real in Web Assembly outside of the browser, you kind of need WASI to be there. Even worse, there seems to be a huge political turf war going on between two warring factions, one that thinks that the browser is the only place that web assembly can work, and one that thinks that maintaining browser compatibility isn’t important. (Or at least, there are factions that want to imagine that they’re in a war, and want to imagine that their imagined enemy believes such crazy things.) The whole desire-for-it-to-be-a-war is just bizarre. Life’s too short to get caught up in stupid imaginary wars over technical stuff, but now you have groups (e.g. AS) actively trying to jettison their previous support for WASI over these perceived / imaginary battles.
It does look like the space will shake out at some point and WASI will fill out and provide (fingers crossed) interop between code from a web site running in a browser, and code running in e.g. Wasmtime. It’s just not quite there yet, and if people are permitted to drag imaginary wars into the space, it will take a lot longer to get there. I intend to come back in a year and see if any of the missing pieces have materialized, and see if the unnecessary drama has dissipated.
I suspect part of the problem with WASI being ‘there’ is that there isn’t consensus on what ‘there’ means. Some folks want to be able to write OS-independent applications, which requires WASI to grow enough to provide enough OS abstractions to talk to a native GUI toolkit. Some people want to ship architecture-agnostic Linux containers, which means that it needs to surface a large part of the Linux syscall interface but doesn’t need abstractions over it. Others (myself included) see it as an opportunity to ditch a load of POSIX legacy for the next generation of cloud systems and provide a very lightweight host interface for things that need only a network (possibly with some secure RPC layer and not just raw sockets), compute, and RAM, with everything else (e.g. persistent storage) being exposed over RPC.
It’s also a very new project, so I understand that it’s not farther along than it is. And you’re right: There are some competing visions for it. Overall, I’m impressed by the state of the Web Assembly world; I was just hoping it was going to be a tiny bit more “sane” 🤣.
I’m not terribly impressed by most of the design decisions in WebAssembly. A stack-based IR is annoying for optimisation and Dalvik has shown that register IRs are better for code density (they only thing stack-based IRs are better for is direct interpreters and those are not the intended target for WebAssembly). The requirement to have reducible control flow is annoying for front ends and does not make validation easier for control-flow integrity (a basic block index as a branch target is sufficient). Conflating pointers and integers will make retrofitting memory safety very difficult and happened two years after I demonstrated that you could compile non-trivial C/C++ code to a target with distinct pointer and integer types (the MSWasm work is building on this). Their decision to add fixed-width vectors to a cross-architecture IR is odd, given that LLVM can already target SVE and lowering from variable-width vectors to a fixed-width vector representation is far easier than the converse (and easier than changing from, for example, 128-bit vectors to 256-bit ones when targeting AVX).
Like RISC-V, I’m mostly interested in it because it seems to have traction, not because it’s technically very good.
Since the article is about Cranelift, I thought I’d focus on that. Cranelift is a code generator which aims to be faster and lighter weight than LLVM, with less optimization. The original WASM focus means that Cranelift may inherit problems from WASM.
stack-based IR
The input to Cranelift is not WASM, it is CLIF, which is SSA, not a stack based IR.
reducible control flow
In CLIF, control flow is represented by a graph of basic blocks, each block ending in a conditional or unconditional jump to another block. Block parameters are used instead of phi instructions. I can’t find any documentation requiring that CLIF CFGs must be reducible. So I’m not sure if this is a restriction?
conflating pointers and integers
Yes, this seems to be baked into CLIF right now.
fixed width vectors
This is a current limitation, but the progress report says they are working on this (the feature is “flexible vector types”).
IIRC correctly, they originally wanted to just ship an AST but there was some logic that couldn’t be represented that way. The deadline was coming up and they saw stack vs register as mostly being equivalent. One reason they chose stack was because the overall size of the payloads would be smaller, which is important for a network oriented runtime. But it was an admittedly rushed decision.
Everything you said seems technically correct. As you know, the best tech isn’t the one that people end up using … and in the case of WA, the massive investment from Google etc. has made it competitive, despite its technical shortcomings. As you say: you’re “mostly interested in it because it seems to have traction, not because it’s technically very good.” Well said.
I recently (within the last 30 days) tried prototyping something with Cranelift / Wasmtime (etc.) using WASI. And that was the problem: WASI isn’t there today, and to do anything real in Web Assembly outside of the browser, you kind of need WASI to be there. Even worse, there seems to be a huge political turf war going on between two warring factions, one that thinks that the browser is the only place that web assembly can work, and one that thinks that maintaining browser compatibility isn’t important. (Or at least, there are factions that want to imagine that they’re in a war, and want to imagine that their imagined enemy believes such crazy things.) The whole desire-for-it-to-be-a-war is just bizarre. Life’s too short to get caught up in stupid imaginary wars over technical stuff, but now you have groups (e.g. AS) actively trying to jettison their previous support for WASI over these perceived / imaginary battles.
It does look like the space will shake out at some point and WASI will fill out and provide (fingers crossed) interop between code from a web site running in a browser, and code running in e.g. Wasmtime. It’s just not quite there yet, and if people are permitted to drag imaginary wars into the space, it will take a lot longer to get there. I intend to come back in a year and see if any of the missing pieces have materialized, and see if the unnecessary drama has dissipated.
I suspect part of the problem with WASI being ‘there’ is that there isn’t consensus on what ‘there’ means. Some folks want to be able to write OS-independent applications, which requires WASI to grow enough to provide enough OS abstractions to talk to a native GUI toolkit. Some people want to ship architecture-agnostic Linux containers, which means that it needs to surface a large part of the Linux syscall interface but doesn’t need abstractions over it. Others (myself included) see it as an opportunity to ditch a load of POSIX legacy for the next generation of cloud systems and provide a very lightweight host interface for things that need only a network (possibly with some secure RPC layer and not just raw sockets), compute, and RAM, with everything else (e.g. persistent storage) being exposed over RPC.
The problem with wanting to “ditch a load of POSIX legacy” is that nobody seems to be able to agree on what counts as “POSIX legacy”.
It’s also a very new project, so I understand that it’s not farther along than it is. And you’re right: There are some competing visions for it. Overall, I’m impressed by the state of the Web Assembly world; I was just hoping it was going to be a tiny bit more “sane” 🤣.
I’m not terribly impressed by most of the design decisions in WebAssembly. A stack-based IR is annoying for optimisation and Dalvik has shown that register IRs are better for code density (they only thing stack-based IRs are better for is direct interpreters and those are not the intended target for WebAssembly). The requirement to have reducible control flow is annoying for front ends and does not make validation easier for control-flow integrity (a basic block index as a branch target is sufficient). Conflating pointers and integers will make retrofitting memory safety very difficult and happened two years after I demonstrated that you could compile non-trivial C/C++ code to a target with distinct pointer and integer types (the MSWasm work is building on this). Their decision to add fixed-width vectors to a cross-architecture IR is odd, given that LLVM can already target SVE and lowering from variable-width vectors to a fixed-width vector representation is far easier than the converse (and easier than changing from, for example, 128-bit vectors to 256-bit ones when targeting AVX).
Like RISC-V, I’m mostly interested in it because it seems to have traction, not because it’s technically very good.
Since the article is about Cranelift, I thought I’d focus on that. Cranelift is a code generator which aims to be faster and lighter weight than LLVM, with less optimization. The original WASM focus means that Cranelift may inherit problems from WASM.
The input to Cranelift is not WASM, it is CLIF, which is SSA, not a stack based IR.
In CLIF, control flow is represented by a graph of basic blocks, each block ending in a conditional or unconditional jump to another block. Block parameters are used instead of phi instructions. I can’t find any documentation requiring that CLIF CFGs must be reducible. So I’m not sure if this is a restriction?
Yes, this seems to be baked into CLIF right now.
This is a current limitation, but the progress report says they are working on this (the feature is “flexible vector types”).
IIRC correctly, they originally wanted to just ship an AST but there was some logic that couldn’t be represented that way. The deadline was coming up and they saw stack vs register as mostly being equivalent. One reason they chose stack was because the overall size of the payloads would be smaller, which is important for a network oriented runtime. But it was an admittedly rushed decision.
Everything you said seems technically correct. As you know, the best tech isn’t the one that people end up using … and in the case of WA, the massive investment from Google etc. has made it competitive, despite its technical shortcomings. As you say: you’re “mostly interested in it because it seems to have traction, not because it’s technically very good.” Well said.