The Mill's Competition: Can it still win?

Not a Mill spokesperson but figured I’d chime in.

Last I looked the sandboxing for WASM relied on you being restricted to a 4GB address space, which means most heavy duty server applications are out. When 64-bit WASM arrives it will likely involve slower code that has to perform runtime checks to enforce the sandboxing.

Also the power efficiency gains are the whole point of the Mill! This is the arbitrage Ivan mentions in his talks figuring out how to get the generality of an x86 CPU but with DSP like performance.

Cerebras is not really comparable because they are throwing out the window one of the main advantages of the Mill. The Mill only requires you to recompile your existing C/C++ code. Cerebras and GPUs require requiring it, and they require that the particular computation your software is doing is the kind that is massively parallel. Most day to day applications most people use for their work and that are running the world servers are don’t resemble the kind of workloads that GPU/Cerebras are good at.

If the fabs can build a 1.2M chip for one company then they can and will for all; the ISA question is whether you can use those transistors. In the CPU space you cannot; you are pin-pad limited on the wafer, and more transistors are useless except for heating office buildings. You can use them in some kinds of AI work, and likely also in rare embedded applications, data reduction in your friendly local SuperCollider for example. They won’t run Windows, and the control processors they need (and for which you can see them as peculiar I/O devices) can be Mills.

We still don’t see any prospect of a general change upcoming in the CPU ISA space. Except us. Thanks for your support; we will need it especially as we scale up, which was supposed to have happened this year, but 2020 🙁

According to Wikipedia WebAssembly may get about 65% of native assembly speed (mileage may vary).

WebAssembly runs on a VM and is more a 32-bit virtual machine running on modern hardware as much as Steve Wozniak’s Sweet-16 ran on the Apple 2 series (could run on other machines easily).

The biggest “value” for running WebAssembly on another processor rather than native is a portable executable that doesn’t need to be recompiled natively (or, not as much) but you lose so much more in the process of that, including execution speed, energy efficiency, and you need to have a lot of other things added to make it useful.

It’d be interesting to see how efficiently a Mill processor can execute the VM in practice because it’s clear it’s something a number of online things will use in web browsers. Outside of web browsers it makes far more sense to compile a higher-level language down to local Mill ISA than to use WebAssembly.

I believe that the most important property that a virtual ISA such as WebAssembly (or JVM, CLR, …) would have for cloud application developers is not to remove the need to recompile but to remove the need to test the code on each type of hardware that it is supposed to be deployed on. This determinism is something that has hitherto not been available for C/C++ developers.
If WebAssembly/WASI would develop in the right direction, I think that it would not pose a threat but rather help to reduce the cost of adopting new types of hardware, which would allow them to better compete on just such aspects such as performance/Watt where The Mill would excel.

Even though WebAssembly has limited performance (as it has been designed for fast code-generation rather than fast code-execution), I think that could be a lesser concern as a lot of an application’s run-time is often spent in imported modules anyway — which could still be in native code. But WebAssembly is also evolving.

I don’t see advantages of using WASM on the server/desktop for anything but C/C++ code though, but the Rust community seems to also have adopted it for some reason… Maybe just hype?

• This reply was modified 3 years, 7 months ago by  Findecanor.
• This reply was modified 3 years, 7 months ago by  Findecanor.

WebAssembly is a fantastic development, it’s gaining steam because compared to JavaScript, it’s much faster, the performance is much more reliable (it’s easy to accidentally break the JavaScript JIT’s ability to optimize a particular chunk of code), there’s no GC so latency is better, and you can target it with statically typed languages like Rust, so correctness is often better as well. So compared to using JavaScript it’s amazing, and will continue to get better with WASI (WebAssembly on its own has no syscalls, WASI adds a posix like layer).

But it doesn’t negate any of the performance/power advantages of the Mill. A WebAssembly compiler targeting the Mill should still end in better performance per watt than a WebAssembly compiler targeting x86.

This thread is a bit like saying, “Is the Mill still relevant because the JVM let’s you write code once and have it run everywhere, as well as preventing all the common security issues like buffer overflows and out of bounds accesses?” Look at how that worked out.

but aside from some power efficiency gains, can’t I get most of the Mill’s advantages by simply using WebAssembly + WASI?

WASI looks like it trying to be a capability based design. Which is certainly possible on existing hardware, it’s just always been slow. The Mill ISA and security model should adapt quite well to WASI, and you might even have a micro kernel with paravitualized drivers that can run the API directly. Great effeciency, and scalability.

WebAssembly sandboxing between modules on x86 still relies on each module’s memory occupying disjoint pages. The only reason the sandboxing is “cheap” is because 32-bit values can’t express numbers greater than or equal to 2**32, and implementations reserve that much address space for each module. But forcing them to run on disjoint pages results in scalability limits on how many sandboxes you can have and what the performance of communication between them will be. More pages means more TLB pressure.

I have not worked through the mental exercise, but my guess is that portal calls and the like on the Mill would let a WebAssembly JIT make sandboxing more performant than on x86 and generalize better to 64-bit. I’d need to refresh myself on how portals on the Mill interact with paging and permissions to say with confidence though and it would still be speculative until we have hardware.

I still find it a little odd to be thinking along the lines of “well if you ignore Mill’s core economic advantage will it still be better?” though.

It’s been a while since this thread was active, and WASM is coming along nicely, if not quickly. Here are a few neat developments (picked to sample recent progress, rather than totality of progress): First, just-in-time code generation within webassembly which uses a JIT strategy that would fit right in on a Mill, and then Postgres compiled to WASM running in browser which is surprising.

Ivan’s analysis seems spot on that the general WASM execution model maps fairly nicely to the Mill. I don’t think it’s too far to say that WASM’s principles align reasonably well with the Mill in general, and notably better than existing architectures. Don’t be fooled by the presence of the word “web” in its name, it’s design is closer to an intermediate representation for architecture-agnostic machine code than something that needs a heavyweight VM runtime like JS/JVM/.NET.

I suspect that WASM would be a great ‘IR’ to quickly port existing programs to work on the Mill without requiring (further) architecture retargeting. Once a WASM interpreter/compiler is built for the Mill — probably a more tractable task than adding the Mill as a new backend architecture in an existing compiler — many hundreds of existing WASM programs will start working right away. This could be a boon to get your hands on a wide array of nontrivial programs for testing and development, and as a fast path to write custom applications for the Mill.

• This reply was modified 1 year, 11 months ago by  Joe Taber.
• This reply was modified 1 year, 11 months ago by  Joe Taber.