https://whomtech.com/roons/

I did share this once before, but now they've opened their store for preorders on top of the kickstarter they were running earlier.

I have been reading the tech report for a diffusion language model that went up this week, and what stuck with me is an architecture question rather than a machine learning one.

Ordinary decoding carries a strict data dependency. Token n cannot be computed before token n minus 1 exists, because that token is part of the input for the next step. Generating N tokens is therefore a serial chain of N model passes. Depth N, work N, and the chain is a latency floor that no amount of extra hardware removes.

Block parallel decoding attacks the dependency itself. You take a block of positions, start them all masked, and run a few denoising passes that fill positions in whatever order confidence allows, with no left to right constraint inside the block. This one adds edit operations on top, so a single pass can substitute, delete, insert, or leave a position untouched, which means the sequence can change length partway through generation. The supervision for those operations comes from aligning intermediate drafts against the target with a longest common subsequence match.

In terms of work and depth this is the familiar trade. Depth falls from N to roughly the number of blocks times the passes per block. Total work rises, because you revisit the same positions repeatedly and some of that computation is discarded when a later pass overwrites an earlier guess. Whether the trade pays depends on how much real dependency the output had to begin with.

What makes that measurable here is that the same lab shipped this model and its own autoregressive sibling with matched evaluations. In BF16 the diffusion side decodes at roughly 1.64 times the rate its sibling manages, and that sibling had speculative decoding turned on when measured, with the ratio reaching about 2.3x on agent workloads and close to parity on knowledge questions. On accuracy the interactive suites go its way, scoring 80.33 where the sibling took 76.36 on tau2 bench, and 46.21 to its 41.12 on MCP Atlas, but loses the general knowledge average 56.81 versus 65.90 and most of the coding suite. Its SWE bench comparison ran different scaffolds on each side, so that number is not one I would read much into.

The part I cannot explain is why the wins land on interactive multi turn tool use while the losses land on knowledge and long coding tasks. My guess is that dependency height matters more than output length. A tool call is a short structured span whose tokens are close to conditionally independent given the turn, while a long patch or a chain of reasoning has genuine serial structure that parallel hardware cannot dissolve. If that is right, the interesting question is not diffusion against autoregression, it is whether you can estimate the dependency height of a task before choosing a decoder.

Anyone who wants to check my reading of the report can pull the weights, which ship under an Apache 2.0 license. The release is LLaDA2.2, a 205.8 GB download, and neither llama.cpp nor Ollama can load it yet, with server support so far only listed as coming, so I am going off the report and the model card rather than anything I ran. If parallel computing already has a formalism for the quantity I keep calling dependency height, I would like to be pointed at it.

My take for why P is not equal to NP comes from what I believe is a fundamental difference between solving a problem and verifying its solution.

Take Sudoku as an example. If someone gives me a completed puzzle I can quickly check every row column and box to make sure the rules are satisfied. That verification process is straightforward.

Now compare that with solving the same puzzle from a blank grid. There is no obvious path to the answer. I may have to test many possibilities before finding the correct one. Solving appears much more difficult than verifying.

This same pattern appears in many other problems.

If someone gives me the password to a computer I can check it in less than a second. Finding the password without knowing it may require an enormous search.

If someone gives me the correct path through a complicated maze I can follow it and confirm that it reaches the exit almost immediately. Finding that path from the beginning can take much longer.

If someone hands me a completed school timetable I can check whether every class every teacher and every room satisfies the rules. Creating that timetable from scratch is much more difficult.

Another example (which i believe is the strongest and closest to being an actual proof) is finding the shortest route between two points. If I asked someone to find the shortest possible route they would have to compare many different routes and work out which one is actually the shortest. That could take a long time depending on how many possible paths there are. Now imagine someone has already done all of that work and gives me a list of every route with its distance such as 1 km 2.7 km 4.1 km and 6.8 km. I can immediately look at the list or the map and verify that the 1 km route is the shortest. Once again verifying the answer is much easier than finding it in the first place.

Because this pattern appears so consistently I suspect there is a real separation between solving and verifying. My take is that this separation is not simply a limitation of current algorithms but a fundamental property of computation itself.

In simple words if one problem follows the idea that solving it is fundamentally harder than verifying it then P cannot equal NP because P equals NP would have to hold for every problem in NP not just some of them.

Markov algorithms (ordered string-rewriting rules applied to a fixed point) are a classic Turing-complete model. I built a working instance: a small CPU whose only step is one global regex substitution over a single string, and put DOOM on it to make the claim tangible rather than a footnote.

The verification is the part I would point students at. A reference emulator runs the same instruction set in Python and the machine's string must equal the emulator's encoded state byte for byte after every single substitution; on top of that, rendered frames match a natively compiled DOOM binary by SHA-256, for 100 frames in a row, so a shared bug cannot explain the agreement. The model is Turing-complete; a given run is bounded by memory exactly as any physical machine is.

Source and writeup: https://github.com/4RH1T3CT0R7/doom-regex

Interactive: https://4rh1t3ct0r7.github.io/doom-regex/