Summarizer

WebAssembly and VM Embedding

Discussion of why WebAssembly was chosen for the VM, with alternative suggestions like embedded Elixir or other lightweight interpreters.

← Back to Executing programs inside transformers with exponentially faster inference

The discussion centers on whether embedding WebAssembly is the most efficient way to grant LLMs computational power, with some suggesting that lightweight alternatives like Elixir could better minimize overhead and streamline code generation. While some participants are fascinated by a next-token predictor’s ability to execute assembly and potentially "internalize" computation, others argue the approach is a temporary "hack" that functions as a general oracle without solving core architectural problems directly. Ultimately, the debate explores whether these models should use internal execution engines to improve their "thinking" or if programs should eventually be optimized directly into the transformer weights themselves to bypass token-based tool calling altogether.

3 comments tagged with this topic

View on HN · Topics
I spent the entire time reading it pondering the same thing. 1. The article presents that calling out to a tool like python is "expensive" because of the overhead of forking a process, loading up the python env etc, but why not just eliminate that overhead and embed WebAssembly so this "tool call" is near zero? This feels very similar to the discussion in the 90's around the overhead of threads v.s. processes or kernel space v.s. user space. Could even go further and have a running beam vm so the LLM can write elixir which is ideal for LLM's that stream out code? Elixir programs will be a lot shorter than webassembly. 2. The core argument stated is "A system that cannot compute cannot truly internalize what computation is." The idea being that it could write a program, execute it and by seeing all of the steps maybe even part way through stop and change its mind or when writing new programs write them better, aka be able to debug on the fly? 3. Not mentioned, but there is a 3rd x factor that LLM's will use this new found computation engine to do overall better at "thinking". Computing in very unexpected ways and to unexpected problems. Maybe it would do dramatically better at some benchmark because of this? Unfortunately these are not explored and it is just an execution engine even resulting in the conclusion stating "arbitrary programs can be compiled directly into the transformer weights, bypassing the need to represent them as token sequences at all." which goes to point number 1 of if we are compiling to weights why not just optimize the tool calling?
View on HN · Topics
It makes sense that a next token predictor could execute assembly code. This is fascinating work, especially with the memory implementation.
View on HN · Topics
This looks like a hack. Yes, being able to interpret webassembly is a general oracle. Still falls short of solving the real problem directly.